From shade at openjdk.java.net  Wed Jun  1 10:15:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 10:15:36 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
Message-ID: <_9szrwwasTwWD6ZQRRnt8eR7tLE685Hmi8eSK-XtkAM=.93186cc4-3e8f-4348-8e1a-13897c8a8255@github.com>

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

I am okay with most of it, but still concerned with the injecting new code into hot marking loops.

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

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

From shade at openjdk.java.net  Wed Jun  1 10:15:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 10:15:38 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
Message-ID: <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>

On Mon, 30 May 2022 07:08:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - NMethod::heal_nmethod() does not need to handle ref-update
>
> src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73:
> 
>> 71:     if (obj->is_instance()) {
>> 72:       // Case 1: Normal oop, process as usual.
>> 73:       if (ContinuationGCSupport::relativize_stack_chunk(obj)) {
> 
> Ooof, this is very hot code path. Is there any way to do this without injecting the code here?

Um, this conversation seems to be "resolved" without the answer.

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

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

From zgu at openjdk.java.net  Wed Jun  1 12:32:33 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 12:32:33 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
Message-ID: <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>

On Wed, 1 Jun 2022 10:10:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 73:
>> 
>>> 71:     if (obj->is_instance()) {
>>> 72:       // Case 1: Normal oop, process as usual.
>>> 73:       if (ContinuationGCSupport::relativize_stack_chunk(obj)) {
>> 
>> Ooof, this is very hot code path. Is there any way to do this without injecting the code here?
>
> Um, this conversation seems to be "resolved" without the answer.

Hmm... somehow, my comments gone missing.

Yes, I am award of it, but could not find a better place, any suggestions are welcome.

ZGC takes the similar hit [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/z/zMark.cpp#L289).

Let's get this in for correctness and work on optimizing it in followup CR.

Thanks.

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

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

From stefank at openjdk.java.net  Wed Jun  1 13:03:33 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 1 Jun 2022 13:03:33 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
 <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
Message-ID: <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>

On Wed, 1 Jun 2022 12:28:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Um, this conversation seems to be "resolved" without the answer.
>
> Hmm... somehow, my comments gone missing.
> 
> Yes, I am award of it, but could not find a better place, any suggestions are welcome.
> 
> ZGC takes the similar hit [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/z/zMark.cpp#L289).
> 
> Let's get this in for correctness and work on optimizing it in followup CR.
> 
> Thanks.

Both `obj->is_instance()` and `obj->is_stackChunk()` in `relativize_stack_chunk` checks the same Klass::_kind field, so I would be surprised if you would be able to find a perf regression here. We checked the marking times before and  after adding relativize_stack_chunk, and couldn't see any difference.

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

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

From zgu at openjdk.java.net  Wed Jun  1 13:50:37 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 13:50:37 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
 <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
 <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>
Message-ID: <Gtnd_KHEs2YO7676ygHghncDMmBi5RxRoc60hXZzq3k=.8c54e550-2643-4bde-8f63-2d57b2f726ac@github.com>

On Wed, 1 Jun 2022 13:00:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Hmm... somehow, my comments gone missing.
>> 
>> Yes, I am award of it, but could not find a better place, any suggestions are welcome.
>> 
>> ZGC takes the similar hit [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/z/zMark.cpp#L289).
>> 
>> Let's get this in for correctness and work on optimizing it in followup CR.
>> 
>> Thanks.
>
> Both `obj->is_instance()` and `obj->is_stackChunk()` in `relativize_stack_chunk` checks the same Klass::_kind field, so I would be surprised if you would be able to find a perf regression here. We checked the marking times before and  after adding relativize_stack_chunk, and couldn't see any difference.

Thanks for your insights, @stefank

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

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

From shade at openjdk.java.net  Wed Jun  1 14:49:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 14:49:32 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <Gtnd_KHEs2YO7676ygHghncDMmBi5RxRoc60hXZzq3k=.8c54e550-2643-4bde-8f63-2d57b2f726ac@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <Y6KO2ne0DuMpiHAWkW0scbgYMTdP7JbvTvgV94NzDAI=.11fdaeec-24b6-4085-bab2-9fcbe8c932be@github.com>
 <PxLk7BpKm83_te0G6zdE__tYmpU9p9hUzX7BgBRwif4=.b6b7160a-9a3d-4c8d-95f9-956d9743a240@github.com>
 <QrCb9Ldh-20z5euCpOAy-yHlTnTB-K5UNn29X4SXskk=.3dbf10f8-56a7-4d9f-81c9-4ec03e8a93d2@github.com>
 <DnHx7vSwo59I8_ThaoRGe6eIrYZSVcFZoyuCPvLD1VE=.2299443b-a79d-4369-b67b-048f7b157954@github.com>
 <Gtnd_KHEs2YO7676ygHghncDMmBi5RxRoc60hXZzq3k=.8c54e550-2643-4bde-8f63-2d57b2f726ac@github.com>
Message-ID: <lJpOuBmkdPXK676M85mbzNkqgSBYCYAlXwsU3saJuUA=.a4d01b93-c291-4c6c-949e-d72d0d3cb905@github.com>

On Wed, 1 Jun 2022 13:48:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Both `obj->is_instance()` and `obj->is_stackChunk()` in `relativize_stack_chunk` checks the same Klass::_kind field, so I would be surprised if you would be able to find a perf regression here. We checked the marking times before and  after adding relativize_stack_chunk, and couldn't see any difference.
>
> Thanks for your insights, @stefank

All right then!

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

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

From shade at openjdk.java.net  Wed Jun  1 15:48:37 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 15:48:37 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
Message-ID: <C1vgYGAgRQ3pPxsMPjDU250vn66DYc0g_O_DRA258_w=.81a75978-10c7-4265-938a-7d47a1325646@github.com>

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

I still have a question: now that closures drop `do_metadata`, does that mean we always traverse metadata now? Which means we can remove half of the closures? For example, `ShenandoahMarkUpdateRefsClosure` and `ShenandoahMarkUpdateRefsMetadataClosure` are pretty much the same, right? We can leave `ShenandoahMarkUpdateRefsClosure` only then?

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

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

From zgu at openjdk.java.net  Wed Jun  1 16:00:47 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 16:00:47 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <C1vgYGAgRQ3pPxsMPjDU250vn66DYc0g_O_DRA258_w=.81a75978-10c7-4265-938a-7d47a1325646@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
 <C1vgYGAgRQ3pPxsMPjDU250vn66DYc0g_O_DRA258_w=.81a75978-10c7-4265-938a-7d47a1325646@github.com>
Message-ID: <XlZ5C8d1y-KCr7kl00zRFNR6_F6135cO7VCTHfwfXMQ=.f49b924e-0934-48d2-b456-a8967c619281@github.com>

On Wed, 1 Jun 2022 15:45:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ShenandoahMarkUpdateRefsMetadataClosure

Yes, we always walk metadata now.

And right, I need to look into duplicated closures. But can we do that in separate CR? Another round of tests going to take a couple of days, and I want to get this in before RDP1.

Thanks.

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

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

From shade at openjdk.java.net  Wed Jun  1 16:13:33 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Jun 2022 16:13:33 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
Message-ID: <9uPHyMy7RkyTdkd60iSSRUrekR8ItM5I9THw_3BEq7M=.13de37f9-28d3-4e25-9d53-a60276ad9a21@github.com>

On Tue, 31 May 2022 17:45:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review the patch that fixes Loom support in Shenandoah GC.
>> 
>> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
>> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
>> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
>> 
>> Test:  
>> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
>> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
>> - [x] hotspot_gc_shenandoah  on Linux x86_32
>> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - NMethod::heal_nmethod() does not need to handle ref-update

All right then!

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Wed Jun  1 17:04:37 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 17:04:37 GMT
Subject: RFR: 8286829: Shenandoah: fix Shenandoah Loom support [v3]
In-Reply-To: <9uPHyMy7RkyTdkd60iSSRUrekR8ItM5I9THw_3BEq7M=.13de37f9-28d3-4e25-9d53-a60276ad9a21@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
 <N2ilTCcuA77Xc_nmiwVoWRfkh1JcbtpRY22XHSp6iDk=.76bc1ab1-c41d-4666-9f7c-5190e768f5bf@github.com>
 <9uPHyMy7RkyTdkd60iSSRUrekR8ItM5I9THw_3BEq7M=.13de37f9-28d3-4e25-9d53-a60276ad9a21@github.com>
Message-ID: <VlLjMFN6q8pJwxJ2vQfmxOOMKZyU7apAqG5sfS87JHM=.8e45c2d5-0b5e-4520-bf32-787246f28190@github.com>

On Wed, 1 Jun 2022 16:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix
>>  - NMethod::heal_nmethod() does not need to handle ref-update
>
> All right then!

Thanks, @shipilev

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

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

From zgu at openjdk.java.net  Wed Jun  1 17:04:39 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 1 Jun 2022 17:04:39 GMT
Subject: Integrated: 8286829: Shenandoah: fix Shenandoah Loom support
In-Reply-To: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
References: <22heQxmCt68HgtjwEZ_DYH55Fq574GeGWjeIHriOM0c=.0cb10596-4cc0-4b3b-b7c6-c5da82f97d5d@github.com>
Message-ID: <NNN4yZJQT1k9NJwGkE0jik5754JaDtA0NOVd9gniPHk=.a24ec7d8-80d2-43bc-b063-ccc391afb032@github.com>

On Fri, 27 May 2022 14:52:19 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review the patch that fixes Loom support in Shenandoah GC.
> 
> - stackChunkOop is a special oop that contains stack metadata, we need to utilize nmethod entry barrier to mark, evacuate and update stack metadata.
> - During evacuation and reference updating phase, we can not guarantee all metadata in stackChunkOop is deeply good, so I force it to take slow path for the correctness, will try to optimize it later in separate CR.
> - Shenandoah uses similar way to arm and disarm nmethod as the new mechanism introduced in JDK-8284161. We may want to migrate to it in followup CR.
> 
> Test:  
> - [x] tier1 with ShenandoahGC  (Linux x86_64 and Windows x64)
> - [x] tier2 with Shenandoah GC (Linux x86_64 and Windows x64) 
> - [x] hotspot_gc_shenandoah  on Linux x86_32
> - [x] tier1 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)
> - [x] tier2 with ShenandoahGC + Loom (Linux x86_64 and Windows x64)

This pull request has now been integrated.

Changeset: 239ac2a5
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/239ac2a5d4c9a13e10e8c75324cd51f5f825337d
Stats:     112 lines in 15 files changed: 77 ins; 7 del; 28 mod

8286829: Shenandoah: fix Shenandoah Loom support

Reviewed-by: shade

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

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

From zgu at openjdk.java.net  Thu Jun  2 19:17:54 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 2 Jun 2022 19:17:54 GMT
Subject: RFR: 8287734: Shenandoah: Consolidate marking closures
Message-ID: <fWcimNxZI2_TIvigLf2yJQ92hyk9pXCcqajXFoL7tPc=.9cf3ca10-5d88-4758-8875-3133cea5ad49@github.com>

Shenandoah used to have different marking closures that mark metadata or not. With Loom, marking closures always mark metadata, so they can be consolidated.

Test:

- [x] hotspot_gc_shenandoah
- [x] jdk_loom + ShenandoahGC
- [x] hotspot_loom + ShenandoahGC

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

Commit messages:
 - Update
 - v0

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

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

From shade at openjdk.java.net  Fri Jun  3 05:54:31 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Jun 2022 05:54:31 GMT
Subject: RFR: 8287734: Shenandoah: Consolidate marking closures
In-Reply-To: <fWcimNxZI2_TIvigLf2yJQ92hyk9pXCcqajXFoL7tPc=.9cf3ca10-5d88-4758-8875-3133cea5ad49@github.com>
References: <fWcimNxZI2_TIvigLf2yJQ92hyk9pXCcqajXFoL7tPc=.9cf3ca10-5d88-4758-8875-3133cea5ad49@github.com>
Message-ID: <8bUr_BAC3ux5oM87a-IU31Iji_Fx5wtHtppI80hze70=.f5d79f07-a6aa-425a-b0db-5d2ce830c459@github.com>

On Thu, 2 Jun 2022 17:29:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah used to have different marking closures that mark metadata or not. With Loom, marking closures always mark metadata, so they can be consolidated.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom + ShenandoahGC
> - [x] hotspot_loom + ShenandoahGC

Nice, looks good.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Fri Jun  3 12:34:44 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 3 Jun 2022 12:34:44 GMT
Subject: Integrated: 8287734: Shenandoah: Consolidate marking closures
In-Reply-To: <fWcimNxZI2_TIvigLf2yJQ92hyk9pXCcqajXFoL7tPc=.9cf3ca10-5d88-4758-8875-3133cea5ad49@github.com>
References: <fWcimNxZI2_TIvigLf2yJQ92hyk9pXCcqajXFoL7tPc=.9cf3ca10-5d88-4758-8875-3133cea5ad49@github.com>
Message-ID: <w1P5Twl2_5Lsz9JeWw6o42d_qWyWargBK5SmmqHaXHg=.80112831-6823-4bc7-872f-e86201fefe3f@github.com>

On Thu, 2 Jun 2022 17:29:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah used to have different marking closures that mark metadata or not. With Loom, marking closures always mark metadata, so they can be consolidated.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom + ShenandoahGC
> - [x] hotspot_loom + ShenandoahGC

This pull request has now been integrated.

Changeset: 34bb0a5e
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/34bb0a5e6e9c91e037fbbe87382e8275b2435a3f
Stats:     46 lines in 2 files changed: 0 ins; 39 del; 7 mod

8287734: Shenandoah: Consolidate marking closures

Reviewed-by: shade

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

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

From zgu at openjdk.java.net  Fri Jun  3 19:08:04 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 3 Jun 2022 19:08:04 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures
Message-ID: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>

ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.

Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.

Test:

- [x] hotspot_gc_shenandoah

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

Commit messages:
 - 8287805: Shenandoah: consolidate evacuate-update-root closures
 - Merge branch 'master' into consolidate_evac_root_closures
 - v0
 - v0

Changes: https://git.openjdk.java.net/jdk/pull/9023/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9023&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287805
  Stats: 70 lines in 4 files changed: 7 ins; 30 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9023.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9023/head:pull/9023

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

From zgu at openjdk.java.net  Mon Jun  6 23:38:23 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 6 Jun 2022 23:38:23 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom
Message-ID: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>

Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it.

Test:

- [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64
- [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 
- [x] hotspot_gc_shenandoah on AArch64

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

Commit messages:
 - 8287818: Shenandoah: adapt nmethod arming from Loom
 - Merge branch 'master' into migrate_nmethod_arming_shenandoah
 - v0

Changes: https://git.openjdk.java.net/jdk/pull/9048/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287818
  Stats: 53 lines in 5 files changed: 4 ins; 41 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9048.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9048/head:pull/9048

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

From duke at openjdk.java.net  Tue Jun  7 23:45:14 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 7 Jun 2022 23:45:14 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during code
 emission
Message-ID: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>

Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.

As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.

I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.

**I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.

Thanks in advance,
Cesar

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

Commit messages:
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - merging
 - merge fix for macos building
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/239ac2a5...7c739f77

Changes: https://git.openjdk.java.net/jdk/pull/9074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8241503
  Stats: 2393 lines in 49 files changed: 117 ins; 332 del; 1944 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9074.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9074/head:pull/9074

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

From duke at openjdk.java.net  Tue Jun  7 23:49:09 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 7 Jun 2022 23:49:09 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v2]
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <AVvBOfxDwSVIcUpLEWJgDa5vcWrg19woaMdan40Q8C4=.f932b386-3688-4e61-8f1e-6f926d1ddc69@github.com>

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

Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:

  fix last minute typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9074/files
  - new: https://git.openjdk.java.net/jdk/pull/9074/files/7c739f77..13fe3060

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

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

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

From kvn at openjdk.java.net  Wed Jun  8 18:06:32 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 8 Jun 2022 18:06:32 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v2]
In-Reply-To: <AVvBOfxDwSVIcUpLEWJgDa5vcWrg19woaMdan40Q8C4=.f932b386-3688-4e61-8f1e-6f926d1ddc69@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
 <AVvBOfxDwSVIcUpLEWJgDa5vcWrg19woaMdan40Q8C4=.f932b386-3688-4e61-8f1e-6f926d1ddc69@github.com>
Message-ID: <hNKocjSz7sfrqqKyE4X5Kf4NKHSaPu5ZXk1AUrMzT60=.344e5ee2-9a2f-407f-9e2a-ed9b58c7bd4a@github.com>

On Tue, 7 Jun 2022 23:49:09 GMT, Cesar Soares <duke at openjdk.java.net> wrote:

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

Nice work. I think we can target this for JDK 20. Please, update it to latest JDK - there are conflicts.

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

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

From kdnilsen at openjdk.java.net  Wed Jun  8 22:05:30 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 8 Jun 2022 22:05:30 GMT
Subject: RFR: Fix fullgc
Message-ID: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>

Two errors were recently discovered in the generational-mode implementation of FullGC:

1. There was an off-by-one error which caused full-gc to promote one cycle later than intent.
2. During a post-compaction phase of full-gc, certain old-gen regions were relabeled as young-gen, sometimes resulting in young-gen having usage above its capacity.  When this occurs, further allocations are blocked because available within young-gen is zero (actually is negative).

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

Commit messages:
 - Fix Full GC
 - Start young collect instead of old if mixed evacuations are pending
 - Filter out invalid pointers picked up by old gen SATB
 - Log messages for old and young only if is generational
 - Add log messages to degen and fuill GC
 - Do not make_regular_bypass without heap lock
 - Insert instrumentation for further testing
 - Fix full gc
 - Merge branch 'shenandoah-master' into shenandoah
 - Merge branch 'shenandoah-master' into shenandoah
 - ... and 10 more: https://git.openjdk.java.net/shenandoah/compare/5473b079...2a3943ce

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

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

From wkemper at openjdk.java.net  Wed Jun  8 22:48:04 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 8 Jun 2022 22:48:04 GMT
Subject: RFR: Fix fullgc
In-Reply-To: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>
References: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>
Message-ID: <U4FuNXQKihcnVUrBL4IK56Urr9gS1oKIQogSweO4GHs=.1422efc3-24b2-4950-b78f-3c5a5f06cafe@github.com>

On Wed, 8 Jun 2022 22:00:15 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Two errors were recently discovered in the generational-mode implementation of FullGC:
> 
> 1. There was an off-by-one error which caused full-gc to promote one cycle later than intent.
> 2. During a post-compaction phase of full-gc, certain old-gen regions were relabeled as young-gen, sometimes resulting in young-gen having usage above its capacity.  When this occurs, further allocations are blocked because available within young-gen is zero (actually is negative).

Does it make sense to remove the side-effect of `make_regular_bypass`. It's probably a vestige of an out-dated version of the generational support for Full GC.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 838:

> 836:     if (r->is_cset()) {
> 837:       // If generational, leave affiliation alone.
> 838:       r->make_regular_bypass(!is_generational);

So - if we are not in generational mode, we will set the affiliation to `YOUNG`, is that necessary when we are not in generational mode? Wouldn't it already be young (or free) in that mode?

And when we are in generational mode, we don't want to change the affiliation. Should we just remove this affiliation changing side-effect of `make_regular_bypass`?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1347:

> 1345:           ShenandoahHeapRegion* r = heap->get_region(c);
> 1346:           // Consider regions emptied by humongous evacuation to be young
> 1347:           r->make_regular_bypass(true);

If we remove the side-effect of `make_regular_bypass`, we would have something like:

if (r->is_humongous_start() || r->is_humongous_cont()) {
  r->set_affiliation(YOUNG);
}

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

Changes requested by wkemper (Committer).

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

From kdnilsen at openjdk.java.net  Wed Jun  8 23:15:57 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 8 Jun 2022 23:15:57 GMT
Subject: RFR: Fix fullgc
In-Reply-To: <U4FuNXQKihcnVUrBL4IK56Urr9gS1oKIQogSweO4GHs=.1422efc3-24b2-4950-b78f-3c5a5f06cafe@github.com>
References: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>
 <U4FuNXQKihcnVUrBL4IK56Urr9gS1oKIQogSweO4GHs=.1422efc3-24b2-4950-b78f-3c5a5f06cafe@github.com>
Message-ID: <SnPW5Zkn3OMRjTZQ0LdkezfQoJRGlPLCT-qqzdg0GKk=.24ceb8bf-ac42-47cb-a39c-a9ef3d56f0e4@github.com>

On Wed, 8 Jun 2022 22:37:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Two errors were recently discovered in the generational-mode implementation of FullGC:
>> 
>> 1. There was an off-by-one error which caused full-gc to promote one cycle later than intent.
>> 2. During a post-compaction phase of full-gc, certain old-gen regions were relabeled as young-gen, sometimes resulting in young-gen having usage above its capacity.  When this occurs, further allocations are blocked because available within young-gen is zero (actually is negative).
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 838:
> 
>> 836:     if (r->is_cset()) {
>> 837:       // If generational, leave affiliation alone.
>> 838:       r->make_regular_bypass(!is_generational);
> 
> So - if we are not in generational mode, we will set the affiliation to `YOUNG`, is that necessary when we are not in generational mode? Wouldn't it already be young (or free) in that mode?
> 
> And when we are in generational mode, we don't want to change the affiliation. Should we just remove this affiliation changing side-effect of `make_regular_bypass`?

You raise good questions here.  I was not sure why make_regular_bypass() wanted to overwrite affiliation with young.  I knew it shouldn't do it in the case I was observing.  I was trying to effect only my use case so as not to break other "use cases".

I'll think a bit harder on this.

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

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

From wkemper at openjdk.java.net  Thu Jun  9 17:29:16 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Jun 2022 17:29:16 GMT
Subject: RFR: Reserve regions for the collector according to generational
 reserves
Message-ID: <C8YzZulgjZgF4_tPz_VCGpBm-tPrJIzgZ4sBMhnrN00=.39bad5c0-c5d9-4e47-98b6-1281a78eb6d0@github.com>

When the freeset is rebuilt, it reserves a number of regions for evacuation proportional to the total size of the heap. With default settings, this will reserve more regions than intended for the generational mode and may lead to premature allocation failures for mutators.

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

Commit messages:
 - Reserve regions for the collector according to generational reserves

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

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

From kdnilsen at openjdk.java.net  Thu Jun  9 18:22:52 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 9 Jun 2022 18:22:52 GMT
Subject: RFR: Reserve regions for the collector according to generational
 reserves
In-Reply-To: <C8YzZulgjZgF4_tPz_VCGpBm-tPrJIzgZ4sBMhnrN00=.39bad5c0-c5d9-4e47-98b6-1281a78eb6d0@github.com>
References: <C8YzZulgjZgF4_tPz_VCGpBm-tPrJIzgZ4sBMhnrN00=.39bad5c0-c5d9-4e47-98b6-1281a78eb6d0@github.com>
Message-ID: <voVCJJtEOJgTPVsMcwjmEk-iWKC57PqAXyaUdhnQjHQ=.102f7b8e-5d1e-4323-b7ba-73c7807abe27@github.com>

On Thu, 9 Jun 2022 17:22:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the freeset is rebuilt, it reserves a number of regions for evacuation proportional to the total size of the heap. With default settings, this will reserve more regions than intended for the generational mode and may lead to premature allocation failures for mutators.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.java.net  Thu Jun  9 18:26:29 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 9 Jun 2022 18:26:29 GMT
Subject: Integrated: Reserve regions for the collector according to
 generational reserves
In-Reply-To: <C8YzZulgjZgF4_tPz_VCGpBm-tPrJIzgZ4sBMhnrN00=.39bad5c0-c5d9-4e47-98b6-1281a78eb6d0@github.com>
References: <C8YzZulgjZgF4_tPz_VCGpBm-tPrJIzgZ4sBMhnrN00=.39bad5c0-c5d9-4e47-98b6-1281a78eb6d0@github.com>
Message-ID: <1KzWRg_u5hJMpFSCGq2E2O4YKyYBIqKYhZ9PAOerr00=.0c6e60b7-6396-486b-bd41-fceea7df3207@github.com>

On Thu, 9 Jun 2022 17:22:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When the freeset is rebuilt, it reserves a number of regions for evacuation proportional to the total size of the heap. With default settings, this will reserve more regions than intended for the generational mode and may lead to premature allocation failures for mutators.

This pull request has now been integrated.

Changeset: ea3191de
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/ea3191de45e97a4ad4f91f507dc85de0e51a04af
Stats:     20 lines in 2 files changed: 16 ins; 3 del; 1 mod

Reserve regions for the collector according to generational reserves

Reviewed-by: kdnilsen

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

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

From aph at openjdk.java.net  Fri Jun 10 10:40:24 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 10 Jun 2022 10:40:24 GMT
Subject: RFR: 8288181: AArch64: clean up out-of-date comments
Message-ID: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>

Some of the comments and enum constants in cpu/aarch64 date from the early days of the project and are no longer valid.

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

Commit messages:
 - More
 - More
 - 8288181: AArch64: clean up out-of-date comments

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

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

From shade at openjdk.java.net  Fri Jun 10 11:10:00 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Jun 2022 11:10:00 GMT
Subject: RFR: 8288181: AArch64: clean up out-of-date comments
In-Reply-To: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
References: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
Message-ID: <cVvevlcgDd8LhedcO9gi45z6g5FCJm2AfBjZytyq1UI=.78945395-1c87-496b-b60d-36423e0471bc@github.com>

On Fri, 10 Jun 2022 10:30:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Some of the comments and enum constants in cpu/aarch64 date from the early days of the project and are no longer valid.

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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

From aph at openjdk.java.net  Fri Jun 10 13:31:03 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 10 Jun 2022 13:31:03 GMT
Subject: Integrated: 8288181: AArch64: clean up out-of-date comments
In-Reply-To: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
References: <eQ9QLZrLR8twsIjg3mnMtLKYeBlrvM1W7v9Rpj95fEQ=.dc27cc4a-3a0f-4807-8c90-b73c82d06213@github.com>
Message-ID: <7a-a1ffFIyd6xUWsrLYIV7PeFlonL6ZYg_X38ElK6lY=.71f5242b-2d84-4af7-bf0d-bc93209fd1f2@github.com>

On Fri, 10 Jun 2022 10:30:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Some of the comments and enum constants in cpu/aarch64 date from the early days of the project and are no longer valid.

This pull request has now been integrated.

Changeset: bdd64d6f
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bdd64d6f7d5cbb470fc951174145602647d1c283
Stats:     18 lines in 7 files changed: 0 ins; 5 del; 13 mod

8288181: AArch64: clean up out-of-date comments

Reviewed-by: shade

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

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

From kdnilsen at openjdk.java.net  Sun Jun 12 02:49:48 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Sun, 12 Jun 2022 02:49:48 GMT
Subject: RFR: Fix fullgc [v2]
In-Reply-To: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>
References: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>
Message-ID: <3SHVgBAintpi0HnBTl4YWEGAttm_4wSrvFN-QZ2ef-0=.de4d1802-6621-4ca2-a9b4-980a9159dca2@github.com>

> Two errors were recently discovered in the generational-mode implementation of FullGC:
> 
> 1. There was an off-by-one error which caused full-gc to promote one cycle later than intent.
> 2. During a post-compaction phase of full-gc, certain old-gen regions were relabeled as young-gen, sometimes resulting in young-gen having usage above its capacity.  When this occurs, further allocations are blocked because available within young-gen is zero (actually is negative).

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

 - Be more careful about changing affiliation to YOUNG
 - Remove affiliation overwrite side effect from make_regular_bypass
   
   This change makes the code more clear and easier to maintain.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/142/files
  - new: https://git.openjdk.org/shenandoah/pull/142/files/2a3943ce..24349b5e

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

  Stats: 35 lines in 3 files changed: 25 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/142.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/142/head:pull/142

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

From kdnilsen at openjdk.java.net  Sun Jun 12 02:55:37 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Sun, 12 Jun 2022 02:55:37 GMT
Subject: RFR: Fix fullgc [v2]
In-Reply-To: <U4FuNXQKihcnVUrBL4IK56Urr9gS1oKIQogSweO4GHs=.1422efc3-24b2-4950-b78f-3c5a5f06cafe@github.com>
References: <HMf2t3KxwFVTiR1bocA_Z0k4s8fwKucsXFjwABjz57I=.92040f92-6d71-4b8f-90ee-6640e30b1eb7@github.com>
 <U4FuNXQKihcnVUrBL4IK56Urr9gS1oKIQogSweO4GHs=.1422efc3-24b2-4950-b78f-3c5a5f06cafe@github.com>
Message-ID: <bPBAiYBTWmyR9oDvWuGv3e1b99v3c1gPLsfezAU2q_0=.018be514-4552-4846-9c83-e665bfb32b24@github.com>

On Wed, 8 Jun 2022 22:41:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Be more careful about changing affiliation to YOUNG
>>  - Remove affiliation overwrite side effect from make_regular_bypass
>>    
>>    This change makes the code more clear and easier to maintain.
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1347:
> 
>> 1345:           ShenandoahHeapRegion* r = heap->get_region(c);
>> 1346:           // Consider regions emptied by humongous evacuation to be young
>> 1347:           r->make_regular_bypass(true);
> 
> If we remove the side-effect of `make_regular_bypass`, we would have something like:
> 
> if (r->is_humongous_start() || r->is_humongous_cont()) {
>   r->set_affiliation(YOUNG);
> }

I've implemented and tested a change that removes the change-affiliation side effect of make_regular_bypass.

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

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

From duke at openjdk.java.net  Tue Jun 14 00:32:24 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 14 Jun 2022 00:32:24 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v3]
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <kHNZMo5ZoHxU--J0NIq3PAQ_LGCTqfGIMqBrx68euAk=.a74525f6-4dcc-4f11-b208-dee160805374@github.com>

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

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

 - update with master
 - fix last minute typo
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - work
 - ... and 13 more: https://git.openjdk.org/jdk/compare/a9c2ab67...fbb8cb1c

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

Changes: https://git.openjdk.org/jdk/pull/9074/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9074&range=02
  Stats: 2392 lines in 48 files changed: 117 ins; 331 del; 1944 mod
  Patch: https://git.openjdk.org/jdk/pull/9074.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9074/head:pull/9074

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

From duke at openjdk.java.net  Tue Jun 14 03:56:47 2022
From: duke at openjdk.java.net (Cesar Soares)
Date: Tue, 14 Jun 2022 03:56:47 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v4]
In-Reply-To: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
Message-ID: <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>

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

Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:

  fix merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9074/files
  - new: https://git.openjdk.org/jdk/pull/9074/files/fbb8cb1c..8ebb3dca

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

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

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

From kdnilsen at openjdk.java.net  Tue Jun 14 20:14:48 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Jun 2022 20:14:48 GMT
Subject: RFR: Improve humongous remset scan
Message-ID: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>

These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

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

Commit messages:
 - Merge remote-tracking branch 'GitFarmBranch/optimize-humongous-remset-scan' into improve-humongous-remset-scan
 - Fix handling of humongous continuation regions
 - Merge branch 'optimize-humongous-remset-scan' of ssh://git.amazon.com/pkg/OpenJDKTipSrc into optimize-humongous-remset-scan
 - Start young collect instead of old if mixed evacuations are pending
 - Filter out invalid pointers picked up by old gen SATB
 - Fix typo in assertion
 - Add missing semicolon
 - Another fix to round-up calculation
 - Fix error in round-up calculation
 - Require humongous slice to be multiple of card size
 - ... and 14 more: https://git.openjdk.org/shenandoah/compare/a8676f6d...3b558e0a

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

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

From wkemper at openjdk.java.net  Tue Jun 14 20:33:13 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 14 Jun 2022 20:33:13 GMT
Subject: RFR: Improve humongous remset scan
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <fHrHaH8GAhM90yKCY1NIW1p18LBie44-mKl7yLvfRF4=.0a83977d-f193-44a6-af46-3b533b462704@github.com>

On Tue, 14 Jun 2022 20:09:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

I'm sorry, I'm missing how this splits the humongous object across threads. It reads as though every thread that encounters any region from this humongous object will scan it.

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

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

From kdnilsen at openjdk.java.net  Tue Jun 14 21:55:13 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Jun 2022 21:55:13 GMT
Subject: RFR: Improve humongous remset scan
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <kAoSX1F1w32nKUtgu5--lknFCof5td-obrk7_b0-lmU=.4f146da0-1805-4199-9442-50fd118f31a1@github.com>

On Tue, 14 Jun 2022 20:09:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

Before this change, a single thread would scan the entire humongous object, even if the object spans multiple regions.  With this change, different worker threads will be able to scan different parts of the humongous object.  The other improvement here is that when a thread is scanning a humongous object, it only scans the portions of the humongous object that are spanned by DIRTY remembered set cards.  Previously, the entire humongous object was scanned by a single thread.

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

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

From wkemper at openjdk.java.net  Tue Jun 14 22:39:27 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 14 Jun 2022 22:39:27 GMT
Subject: RFR: Improve humongous remset scan
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <lIjHbObk_2MZq2_TBnOH_4hS4La6ER_mBqY11DdcK5Q=.b505216d-d360-446a-a457-d07232c29ee1@github.com>

On Tue, 14 Jun 2022 20:09:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

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

> 583: // DO NOT CANCEL.  If this worker thread has accepted responsibility for scanning a particular range of addresses, it
> 584: // must finish the work before it can be cancelled.
> 585: void ShenandoahHeapRegion::oop_iterate_humongous_slice(OopIterateClosure* blk, bool dirty_only,

Should this also be used during marking scan?

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

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

From wkemper at openjdk.java.net  Tue Jun 14 22:54:06 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 14 Jun 2022 22:54:06 GMT
Subject: RFR: Improve humongous remset scan
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <jjG6LnL_qpjhtNbCW9X8jy4jn4ig_uKW2km_K0fH6Oo=.721b9b4e-90d7-4542-9c35-00280baa77bf@github.com>

On Tue, 14 Jun 2022 20:09:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2464:

> 2462:               // old-gen heap regions.
> 2463:               if (r->is_humongous()) {
> 2464:                 // Need to examine both dirty and clean cards during mixed evac.

Sorry, I'm not seeing it. This code looks like it will compute the same `end_of_object` for every region in the humongous object (line 2468), but `start_of_scan` will be `r->bottom`. It seems like this code will have every thread that encounters a region in the humongous object scan the regions between `r` and `end_of_object`. The original method `oop_iterate_humongous` would scan only between `r->bottom` and `r->top`. Maybe we want `end_of_object` to be `r->top` and combine that with only scanning dirty cards?

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

> 619:     // Scan all data, regardless of whether cards are dirty
> 620:     while (num_cards-- > 0) {
> 621:       obj->oop_iterate(blk, MemRegion(start, start + CardTable::card_size_in_words()));

Could this just be `obj->oop_iterate(blk, MemRegion(start, start + CardTable::card_size_in_words() * num_cards))`?

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

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

From wkemper at openjdk.java.net  Tue Jun 14 22:54:07 2022
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 14 Jun 2022 22:54:07 GMT
Subject: RFR: Improve humongous remset scan
In-Reply-To: <jjG6LnL_qpjhtNbCW9X8jy4jn4ig_uKW2km_K0fH6Oo=.721b9b4e-90d7-4542-9c35-00280baa77bf@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
 <jjG6LnL_qpjhtNbCW9X8jy4jn4ig_uKW2km_K0fH6Oo=.721b9b4e-90d7-4542-9c35-00280baa77bf@github.com>
Message-ID: <KHXvwOefLfRbKa60YJTQ-uibUFnUPpicPrum5u24yd4=.05b00ac0-56d5-4383-8328-71bd353feb01@github.com>

On Tue, 14 Jun 2022 22:44:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2464:
> 
>> 2462:               // old-gen heap regions.
>> 2463:               if (r->is_humongous()) {
>> 2464:                 // Need to examine both dirty and clean cards during mixed evac.
> 
> Sorry, I'm not seeing it. This code looks like it will compute the same `end_of_object` for every region in the humongous object (line 2468), but `start_of_scan` will be `r->bottom`. It seems like this code will have every thread that encounters a region in the humongous object scan the regions between `r` and `end_of_object`. The original method `oop_iterate_humongous` would scan only between `r->bottom` and `r->top`. Maybe we want `end_of_object` to be `r->top` and combine that with only scanning dirty cards?

Or, in this case, since we don't care about cards being dirty and we will scan the whole region, could just use the original method?

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

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

From kdnilsen at openjdk.java.net  Tue Jun 14 23:02:15 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 14 Jun 2022 23:02:15 GMT
Subject: RFR: Improve humongous remset scan
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <U_8HvUeIogQ-FDtBqHf4q5gghSdb84fqzhP3OFGf6zk=.bba2482f-c0f8-426f-b559-961cbd60ee88@github.com>

On Tue, 14 Jun 2022 20:09:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2471:

> 2469:                 HeapWord* start_of_scan = r->bottom();
> 2470:                 size_t card_size_in_words = CardTable::card_size_in_words();
> 2471:                 size_t words_to_scan = end_of_object - start_of_scan;

With some "last minute" editing, I introduced an error here.  This code should scan to end of region or end of object, whichever comes first.  William is correct to point out that we are rescanning portions of humongous objects multiple times.

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

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

From kdnilsen at openjdk.java.net  Wed Jun 15 00:28:12 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 15 Jun 2022 00:28:12 GMT
Subject: RFR: Improve humongous remset scan [v2]
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <UcHZyw6CZvlds777hxbCsE-pkZxpY5WESUSb1EQq1C8=.b7341cdc-0e82-4eaf-8ef3-7b59d9c96be6@github.com>

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

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

  Improvements requested by reviewer

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/144/files
  - new: https://git.openjdk.org/shenandoah/pull/144/files/3b558e0a..0d7388ad

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

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

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

From iklam at openjdk.java.net  Thu Jun 16 03:30:49 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 16 Jun 2022 03:30:49 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
Message-ID: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>

HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.

iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.

This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

Commit messages:
 - fixed Shenandoah build
 - 8288537: Refactor hotspot/share/memory/iterator.hpp

Changes: https://git.openjdk.org/jdk/pull/9176/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9176&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288537
  Stats: 568 lines in 28 files changed: 337 ins; 214 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9176.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9176/head:pull/9176

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

From kdnilsen at openjdk.java.net  Thu Jun 16 04:01:52 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 16 Jun 2022 04:01:52 GMT
Subject: RFR: Improve humongous remset scan [v2]
In-Reply-To: <KHXvwOefLfRbKa60YJTQ-uibUFnUPpicPrum5u24yd4=.05b00ac0-56d5-4383-8328-71bd353feb01@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
 <jjG6LnL_qpjhtNbCW9X8jy4jn4ig_uKW2km_K0fH6Oo=.721b9b4e-90d7-4542-9c35-00280baa77bf@github.com>
 <KHXvwOefLfRbKa60YJTQ-uibUFnUPpicPrum5u24yd4=.05b00ac0-56d5-4383-8328-71bd353feb01@github.com>
Message-ID: <NwXbFGtfsWyf4P0DRzb5M0123LG424D1tlbemeSQc2U=.3f01731d-f5bf-4cdd-a88b-4b64e80fa0a4@github.com>

On Tue, 14 Jun 2022 22:50:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2464:
>> 
>>> 2462:               // old-gen heap regions.
>>> 2463:               if (r->is_humongous()) {
>>> 2464:                 // Need to examine both dirty and clean cards during mixed evac.
>> 
>> Sorry, I'm not seeing it. This code looks like it will compute the same `end_of_object` for every region in the humongous object (line 2468), but `start_of_scan` will be `r->bottom`. It seems like this code will have every thread that encounters a region in the humongous object scan the regions between `r` and `end_of_object`. The original method `oop_iterate_humongous` would scan only between `r->bottom` and `r->top`. Maybe we want `end_of_object` to be `r->top` and combine that with only scanning dirty cards?
>
> Or, in this case, since we don't care about cards being dirty and we will scan the whole region, could just use the original method?

Agree that it is easier to just call the original function here.  Thanks for your insight.

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

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

From kdnilsen at openjdk.java.net  Thu Jun 16 04:01:53 2022
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 16 Jun 2022 04:01:53 GMT
Subject: RFR: Improve humongous remset scan [v2]
In-Reply-To: <lIjHbObk_2MZq2_TBnOH_4hS4La6ER_mBqY11DdcK5Q=.b505216d-d360-446a-a457-d07232c29ee1@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
 <lIjHbObk_2MZq2_TBnOH_4hS4La6ER_mBqY11DdcK5Q=.b505216d-d360-446a-a457-d07232c29ee1@github.com>
Message-ID: <Cs4bly3PSskxD5v9OYcKZVk9T5qMZgkZyShf30CoVgM=.f0dcdd8f-bac4-43ca-b601-eec46136f61e@github.com>

On Tue, 14 Jun 2022 22:35:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improvements requested by reviewer
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 585:
> 
>> 583: // DO NOT CANCEL.  If this worker thread has accepted responsibility for scanning a particular range of addresses, it
>> 584: // must finish the work before it can be cancelled.
>> 585: void ShenandoahHeapRegion::oop_iterate_humongous_slice(OopIterateClosure* blk, bool dirty_only,
> 
> Should this also be used during marking scan?

There is a similar solution that divides the humongous regions into slices smaller than the full region size, but this is planned for a future pull request.  It is less critical to divide into smaller slices during update refs because the "structure" of update references allows some worker threads to begin updating old-gen references even before all threads have finished updating references within young-gen.

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 621:
> 
>> 619:     // Scan all data, regardless of whether cards are dirty
>> 620:     while (num_cards-- > 0) {
>> 621:       obj->oop_iterate(blk, MemRegion(start, start + CardTable::card_size_in_words()));
> 
> Could this just be `obj->oop_iterate(blk, MemRegion(start, start + CardTable::card_size_in_words() * num_cards))`?

Yes.  Thanks.

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

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

From stefank at openjdk.java.net  Thu Jun 16 08:15:08 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 16 Jun 2022 08:15:08 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <kxjlvL4odFG-u_IZ6phX777IK5pT6xZPqbgaNrEfVk8=.b4b574e9-12aa-4860-a2c4-b3a2950c1516@github.com>

On Thu, 16 Jun 2022 02:14:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

Even though the name sounds generic, the Devirtualizer class was written to support the oop_iterate / OopIterateClosure devirtualization. (Maybe a hint that this should be renamed)

This patch splits the implementation of this devirtualization into two different files. I think that's unfortunate. I'd rather see that we kept that code together. Maybe move all the code into a new oopIterateClosure.inline.hpp file.

However, if you do so, you'll find that we would almost move all the code out of iterator.inline.hpp. To me that makes it unclear how much the move of the Devirtualizer contributed to the fixed compilation time.

Since this patch moves two completely separate closures, could you repurpose this PR to only move the SerializeClosure, so that we can evaluate the move of the OopIterateClosure separately?

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

Changes requested by stefank (Reviewer).

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

From iklam at openjdk.org  Thu Jun 16 15:28:47 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 16 Jun 2022 15:28:47 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
In-Reply-To: <kxjlvL4odFG-u_IZ6phX777IK5pT6xZPqbgaNrEfVk8=.b4b574e9-12aa-4860-a2c4-b3a2950c1516@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <kxjlvL4odFG-u_IZ6phX777IK5pT6xZPqbgaNrEfVk8=.b4b574e9-12aa-4860-a2c4-b3a2950c1516@github.com>
Message-ID: <ngCven4rd6ujy-8nIfzu1iHIMkAjhqyNLKXGjOoOGOg=.351af1e1-61a6-4cc9-894b-fec29865c9fb@github.com>

On Thu, 16 Jun 2022 08:11:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Even though the name sounds generic, the Devirtualizer class was written to support the oop_iterate / OopIterateClosure devirtualization. (Maybe a hint that this should be renamed)
> 
> This patch splits the implementation of this devirtualization into two different files. I think that's unfortunate. I'd rather see that we kept that code together. Maybe move all the code into a new oopIterateClosure.inline.hpp file.
> 
> However, if you do so, you'll find that we would almost move all the code out of iterator.inline.hpp. To me that makes it unclear how much the move of the Devirtualizer contributed to the fixed compilation time.
> 
> Since this patch moves two completely separate closures, could you repurpose this PR to only move the SerializeClosure, so that we can evaluate the move of the OopIterateClosure separately?

The main problem is:

- Devirtualizer inline functions are simpler, but they are needed by many object files
- OopIterateClosure inline functions are complex (and have lots of dependencies, due to the expansion of `OopOopIterateDispatch::Table::Table()`), but they are needed by very few object files

Here's the output of https://urldefense.com/v3/__https://github.com/iklam/tools/blob/main/headers/whoincludes.tcl__;!!ACWV5N9M2RV99hQ!PwCrsqzCaEUD7fa9KqHgab_l8eJxF6NukrKgikTQ__WL2qnxtbl7aJdFw4PUHa_vUOUaAQa04_ahltyq8pePug$ :

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

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

From wkemper at openjdk.org  Thu Jun 16 21:19:34 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Jun 2022 21:19:34 GMT
Subject: RFR: Improve humongous remset scan [v2]
In-Reply-To: <UcHZyw6CZvlds777hxbCsE-pkZxpY5WESUSb1EQq1C8=.b7341cdc-0e82-4eaf-8ef3-7b59d9c96be6@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
 <UcHZyw6CZvlds777hxbCsE-pkZxpY5WESUSb1EQq1C8=.b7341cdc-0e82-4eaf-8ef3-7b59d9c96be6@github.com>
Message-ID: <7b0eN7bV4ywcxLJONXc4YTHwVyt0go7atyYXJvhefs4=.8d25934b-cb7b-4478-b6bc-8e62da0c74c2@github.com>

On Wed, 15 Jun 2022 00:28:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improvements requested by reviewer

Marked as reviewed by wkemper (Committer).

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

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

From kdnilsen at openjdk.org  Fri Jun 17 01:14:16 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Jun 2022 01:14:16 GMT
Subject: Integrated: Improve humongous remset scan
In-Reply-To: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
References: <nWFTDtZWgKBbsrSq1dBOWbHaiSwm-h7fkml_diO2gXM=.f1535332-2ceb-4804-b5f1-d265b33e3939@github.com>
Message-ID: <nT1UnXELyOLMVAdC2570nWS82ZFMGBINjTpjzoKGFos=.1db700f4-b264-4cdf-bdc9-72e4f8e19b41@github.com>

On Tue, 14 Jun 2022 20:09:14 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> These changes allow humongous objects residing within the remembered set to be scanned by muitiple concurrent GC worker threads, allowing more efficient parallelization of the remembered set scanning effort.

This pull request has now been integrated.

Changeset: a5aa4130
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/a5aa41308961c28eb4534191f6346d78ff27b290
Stats:     58 lines in 3 files changed: 58 ins; 0 del; 0 mod

Improve humongous remset scan

Reviewed-by: wkemper

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

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

From stefank at openjdk.org  Fri Jun 17 08:59:50 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 08:59:50 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <l_KumqJN1pT0_6oOOg310YZkoKybb28dP0jMUSsiUAg=.f50bb97c-ca4d-401b-a42a-1a580a19db3e@github.com>

On Thu, 16 Jun 2022 02:14:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

I forgot that Loom hijacked Devirtualizer for the derived oops processing. This devirtualization is not needed. The compiler sees the correct type and performs the correct inlining anyway. Before the integration of Loom I removed the usage of Devirtualizer::do_bit and verified that the compiler generated the same code (though I forgot to remove function).

I took and tested removing Devirtualizer::do_derived_oops, and again, the compiler generated the same code. So, simplest would be to just remove that function and the include of iterator.inline.hpp. However, if you still want to do this separation, then I guess that's OK as well. Could you move the Devirtualizer class to utilities/ instead of oops/, given that it's not necessarily oops that we are visiting? Maybe also update the comment to not mention OopClosureType.

Sounds good to move the OopIterateDispatch code to oops/oopIterateDispatch.

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

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

From iklam at openjdk.org  Fri Jun 17 15:05:05 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:05:05 GMT
Subject: RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp [v2]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <8VmvMkmeRKrAzYr6f7dIOE4GFBzu6tmsOFG33LnIPOM=.92915b50-5906-40e7-aaf0-1fbb18ae70bb@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

 - moved memory/devirtualizer.hpp -> utilities/devirtualizer.hpp
 - separate out the changes related to SerializeClosure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/ebb83152..159e9530

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

  Stats: 208 lines in 26 files changed: 75 ins; 126 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9176.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9176/head:pull/9176

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

From iklam at openjdk.org  Fri Jun 17 15:13:57 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:13:57 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

  renamed include guard macro

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/159e9530..ba07ef2c

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

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

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

From iklam at openjdk.org  Fri Jun 17 15:13:58 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 17 Jun 2022 15:13:58 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp
In-Reply-To: <l_KumqJN1pT0_6oOOg310YZkoKybb28dP0jMUSsiUAg=.f50bb97c-ca4d-401b-a42a-1a580a19db3e@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <l_KumqJN1pT0_6oOOg310YZkoKybb28dP0jMUSsiUAg=.f50bb97c-ca4d-401b-a42a-1a580a19db3e@github.com>
Message-ID: <edSca0RNQSfJxsa8OUi4vbCBKtcprD07zatmi6b1nTg=.85c16128-3e65-4ddd-a374-4064c1e61c65@github.com>

On Fri, 17 Jun 2022 08:55:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I forgot that Loom hijacked Devirtualizer for the derived oops processing. This devirtualization is not needed. The compiler sees the correct type and performs the correct inlining anyway. Before the integration of Loom I removed the usage of Devirtualizer::do_bit and verified that the compiler generated the same code (though I forgot to remove function).
> 
> I took and tested removing Devirtualizer::do_derived_oops, and again, the compiler generated the same code. So, simplest would be to just remove that function and the include of iterator.inline.hpp. However, if you still want to do this separation, then I guess that's OK as well. Could you move the Devirtualizer class to utilities/ instead of oops/, given that it's not necessarily oops that we are visiting? Maybe also update the comment to not mention OopClosureType.
> 
> Sounds good to move the OopIterateDispatch code to oops/oopIterateDispatch.

I think it's still useful to move Devirtualizer out in case it might be used in the future by other code. I've backed out the changes related to SerializeClosure, and moved the header to utilities/devirtualizer.hpp.

If you want to do the Loom cleanup, I'll leave it up to you :-)

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

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

From stefank at openjdk.org  Fri Jun 17 20:18:01 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 17 Jun 2022 20:18:01 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
Message-ID: <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>

On Fri, 17 Jun 2022 15:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
>> 
>> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
>> 
>> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed include guard macro

Sounds good to me :)

src/hotspot/share/utilities/devirtualizer.inline.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.

Since these new files are mainly copied code, would you mind retaining the copyright dates. Right now this look like newly created code.

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

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

From coleenp at openjdk.org  Fri Jun 17 20:53:53 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 17 Jun 2022 20:53:53 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
Message-ID: <e_1KhnRerWPFNH_xXcGxLzoMi5L4TakYlgH2cZf92Ts=.2bfb6a1a-6616-4a31-8f06-f6ef47a7f9f9@github.com>

On Fri, 17 Jun 2022 15:13:57 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
>> 
>> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
>> 
>> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed include guard macro

Looks like an improvement.

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

Marked as reviewed by coleenp (Reviewer).

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

From coleenp at openjdk.org  Mon Jun 20 15:59:16 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 20 Jun 2022 15:59:16 GMT
Subject: RFR: 8288752: Split thread implementation files
Message-ID: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>

This changes splits thread.hpp/cpp into javaThread, and threads files.

I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.

I didn't update the copyrights to save diffs but will before integration.
Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.

Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

Commit messages:
 - Remove more includes, alphatize forward declarations.
 - Make compile on all platforms (including ppc, s390 and zero)
 - rename os_cpu/thread_os_cpu.{hpp,cpp} to os_cpu/javaThread_os_cpu.{hpp,cpp}
 - Separate thread.hpp into thread.hpp, javaThread.hpp and threads.hpp.
 - include thread.hpp not thread.inline.hpp unless inline is needed
 - Builds with javaThread.inline.hpp
 - Split thread.cpp into thread.cpp,javaThread.cpp and threads.cpp files.

Changes: https://git.openjdk.org/jdk/pull/9218/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288752
  Stats: 10819 lines in 369 files changed: 5470 ins; 5159 del; 190 mod
  Patch: https://git.openjdk.org/jdk/pull/9218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9218/head:pull/9218

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

From dholmes at openjdk.org  Mon Jun 20 23:59:00 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Jun 2022 23:59:00 GMT
Subject: RFR: 8288752: Split thread implementation files
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <i82Ufph9gUFIYDOpJgzx2wlht00tRRsg_Bvx2BAzAR8=.11b22968-d10d-49a6-80e2-76698a2ddff6@github.com>

On Mon, 20 Jun 2022 15:49:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Hi Coleen,

The changes in themselves seem fine to me - I only skimmed things, mainly looking at the new files.  It is a very large refactoring so there will be an impact on backports naturally.

I'm not sure this will save much in terms of build time inclusions (how many files only include thread.hpp now?) but the code structure/management benefits of this are more important anyway. (Though I must confess in a remote terminal using vi I appreciate everything being in one file. :) ).

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From iklam at openjdk.org  Tue Jun 21 05:29:35 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 05:29:35 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v4]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <UPDebkAy294P9aDAgNw682Q-55pvEJxJiP2zGJY18Qs=.ca67ad88-21c1-4789-8c9d-3e4cfbbca759@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

  Updated copyright year to 2018, where the Devirtualizer class was first added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/ba07ef2c..ab986620

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

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

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

From iklam at openjdk.org  Tue Jun 21 05:29:36 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 05:29:36 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
 <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
Message-ID: <HWTNPgl89GOBsGZU8zXVNXEw2Ulr5Kh2W3AJreuWJoc=.e0ec72c2-be62-42b3-ae63-ce4440db3c5c@github.com>

On Fri, 17 Jun 2022 20:14:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed include guard macro
>
> src/hotspot/share/utilities/devirtualizer.inline.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Since these new files are mainly copied code, would you mind retaining the copyright dates. Right now this look like newly created code.

I updated the copyright year to 2018-2022, since the Devirtualizer class was first added in 2018 in [JDK-8204540](https://bugs.openjdk.org/browse/JDK-8204540)

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

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

From coleenp at openjdk.org  Tue Jun 21 12:22:46 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 12:22:46 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix Shenandoah build.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/32b02a42..ae864661

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

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

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

From stefank at openjdk.org  Tue Jun 21 14:14:56 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 21 Jun 2022 14:14:56 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v4]
In-Reply-To: <UPDebkAy294P9aDAgNw682Q-55pvEJxJiP2zGJY18Qs=.ca67ad88-21c1-4789-8c9d-3e4cfbbca759@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <UPDebkAy294P9aDAgNw682Q-55pvEJxJiP2zGJY18Qs=.ca67ad88-21c1-4789-8c9d-3e4cfbbca759@github.com>
Message-ID: <DdeP-PxbZY6tuaMO3BPjGMZKmI2o_ob6VidStUJfBcc=.b670d08c-6749-4595-9c0d-36c130753323@github.com>

On Tue, 21 Jun 2022 05:29:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
>> 
>> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
>> 
>> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year to 2018, where the Devirtualizer class was first added

Marked as reviewed by stefank (Reviewer).

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

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

From rehn at openjdk.org  Tue Jun 21 14:28:58 2022
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 21 Jun 2022 14:28:58 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
Message-ID: <ZFHC8q2TwxYYOPkrUVRnr--g7HQIm9tNssSOytGPBU8=.3f5d8ff9-3ce2-40a5-98b2-f48cccd062a7@github.com>

On Tue, 21 Jun 2022 12:22:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Shenandoah build.

Looks good, thanks.

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

Marked as reviewed by rehn (Reviewer).

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

From coleenp at openjdk.org  Tue Jun 21 15:32:15 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 15:32:15 GMT
Subject: RFR: 8288752: Split thread implementation files [v3]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <tINNpLPxhPITm7z_lq4kj2XYejOfXZYRgZD-gFKUPno=.aefb7f61-efdd-40d9-b79f-8ba74836f3c2@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix more GHA builds which are slightly different than what we do internally.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/ae864661..93cff18d

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

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

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

From coleenp at openjdk.org  Tue Jun 21 15:32:17 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 15:32:17 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
Message-ID: <miuUsCq-oGb6C91fLIx_JfA3nMWPiVoit7wIJFcm30s=.9faf9020-2079-4d85-b783-67c766fec3e0@github.com>

On Tue, 21 Jun 2022 12:22:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix Shenandoah build.

Thanks David and Robbin.
Unfortunately, this change will make backporting more difficult if we have backport changes from JDK 20.  I still think it's worth separating the thread files.  As a lowly 'vi' user, it's really helpful for me to see whether a field or function belongs to JavaThread or Thread without scrolling up and down the thread.hpp file.  I am guessing that there might be fields in one that really belongs in the other.  This makes it easier, at least for me, to see.

Thank you for the review, Robbin.

I'm still waiting for GHA to pass as I forgot about shenandoah and some of the other platforms build differently.  Also I'm waiting for @dcubed-ojdk changes to JDK 19 to be integrated and merged into JDK 20 first.

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

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

From iklam at openjdk.org  Tue Jun 21 18:02:40 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 18:02:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v3]
In-Reply-To: <tINNpLPxhPITm7z_lq4kj2XYejOfXZYRgZD-gFKUPno=.aefb7f61-efdd-40d9-b79f-8ba74836f3c2@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <tINNpLPxhPITm7z_lq4kj2XYejOfXZYRgZD-gFKUPno=.aefb7f61-efdd-40d9-b79f-8ba74836f3c2@github.com>
Message-ID: <r3qezyI9XyWyljNJnuut8CJMUNkeqzivDgDg5nLXT0g=.54bc31ed-a7b0-4d96-8bc5-09f6d83b9d0e@github.com>

On Tue, 21 Jun 2022 15:32:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix more GHA builds which are slightly different than what we do internally.

Marked as reviewed by iklam (Reviewer).

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

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

From iklam at openjdk.org  Tue Jun 21 18:10:43 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 18:10:43 GMT
Subject: RFR: 8288752: Split thread implementation files [v3]
In-Reply-To: <i82Ufph9gUFIYDOpJgzx2wlht00tRRsg_Bvx2BAzAR8=.11b22968-d10d-49a6-80e2-76698a2ddff6@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <i82Ufph9gUFIYDOpJgzx2wlht00tRRsg_Bvx2BAzAR8=.11b22968-d10d-49a6-80e2-76698a2ddff6@github.com>
Message-ID: <4PXKkWivdT-CTDMwNarYDw4XqioG-tr-I9x5PfXS6Jw=.8db3a172-ade0-448d-a703-c9526a3c67da@github.com>

On Mon, 20 Jun 2022 23:56:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Coleen,
> 
> The changes in themselves seem fine to me - I only skimmed things, mainly looking at the new files. It is a very large refactoring so there will be an impact on backports naturally.
> 
> I'm not sure this will save much in terms of build time inclusions (how many files only include thread.hpp now?) but the code structure/management benefits of this are more important anyway. (Though I must confess in a remote terminal using vi I appreciate everything being in one file. :) ).
> 
> Thanks.

Currently, as counted by https://urldefense.com/v3/__https://github.com/iklam/tools/blob/main/headers/whoincludes.tcl__;!!ACWV5N9M2RV99hQ!KF8R1O2hwrtPafZphREB48VWnVgmHJuCSg8hVT5SegKOlOYxst6cmalIjBN9kYRJ28VxXh6zedCfLPsCXGPZhw$ , there isn't much improvement in terms of build time:

Before this PR:
- thread.hpp was included 847 times

After this PR
- thread.hpp is included 848 times
- javaThread.hpp is included 843 times

One reason is in handles.hpp, which has implicit conversion from `JavaThread*` to `Thread*`. E.g., when you have:


void blah(TRAPS) {
    Handle h(THREAD, someOop);
   . ..
}


Anyway, I think this PR is a very important step towards faster build time. We can do further refactoring. E.g., avoid including handles.hpp unnecessarily in other .hpp files (and move offenders from .hpp to .inline.hpp, etc).

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

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

From iklam at openjdk.org  Tue Jun 21 18:31:30 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 18:31:30 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v5]
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <9HZIcFQ4y2BgfrZ0CUotalUSqJ2ZM4eVow8uLf_Ek-o=.93fc074e-2022-497e-8956-50a8a84adf14@github.com>

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

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

 - Merge branch 'master' of https://urldefense.com/v3/__https://github.com/openjdk/jdk__;!!ACWV5N9M2RV99hQ!O8w2sWDt0MPGVVEybWvls84TjgOspVeKMxwvedai04E5YO0iYMHybIxBFFgPQn2bWY3nW3FBHiUyFCpPS_mLRA$  into 8288537-refactor-iterator-hpp
 - Updated copyright year to 2018, where the Devirtualizer class was first added
 - renamed include guard macro
 - moved memory/devirtualizer.hpp -> utilities/devirtualizer.hpp
 - separate out the changes related to SerializeClosure
 - fixed Shenandoah build
 - 8288537: Refactor hotspot/share/memory/iterator.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9176/files
  - new: https://git.openjdk.org/jdk/pull/9176/files/ab986620..c2dce9be

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

  Stats: 4585 lines in 234 files changed: 2654 ins; 1047 del; 884 mod
  Patch: https://git.openjdk.org/jdk/pull/9176.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9176/head:pull/9176

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

From coleenp at openjdk.org  Tue Jun 21 19:19:03 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 19:19:03 GMT
Subject: RFR: 8288752: Split thread implementation files [v4]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <ARMIGfXJT7qW6ol3zhxFL2rjGwi4FXTv5alY0roFjYg=.ad83ae3d-8fb0-4f7e-b457-3d59e192bf1f@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/93cff18d..d2e93ca4

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

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

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

From coleenp at openjdk.org  Tue Jun 21 19:38:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 19:38:31 GMT
Subject: RFR: 8288752: Split thread implementation files [v5]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/d2e93ca4..b420c9e6

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

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

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

From duke at openjdk.org  Tue Jun 21 19:56:38 2022
From: duke at openjdk.org (Cesar Soares)
Date: Tue, 21 Jun 2022 19:56:38 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v4]
In-Reply-To: <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
 <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>
Message-ID: <AKP_zuoaCiQi7UyT-JrKA6kyOwR7YOJZVCGVbF0o06I=.0442b54b-b5f9-4d99-90a8-57d420038f59@github.com>

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

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

Hi again, can someone with access to a PPC64, S360, etc. help with testing this?

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

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

From coleenp at openjdk.org  Tue Jun 21 19:58:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 19:58:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v5]
In-Reply-To: <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
Message-ID: <GFQBmwY-urzhbLjiC7baSI06s3ZWxr6Rpin1_i61aMo=.9b5917d9-2f4a-48fd-8984-69cbd99c42ba@github.com>

On Tue, 21 Jun 2022 19:38:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

Thanks for reviewing, Ioi.  My intention was more modularity but it's disappointing that the build times don't improve since I culled several (too many, it seems) header files from thread.hpp. But as you said, this is a good step towards the goal of having less excess header file inclusions.

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

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

From coleenp at openjdk.org  Tue Jun 21 20:14:30 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 20:14:30 GMT
Subject: RFR: 8288752: Split thread implementation files [v6]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <QZ1Ymc69ofe-3C2mXXBJOQ783flbp4akYUjipC43Keg=.26bada92-3ece-424a-a469-4fd627721657@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/b420c9e6..5533cd46

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

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

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

From coleenp at openjdk.org  Tue Jun 21 20:17:29 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 20:17:29 GMT
Subject: RFR: 8288752: Split thread implementation files [v5]
In-Reply-To: <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <PqaTEdO-L1-44jmWspkj1JgiZ8pcLrCBD1u2mSAqJiA=.73bbb478-96a6-4d6a-bed4-a5948b2bf983@github.com>
Message-ID: <WyiJ8WUM3zpBYHvYCNHKQh2bMuJcCx71OFFT8dbQVdA=.e548dfee-cbe3-4c4c-a845-aa6db9ac053d@github.com>

On Tue, 21 Jun 2022 19:38:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

I took out #include "mutexLocker.hpp" from thread.hpp, so on the minimal variant, this isn't transitively included from some other file.

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

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

From iklam at openjdk.org  Tue Jun 21 20:58:43 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 20:58:43 GMT
Subject: RFR: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp [v3]
In-Reply-To: <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
 <Q9Dp4DEL0-0cW85FyEc5Rrj3KAZrTp3SgBPl4M75hpE=.35bb960f-52dc-4207-9b8b-8d10c23c514c@github.com>
 <pN0SP3F9lDoDnZKsrAvE3y_PLyjXu_8VTbQQd2E0aUY=.0afc8631-4a6b-47be-93de-2ba764500ea3@github.com>
Message-ID: <Ok0PdFL1pf5hatIZHVeedueJTsC8uDKaafW7U8GNe5I=.4c57b2d6-6c24-462d-be9a-f9585ff8c30e@github.com>

On Fri, 17 Jun 2022 20:13:33 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   renamed include guard macro
>
> Sounds good to me :)

Thanks @stefank @coleenp for the review.
Passes tier-1 and builds-tier5 in our CI. GHA seems to work, too.

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

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

From iklam at openjdk.org  Tue Jun 21 20:58:45 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 21 Jun 2022 20:58:45 GMT
Subject: Integrated: 8288537: Move Devirtualizer out of
 hotspot/share/memory/iterator.hpp
In-Reply-To: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
References: <YmP_QhQ-0xM3UXfgamThUSYX9KZZlK6SoXQ8OCyqt2E=.d1aff3f6-5727-4cac-b81b-6b1c65c12588@github.com>
Message-ID: <pd6owsItlo-Oy21zbiJh1S88k_NoqpM8LoK9SZb5sSQ=.af6e8606-5cbd-49f8-aa2c-b3cf59141e6e@github.com>

On Thu, 16 Jun 2022 02:14:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> HotSpot build time has regressed quite a bit since JDK 17 (1m46s vs 2m20s on my machine). Now it's time to do some header file cleanup.
> 
> iterator.hpp contains a hodge-podge of unrelated classes. Some of these classes have dependencies on other headers (e.g., `Devirtualizer` depends on bitMap.hpp) that slow down C++ compilation.
> 
> This patch moves two infrequently used classes, `Devirtualizer` and `SerializeClosure`, to their own header files. This reduces the total number of C++ lines compiled for libjvm.so for about 1%.

This pull request has now been integrated.

Changeset: 9f8bfab2
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f8bfab29009299e81f4929b5dbd399c21f34d7c
Stats:     387 lines in 15 files changed: 227 ins; 154 del; 6 mod

8288537: Move Devirtualizer out of hotspot/share/memory/iterator.hpp

Reviewed-by: stefank, coleenp

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

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

From dcubed at openjdk.org  Tue Jun 21 21:13:23 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 21:13:23 GMT
Subject: RFR: 8288752: Split thread implementation files [v2]
In-Reply-To: <miuUsCq-oGb6C91fLIx_JfA3nMWPiVoit7wIJFcm30s=.9faf9020-2079-4d85-b783-67c766fec3e0@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <u2dYxbf1yKByeonjS7hKZf65Rt-m7MDxJizh2qcrfzc=.e81340d8-5e11-4e4b-b67d-e07a482659d9@github.com>
 <miuUsCq-oGb6C91fLIx_JfA3nMWPiVoit7wIJFcm30s=.9faf9020-2079-4d85-b783-67c766fec3e0@github.com>
Message-ID: <UaIUC76MZLzMz47W2QLeY7pKPn4l13pWDWJhoQtZqMk=.99a129d7-4d8c-419f-940e-96a2c3f2ce92@github.com>

On Tue, 21 Jun 2022 15:25:00 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Also I'm waiting for @dcubed-ojdk changes to JDK 19 to be integrated and merged into JDK 20 first.

My three fixes have been integrated into JDK19. They have not yet been sync'ed
to JDK20. Thank you very much for waiting.

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

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

From coleenp at openjdk.org  Tue Jun 21 23:02:49 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 23:02:49 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  More GHA fixes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/5533cd46..a7eb45ee

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

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

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

From dcubed at openjdk.org  Tue Jun 21 23:31:39 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 21 Jun 2022 23:31:39 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
Message-ID: <Xpvd2YcWl3v7fpuvmFb1ntKY1hgr1Gdd19pQ1zNCeYU=.f7cc50b5-0d07-4857-9901-4eb567cc6d5c@github.com>

On Tue, 21 Jun 2022 23:02:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

My three fixes have been sync'ed from JDK19 to JDK20.

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

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

From coleenp at openjdk.org  Tue Jun 21 23:44:28 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 21 Jun 2022 23:44:28 GMT
Subject: RFR: 8288752: Split thread implementation files [v8]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <SAJZNym-6_2sTPVBfDjMI2j0xckEbKk0D891VW1b0IY=.77664d6b-a064-4d67-8589-b7cceeb13b4e@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

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

 - Add new files again
 - Merge branch 'master' into thread
 - More GHA fixes.
 - More GHA fixes.
 - More GHA fixes.
 - More GHA fixes.
 - Fix more GHA builds which are slightly different than what we do internally.
 - Fix Shenandoah build.
 - Remove more includes, alphatize forward declarations.
 - Make compile on all platforms (including ppc, s390 and zero)
 - ... and 5 more: https://git.openjdk.org/jdk/compare/2bf5c9a6...2eda69f4

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

Changes: https://git.openjdk.org/jdk/pull/9218/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=07
  Stats: 10904 lines in 383 files changed: 5517 ins; 5188 del; 199 mod
  Patch: https://git.openjdk.org/jdk/pull/9218.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9218/head:pull/9218

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

From coleenp at openjdk.org  Wed Jun 22 01:05:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 01:05:47 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Merge and testing in progress.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9218/files
  - new: https://git.openjdk.org/jdk/pull/9218/files/2eda69f4..d7c5c936

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9218&range=07-08

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

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

From coleenp at openjdk.org  Wed Jun 22 01:05:47 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 01:05:47 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <Xpvd2YcWl3v7fpuvmFb1ntKY1hgr1Gdd19pQ1zNCeYU=.f7cc50b5-0d07-4857-9901-4eb567cc6d5c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
 <Xpvd2YcWl3v7fpuvmFb1ntKY1hgr1Gdd19pQ1zNCeYU=.f7cc50b5-0d07-4857-9901-4eb567cc6d5c@github.com>
Message-ID: <ihrUHskGOko09Ija5pjqwriCSupUkFcHc6GqarTXwXM=.9c470418-dbe0-4e01-b48a-e8bc9dd3f227@github.com>

On Tue, 21 Jun 2022 23:28:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More GHA fixes.
>
> My three fixes have been sync'ed from JDK19 to JDK20.

@dcubed-ojdk Your changes are now in threads.cpp and javaThread.cpp/hpp.  Can you have a look to make sure they're correct?  They were straightforward to move.

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

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

From stuefe at openjdk.org  Wed Jun 22 08:04:40 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 22 Jun 2022 08:04:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <EnoOI4SgAKo2uKQcZskMiuT_TALi8eR9eS2By9bm73A=.e5d92655-b034-4ced-b694-7084475cdd38@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

I like this a lot :) Thanks for doing this. I put this into our CI, just to be sure, but since Aleksey added most of our platforms to GHAs I don't expect any surprises.

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

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

From dholmes at openjdk.org  Wed Jun 22 12:12:58 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Jun 2022 12:12:58 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <r225x-ZzIB9XNV8XG_1t7b3igFT-5SmqR3al4-hEiXg=.b3453101-21d2-47e9-89b6-87d4159bf22a@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Marked as reviewed by dholmes (Reviewer).

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

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

From coleenp at openjdk.org  Wed Jun 22 12:33:56 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 12:33:56 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <_nyxGukdOlO4uHbjFawmB4DdiMzrdzKdPFLc22m9ZnI=.f5fd94ad-ab38-4b59-aa34-81a3a6eecaf8@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Thank you Thomas.  All GHA finally passed as well as my internal testing.  I'm going to update the copyrights and push it before there's a conflict.  I apologize to anyone currently making changes to thread.cpp/hpp.

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

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

From coleenp at openjdk.org  Wed Jun 22 12:50:57 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 12:50:57 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <78l9rFqrnsnTome7w0Bcp4lGm-nNHRvbBpTSXsp9Ma4=.4163cd81-0e5d-442f-878c-48b1cb52574a@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Guidance says no copyright update. Thanks for reviewing.

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

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

From coleenp at openjdk.org  Wed Jun 22 12:53:59 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 12:53:59 GMT
Subject: Integrated: 8288752: Split thread implementation files
In-Reply-To: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
Message-ID: <bH2v_chVzX9woOhmVjScWGxz1hI2cviho17DfC-IAg0=.0be462a6-8fcd-47e1-85b2-483ce44aa4b9@github.com>

On Mon, 20 Jun 2022 15:49:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This changes splits thread.hpp/cpp into javaThread, and threads files.
> 
> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
> 
> I didn't update the copyrights to save diffs but will before integration.
> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
> 
> Tested with tier1-4 on Oracle supported platforms and built on other platforms.

This pull request has now been integrated.

Changeset: 270cf67e
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/270cf67e5ff19b082f710d52831f436dd144d883
Stats:     10905 lines in 383 files changed: 5518 ins; 5188 del; 199 mod

8288752: Split thread implementation files

Reviewed-by: dholmes, rehn, iklam

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

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

From shade at openjdk.org  Wed Jun 22 15:30:01 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jun 2022 15:30:01 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <bPtb_J668vBuNXq8xiX7BkpOvd60Q5j3yZJqnTAJfeg=.aba0a909-1e40-41ed-a4b9-827cd5c3b3a8@github.com>

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

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

Changes requested by shade (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 95:

> 93: class ShenandoahEvacuateUpdateRootClosureBase : public ShenandoahOopClosureBase {
> 94: protected:
> 95:     ShenandoahHeap* const _heap;

Here and later the indenting is a bit off: needs to be 2 spaces, not 4.

src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 99:

> 97:     inline ShenandoahEvacuateUpdateRootClosureBase();
> 98:     inline virtual void do_oop(oop* p);
> 99:     inline virtual void do_oop(narrowOop* p);

Do we have to make these functions `virtual`? I supposed we do templated closures exactly to avoid any sort of virtual method dispatching. Maybe I am missing something here...

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

> 142: template <bool atomic>
> 143: void ShenandoahEvacuateUpdateRootClosureBase<atomic>::do_oop(oop* p) {
> 144:   do_oop_work(p, Thread::current());

Not fond of calling `Thread::current()` on this hotpath. From the code, it looks like we only need it when actually calling `_heap->evacuate_object()`, can we move it there? 

Related: is `ShenandoahContextEvacuateUpdateRootsClosure::_thread` used now? Can we use it on some paths too?

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

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

From shade at openjdk.org  Wed Jun 22 15:32:36 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 22 Jun 2022 15:32:36 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom
In-Reply-To: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
Message-ID: <p_iO1ttgVdcBVplVIaTwdiBFkAv4xSoDu_pa-uMISBE=.0b1f6e39-43f9-46d3-9932-95570830a7e2@github.com>

On Mon, 6 Jun 2022 23:29:10 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64
> - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 
> - [x] hotspot_gc_shenandoah on AArch64

Looks mostly fine to me, but I have questions.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp line 72:

> 70:   ShenandoahNMethod::disarm_nmethod(nm);
> 71:   return true;
> 72: }

Nit: missing newline.

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

> 127: 
> 128: void ShenandoahCodeRoots::arm_nmethods() {
> 129:   BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods();

Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or?

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

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

From dcubed at openjdk.org  Wed Jun 22 19:30:42 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Jun 2022 19:30:42 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
Message-ID: <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>

On Tue, 21 Jun 2022 23:02:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More GHA fixes.

Sorry for the late review. I decided to try a crawl-thru review with this PR
and managed to get 1/3 done yesterday and the rest done today.

I very much like this PR. I think there's only one comment that will require a cleanup.

src/hotspot/cpu/zero/stack_zero.cpp line 29:

> 27: #include "interpreter/interpreterRuntime.hpp"
> 28: #include "interpreter/zero/bytecodeInterpreter.hpp"
> 29: #include "runtime/javaThread.hpp"

Interesting... This replacement of thread.inline.hpp to javaThread.hpp also
has an include javaThread.inline.hpp. There are other thread.inline.hpp to
javaThread.hpp replacements that don't add an include of javaThread.inline.hpp.

Did you only add javaThread.inline.hpp when compilation failed?

src/hotspot/share/prims/jvmtiDeferredUpdates.hpp line 36:

> 34: template <typename T> class GrowableArray;
> 35: 
> 36: class jvmtiDeferredLocalVariable : public CHeapObj<mtCompiler> {

This surprised me, but I'm guessing we picked up the template
from thread.inline.hpp...

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 39:

> 37: #include "runtime/safepointMechanism.inline.hpp"
> 38: #include "runtime/safepointVerifiers.hpp"
> 39: #include "runtime/javaThread.inline.hpp"

This is a duplicate include of the one on L33 above.

src/hotspot/share/runtime/vframe.hpp line 116:

> 114: };
> 115: 
> 116: class MonitorInfo;

This one also surprise me. I don't have a guess how this one worked before.

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

Marked as reviewed by dcubed (Reviewer).

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

From dcubed at openjdk.org  Wed Jun 22 20:04:57 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Jun 2022 20:04:57 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <78l9rFqrnsnTome7w0Bcp4lGm-nNHRvbBpTSXsp9Ma4=.4163cd81-0e5d-442f-878c-48b1cb52574a@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
 <78l9rFqrnsnTome7w0Bcp4lGm-nNHRvbBpTSXsp9Ma4=.4163cd81-0e5d-442f-878c-48b1cb52574a@github.com>
Message-ID: <1wGBDihKF58QXO4N0_mxsmCR8Z53RIoxX31ds7oZit4=.74152b42-6386-4db1-988a-a4e204f02c03@github.com>

On Wed, 22 Jun 2022 12:47:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Merge and testing in progress.
>
> Guidance says no copyright update. Thanks for reviewing.

@coleenp's comment from above:
> @dcubed-ojdk Your changes are now in threads.cpp and javaThread.cpp/hpp.
> Can you have a look to make sure they're correct? They were straightforward to move.

I double checked each of the three patches and all the changes are there and in
the right places. What was really cool was being able to pick between the javaThread.*,
thread.* and threads.* files easily based on the class name for the function that I
was changing. Pretty easy to navigate the new layout (IMHO).

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

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

From coleenp at openjdk.org  Wed Jun 22 21:04:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 21:04:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <GlzsoqgfEb_Yo63X--aVa6vYTthb9fVdQflnro19qbo=.a862c90b-6c44-4ec4-981b-6a00e17287d6@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

Hi Dan, thank you for crawling through the change.  I'm going to make your comments into a new CR and fix it there.
Sorry I didn't wait for the integration.  I was anxious about merging and finally getting GHA to pass.  I'm glad you liked the changes!

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

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

From coleenp at openjdk.org  Wed Jun 22 21:04:40 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 21:04:40 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
 <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
Message-ID: <te2IS0G-YtpjcN2T3i9f5qNM6jyC0jt5Mn4PStd0PIc=.1ca43a32-8ad2-4f92-a028-c0c41dd9b6ea@github.com>

On Wed, 22 Jun 2022 19:06:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More GHA fixes.
>
> src/hotspot/share/prims/jvmtiDeferredUpdates.hpp line 36:
> 
>> 34: template <typename T> class GrowableArray;
>> 35: 
>> 36: class jvmtiDeferredLocalVariable : public CHeapObj<mtCompiler> {
> 
> This surprised me, but I'm guessing we picked up the template
> from thread.inline.hpp...

yes.

> src/hotspot/share/runtime/vframe.hpp line 116:
> 
>> 114: };
>> 115: 
>> 116: class MonitorInfo;
> 
> This one also surprise me. I don't have a guess how this one worked before.

That forward declaration came from a transitive include of thread.hpp, if I remember correctly.

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

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

From coleenp at openjdk.org  Wed Jun 22 21:09:39 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 22 Jun 2022 21:09:39 GMT
Subject: RFR: 8288752: Split thread implementation files [v7]
In-Reply-To: <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <_XuqUNCFDcuoX41_yvdFAJvdZSn_aStzy-J1iXLhSwQ=.fc1d6936-a84e-4088-a1a1-77fb5b4d30ee@github.com>
 <az8QScTYC5o1N6NFifSv0_eSvpgI7iJRom7O6HD810Y=.0faab057-c582-4c62-b314-15ed8dbc099e@github.com>
Message-ID: <jlvU-FB1HYbMFJ163V7JNLwlbKy9AXSh03m5Oe0mYOs=.d4067eb0-945e-47fa-b4c4-13ab404af1d7@github.com>

On Tue, 21 Jun 2022 23:38:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More GHA fixes.
>
> src/hotspot/cpu/zero/stack_zero.cpp line 29:
> 
>> 27: #include "interpreter/interpreterRuntime.hpp"
>> 28: #include "interpreter/zero/bytecodeInterpreter.hpp"
>> 29: #include "runtime/javaThread.hpp"
> 
> Interesting... This replacement of thread.inline.hpp to javaThread.hpp also
> has an include javaThread.inline.hpp. There are other thread.inline.hpp to
> javaThread.hpp replacements that don't add an include of javaThread.inline.hpp.
> 
> Did you only add javaThread.inline.hpp when compilation failed?

Yes, I added javaThread.inline.hpp after compilation failed.  I will remove javaThread.hpp.

> src/hotspot/share/runtime/interfaceSupport.inline.hpp line 39:
> 
>> 37: #include "runtime/safepointMechanism.inline.hpp"
>> 38: #include "runtime/safepointVerifiers.hpp"
>> 39: #include "runtime/javaThread.inline.hpp"
> 
> This is a duplicate include of the one on L33 above.

Thanks, that was unintentional.  Removed.

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

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

From dcubed at openjdk.org  Wed Jun 22 21:14:41 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 22 Jun 2022 21:14:41 GMT
Subject: RFR: 8288752: Split thread implementation files [v9]
In-Reply-To: <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
References: <5Faxzw8Y3PpdI7gQSyvyqNNQ6gQQqW2YrJRiZ3nbMH8=.ff39ace8-4200-4d98-ac70-619b5cc9d51c@github.com>
 <kl1DK0bRqVzt6gTxg3EmCH_AXhsWlw4XsygG4LldNT4=.0da94ff8-505d-4f54-a156-f274c24f992f@github.com>
Message-ID: <4PjPxF1me-KnvwbACwKuZNm74D3rHA8LnICxB72f_Do=.861b1703-e3f3-40e8-a982-0b5a0fa29a0a@github.com>

On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>> 
>> I left the commits intact to see better the progression of changes, but most files are include file changes.  The only tricky parts are that some files were included in thread.hpp, like mutexLocker.cpp, which has to be included in the files that need it.
>> 
>> I didn't update the copyrights to save diffs but will before integration.
>> Also I won't integrate until after Dan's JDK 19 changes are merged into JDK 20.
>> 
>> Tested with tier1-4 on Oracle supported platforms and built on other platforms.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Merge and testing in progress.

No apology needed. It was a huge change and you don't want to wait too long
and run into merge after merge...

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

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

From zgu at openjdk.org  Thu Jun 23 17:49:50 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 17:49:50 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v2]
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <0CN3S9po38Sr2FT3cjroUSWIHhd5tM1QikiBIQTVvec=.9f49a85f-e200-4da8-9f6a-e7ebd5881143@github.com>

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

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

 - Review feedback
 - Merge branch 'master' into JDK-8287805-evac-updt-closures
 - 8287805: Shenandoah: consolidate evacuate-update-root closures
 - Merge branch 'master' into consolidate_evac_root_closures
 - v0
 - v0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9023/files
  - new: https://git.openjdk.org/jdk/pull/9023/files/c3a41277..427c3a45

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

  Stats: 64291 lines in 1573 files changed: 35441 ins; 15195 del; 13655 mod
  Patch: https://git.openjdk.org/jdk/pull/9023.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9023/head:pull/9023

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

From zgu at openjdk.org  Thu Jun 23 17:54:45 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 17:54:45 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v2]
In-Reply-To: <bPtb_J668vBuNXq8xiX7BkpOvd60Q5j3yZJqnTAJfeg=.aba0a909-1e40-41ed-a4b9-827cd5c3b3a8@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <bPtb_J668vBuNXq8xiX7BkpOvd60Q5j3yZJqnTAJfeg=.aba0a909-1e40-41ed-a4b9-827cd5c3b3a8@github.com>
Message-ID: <XMKHGP97tB2vurp_mOABHAan7MVTyEqScjNMgqKvmMg=.b8e8105b-86a4-4a7c-b650-e86c8bf524bd@github.com>

On Wed, 22 Jun 2022 15:26:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Review feedback
>>  - Merge branch 'master' into JDK-8287805-evac-updt-closures
>>  - 8287805: Shenandoah: consolidate evacuate-update-root closures
>>  - Merge branch 'master' into consolidate_evac_root_closures
>>  - v0
>>  - v0
>
> src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 99:
> 
>> 97:     inline ShenandoahEvacuateUpdateRootClosureBase();
>> 98:     inline virtual void do_oop(oop* p);
>> 99:     inline virtual void do_oop(narrowOop* p);
> 
> Do we have to make these functions `virtual`? I supposed we do templated closures exactly to avoid any sort of virtual method dispatching. Maybe I am missing something here...

Fixed

> src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 144:
> 
>> 142: template <bool atomic>
>> 143: void ShenandoahEvacuateUpdateRootClosureBase<atomic>::do_oop(oop* p) {
>> 144:   do_oop_work(p, Thread::current());
> 
> Not fond of calling `Thread::current()` on this hotpath. From the code, it looks like we only need it when actually calling `_heap->evacuate_object()`, can we move it there? 
> 
> Related: is `ShenandoahContextEvacuateUpdateRootsClosure::_thread` used now? Can we use it on some paths too?

My mistake, fixed.

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

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

From zgu at openjdk.org  Thu Jun 23 18:07:58 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 18:07:58 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v3]
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com>

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

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

  Remove unused impl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9023/files
  - new: https://git.openjdk.org/jdk/pull/9023/files/427c3a45..689335bf

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

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

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

From zgu at openjdk.org  Thu Jun 23 18:08:00 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 18:08:00 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v3]
In-Reply-To: <XMKHGP97tB2vurp_mOABHAan7MVTyEqScjNMgqKvmMg=.b8e8105b-86a4-4a7c-b650-e86c8bf524bd@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <bPtb_J668vBuNXq8xiX7BkpOvd60Q5j3yZJqnTAJfeg=.aba0a909-1e40-41ed-a4b9-827cd5c3b3a8@github.com>
 <XMKHGP97tB2vurp_mOABHAan7MVTyEqScjNMgqKvmMg=.b8e8105b-86a4-4a7c-b650-e86c8bf524bd@github.com>
Message-ID: <5QcrbCR00EiXj26otV3Iy6eRcsUHT81iYl9Jdlv8-X8=.0cbde552-718b-4ed0-a776-fa9d7ab56d44@github.com>

On Thu, 23 Jun 2022 17:52:14 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 99:
>> 
>>> 97:     inline ShenandoahEvacuateUpdateRootClosureBase();
>>> 98:     inline virtual void do_oop(oop* p);
>>> 99:     inline virtual void do_oop(narrowOop* p);
>> 
>> Do we have to make these functions `virtual`? I supposed we do templated closures exactly to avoid any sort of virtual method dispatching. Maybe I am missing something here...
>
> Fixed

Removed `virtual` keyword

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

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

From zgu at openjdk.org  Thu Jun 23 18:33:54 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 18:33:54 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v3]
In-Reply-To: <bPtb_J668vBuNXq8xiX7BkpOvd60Q5j3yZJqnTAJfeg=.aba0a909-1e40-41ed-a4b9-827cd5c3b3a8@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <bPtb_J668vBuNXq8xiX7BkpOvd60Q5j3yZJqnTAJfeg=.aba0a909-1e40-41ed-a4b9-827cd5c3b3a8@github.com>
Message-ID: <MekP8gDNoYcWClg8t3ZKW-JdAOiWvYYT3LEbktcGVnk=.ba54ede8-2ce6-446f-bd44-17cb768b4383@github.com>

On Wed, 22 Jun 2022 15:24:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused impl
>
> src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 95:
> 
>> 93: class ShenandoahEvacuateUpdateRootClosureBase : public ShenandoahOopClosureBase {
>> 94: protected:
>> 95:     ShenandoahHeap* const _heap;
> 
> Here and later the indenting is a bit off: needs to be 2 spaces, not 4.

Fixed

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

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

From zgu at openjdk.org  Thu Jun 23 19:02:53 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 19:02:53 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2]
In-Reply-To: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
Message-ID: <AuVfp0mR2Hk91CNCZ-DWUqx-HWSnWZEoIzJe4lUIrY8=.21914aa3-1701-46d5-a08a-cf2ea6bb12f0@github.com>

> Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64
> - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 
> - [x] hotspot_gc_shenandoah on AArch64

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

 - Add a newline
 - Merge branch 'master' into 8287818-nmethod-arming
 - 8287818: Shenandoah: adapt nmethod arming from Loom
 - Merge branch 'master' into migrate_nmethod_arming_shenandoah
 - v0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9048/files
  - new: https://git.openjdk.org/jdk/pull/9048/files/30a2f41b..b4ef6d63

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

  Stats: 64264 lines in 1573 files changed: 35422 ins; 15195 del; 13647 mod
  Patch: https://git.openjdk.org/jdk/pull/9048.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9048/head:pull/9048

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

From zgu at openjdk.org  Thu Jun 23 19:02:56 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 23 Jun 2022 19:02:56 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2]
In-Reply-To: <p_iO1ttgVdcBVplVIaTwdiBFkAv4xSoDu_pa-uMISBE=.0b1f6e39-43f9-46d3-9932-95570830a7e2@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
 <p_iO1ttgVdcBVplVIaTwdiBFkAv4xSoDu_pa-uMISBE=.0b1f6e39-43f9-46d3-9932-95570830a7e2@github.com>
Message-ID: <q8e4s2pK_FkL8ZyG7zN1lXRv1KSWkFX37Tq-ei9oefE=.921fab1c-8103-4559-bc49-7b7e866d3f16@github.com>

On Wed, 22 Jun 2022 15:26:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Add a newline
>>  - Merge branch 'master' into 8287818-nmethod-arming
>>  - 8287818: Shenandoah: adapt nmethod arming from Loom
>>  - Merge branch 'master' into migrate_nmethod_arming_shenandoah
>>  - v0
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp line 72:
> 
>> 70:   ShenandoahNMethod::disarm_nmethod(nm);
>> 71:   return true;
>> 72: }
> 
> Nit: missing newline.

Fixed

> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 129:
> 
>> 127: 
>> 128: void ShenandoahCodeRoots::arm_nmethods() {
>> 129:   BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods();
> 
> Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or?

Only in `passive` mode, Shenandoah does not install nmethod barrier, but `passive` mode never calls `arm_nmethod()`, etc. nmethod entry barrier related methods.

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

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

From shade at openjdk.org  Fri Jun 24 08:47:58 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jun 2022 08:47:58 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2]
In-Reply-To: <AuVfp0mR2Hk91CNCZ-DWUqx-HWSnWZEoIzJe4lUIrY8=.21914aa3-1701-46d5-a08a-cf2ea6bb12f0@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
 <AuVfp0mR2Hk91CNCZ-DWUqx-HWSnWZEoIzJe4lUIrY8=.21914aa3-1701-46d5-a08a-cf2ea6bb12f0@github.com>
Message-ID: <5YeCHWQ7ep4_r14cG96WcKfzp0Bs-AMqfu0KYnYvuiM=.3fcc24de-24a8-472e-8a8b-4508107a2970@github.com>

On Thu, 23 Jun 2022 19:02:53 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64
>> - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 
>> - [x] hotspot_gc_shenandoah on AArch64
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Add a newline
>  - Merge branch 'master' into 8287818-nmethod-arming
>  - 8287818: Shenandoah: adapt nmethod arming from Loom
>  - Merge branch 'master' into migrate_nmethod_arming_shenandoah
>  - v0

Marked as reviewed by shade (Reviewer).

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

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

From shade at openjdk.org  Fri Jun 24 08:48:01 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jun 2022 08:48:01 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2]
In-Reply-To: <q8e4s2pK_FkL8ZyG7zN1lXRv1KSWkFX37Tq-ei9oefE=.921fab1c-8103-4559-bc49-7b7e866d3f16@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
 <p_iO1ttgVdcBVplVIaTwdiBFkAv4xSoDu_pa-uMISBE=.0b1f6e39-43f9-46d3-9932-95570830a7e2@github.com>
 <q8e4s2pK_FkL8ZyG7zN1lXRv1KSWkFX37Tq-ei9oefE=.921fab1c-8103-4559-bc49-7b7e866d3f16@github.com>
Message-ID: <zkV4m2euev-Qn0f293LrpFWYK7sd8EClbHAWiP2ibxA=.221ec3f1-c693-445d-8971-6c2e2a5be5ed@github.com>

On Thu, 23 Jun 2022 18:58:45 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 129:
>> 
>>> 127: 
>>> 128: void ShenandoahCodeRoots::arm_nmethods() {
>>> 129:   BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods();
>> 
>> Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or?
>
> Only in `passive` mode, Shenandoah does not install nmethod barrier, but `passive` mode never calls `arm_nmethod()`, etc. nmethod entry barrier related methods.

All right, would you mind adding at least the assert here, so that we don't have a spurious SEGV if that was ever violated?

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

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

From kdnilsen at openjdk.org  Fri Jun 24 16:19:57 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 16:19:57 GMT
Subject: RFR: Pack old evacuations tightly
Message-ID: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>

This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".

This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

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

Commit messages:
 - Fix whitespace
 - Merge remote-tracking branch 'GitFarmBranch/pack-old-evacuations-tightly' into pack-old-evacuations-tightly
 - Remove instrumentation
 - Improvements to comments and logging
 - Remove newline from inside log message
 - Fix response to PLAB promotion failures
 - Fixup mismatched else clause
 - Fix unbalanced braces
 - Handle promotion failure specially for unnamed threads
 - Fix merge conflict problems
 - ... and 27 more: https://git.openjdk.org/shenandoah/compare/a5aa4130...d5263dcb

Changes: https://git.openjdk.org/shenandoah/pull/145/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=145&range=00
  Stats: 763 lines in 16 files changed: 543 ins; 33 del; 187 mod
  Patch: https://git.openjdk.org/shenandoah/pull/145.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/145/head:pull/145

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

From wkemper at openjdk.org  Fri Jun 24 16:19:58 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jun 2022 16:19:58 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <lOUv776pNmO0krICekkrLPQwQ2GTD0jDKZ5rk8WPGjY=.c83ba0e8-a8bf-492d-be59-ed5a9f292283@github.com>

On Fri, 24 Jun 2022 00:40:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

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

> 112:     ShenandoahHeapRegion* r = data[idx]._region;
> 113:     size_t new_cset;
> 114:     if (is_generational && (r->age() >= InitialTenuringThreshold)) {

Are we changing region affiliation en masse?

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

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

From kdnilsen at openjdk.org  Fri Jun 24 16:19:59 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 16:19:59 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <lOUv776pNmO0krICekkrLPQwQ2GTD0jDKZ5rk8WPGjY=.c83ba0e8-a8bf-492d-be59-ed5a9f292283@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
 <lOUv776pNmO0krICekkrLPQwQ2GTD0jDKZ5rk8WPGjY=.c83ba0e8-a8bf-492d-be59-ed5a9f292283@github.com>
Message-ID: <EY4wQ-Srf2-XQxtZBc75uTDuY561Hli8zMdxXf0iWQs=.0c08c334-4b12-4e5f-84c9-2cb3e2b5b247@github.com>

On Fri, 24 Jun 2022 16:04:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
>> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
>> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
>> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
>> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
>> 
>> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
>> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 114:
> 
>> 112:     ShenandoahHeapRegion* r = data[idx]._region;
>> 113:     size_t new_cset;
>> 114:     if (is_generational && (r->age() >= InitialTenuringThreshold)) {
> 
> Are we changing region affiliation en masse?

We don't "promote" regions by relabeling region affiliation.  But I found that the computed budget for promotion reserve is way too low in the case that entire regions have reached tenure age.  So I made an adjustment to compute larger promotion reserves when we know that all live data within a collection set region is known to be promoted.

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

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

From shade at openjdk.org  Fri Jun 24 17:47:55 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jun 2022 17:47:55 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v3]
In-Reply-To: <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com>
Message-ID: <XAlqh2NMI4bdskdY_QutYrW2W0j-2qzE_ij13jjicFk=.21f42dac-463d-4004-8d1c-c29f2a1b1657@github.com>

On Thu, 23 Jun 2022 18:07:58 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.
>> 
>> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused impl

I still dislike the fact we are calling `Thread::current()` on hotpath. I think we can do better. Consider this modification on top of your current PR: http://cr.openjdk.java.net/~shade/8287805/thread-1.patch -- does that look better?

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

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

From wkemper at openjdk.org  Fri Jun 24 17:59:33 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jun 2022 17:59:33 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <MQxe_rilwGmbo9QzpF0FQD0qfWdJPioZfeKhU8oPFfg=.d6dc7954-5cee-45bb-9117-713031b56a20@github.com>

On Fri, 24 Jun 2022 00:40:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

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

> 154:   virtual void record_requested_gc();
> 155: 
> 156:   virtual size_t prioritize_aged_regions(size_t old_available, size_t num_regions, bool preselected_regions[]);

Maybe call this `select_aged_regions`?

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

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

From wkemper at openjdk.org  Fri Jun 24 18:16:29 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jun 2022 18:16:29 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <CbZNOfyhmiabNdXSVS0MwlOHl8faex3kDvNwvVFScUQ=.82219b67-9ea7-4eba-8bb1-cdd4a56e5bf1@github.com>

On Fri, 24 Jun 2022 00:40:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

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

> 394:       //       garbage).
> 395: 
> 396:       size_t young_evacuation_reserve = (young_generation->soft_max_capacity() * ShenandoahEvacReserve) / 100;

Should we try to align this more closely with how `ShenandoahFreeSet` behaves? It uses `max_capacity`, for example. It could also tell us exactly how much it really reserved.

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

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

From wkemper at openjdk.org  Fri Jun 24 18:26:31 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jun 2022 18:26:31 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <MmwFKsYs1FeuScNGKVPglAydxBk4e6cOVABvWB_J688=.b4a1eabe-9d54-4cb5-8bcd-ae5e40ea578e@github.com>

On Fri, 24 Jun 2022 00:40:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1022:

> 1020: void ShenandoahHeap::retire_plab(PLAB* plab) {
> 1021:   if (!mode()->is_generational()) {
> 1022:     plab->retire();

Do we have plabs in the other modes?

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

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

From wkemper at openjdk.org  Fri Jun 24 18:29:36 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jun 2022 18:29:36 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <Iwt4L7s6VsD8iPlLUuBRYnK6GqqKEFCx4JXx6CungRA=.75a7db58-fdcc-49e1-b318-6837ac32d303@github.com>

On Fri, 24 Jun 2022 00:40:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

Marked as reviewed by wkemper (Committer).

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

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

From kdnilsen at openjdk.org  Fri Jun 24 19:04:18 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 19:04:18 GMT
Subject: RFR: Pack old evacuations tightly
In-Reply-To: <MQxe_rilwGmbo9QzpF0FQD0qfWdJPioZfeKhU8oPFfg=.d6dc7954-5cee-45bb-9117-713031b56a20@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
 <MQxe_rilwGmbo9QzpF0FQD0qfWdJPioZfeKhU8oPFfg=.d6dc7954-5cee-45bb-9117-713031b56a20@github.com>
Message-ID: <HIWm3hN3N24uL6AxHNq54zDHUJmE6xNBNFGs0WPBugY=.a9e2f365-5a0f-4ab7-94e9-5479fc3f4723@github.com>

On Fri, 24 Jun 2022 17:55:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
>> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
>> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
>> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
>> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
>> 
>> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
>> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 156:
> 
>> 154:   virtual void record_requested_gc();
>> 155: 
>> 156:   virtual size_t prioritize_aged_regions(size_t old_available, size_t num_regions, bool preselected_regions[]);
> 
> Maybe call this `select_aged_regions`?

will make this change.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 396:
> 
>> 394:       //       garbage).
>> 395: 
>> 396:       size_t young_evacuation_reserve = (young_generation->soft_max_capacity() * ShenandoahEvacReserve) / 100;
> 
> Should we try to align this more closely with how `ShenandoahFreeSet` behaves? It uses `max_capacity`, for example. It could also tell us exactly how much it really reserved.

I will change this.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1022:
> 
>> 1020: void ShenandoahHeap::retire_plab(PLAB* plab) {
>> 1021:   if (!mode()->is_generational()) {
>> 1022:     plab->retire();
> 
> Do we have plabs in the other modes?

PLABs only exist in generational mode

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

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

From kdnilsen at openjdk.org  Fri Jun 24 19:21:19 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 19:21:19 GMT
Subject: RFR: Pack old evacuations tightly [v2]
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <Mg7BDF4oCCP7NW-T5lVwzFt_ZhC3zcw-kE7W0X7zIaI=.de76a97d-97a2-4ed2-a898-2c15ba468fbb@github.com>

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

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

  Improvements requested by reviewer

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/145/files
  - new: https://git.openjdk.org/shenandoah/pull/145/files/d5263dcb..0741d705

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

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

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

From kdnilsen at openjdk.org  Fri Jun 24 19:21:22 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 19:21:22 GMT
Subject: RFR: Pack old evacuations tightly [v2]
In-Reply-To: <HIWm3hN3N24uL6AxHNq54zDHUJmE6xNBNFGs0WPBugY=.a9e2f365-5a0f-4ab7-94e9-5479fc3f4723@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
 <MQxe_rilwGmbo9QzpF0FQD0qfWdJPioZfeKhU8oPFfg=.d6dc7954-5cee-45bb-9117-713031b56a20@github.com>
 <HIWm3hN3N24uL6AxHNq54zDHUJmE6xNBNFGs0WPBugY=.a9e2f365-5a0f-4ab7-94e9-5479fc3f4723@github.com>
Message-ID: <jfTiv9bHkiTGaFRJr3aJ4R1gJvlY26jxrjPKoapMmZM=.ec43fb1e-5696-45a1-980e-e141706e9356@github.com>

On Fri, 24 Jun 2022 18:59:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1022:
>> 
>>> 1020: void ShenandoahHeap::retire_plab(PLAB* plab) {
>>> 1021:   if (!mode()->is_generational()) {
>>> 1022:     plab->retire();
>> 
>> Do we have plabs in the other modes?
>
> PLABs only exist in generational mode

I should fix this.  sorry

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

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

From kdnilsen at openjdk.org  Fri Jun 24 19:21:23 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 19:21:23 GMT
Subject: Integrated: Pack old evacuations tightly
In-Reply-To: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
References: <ZX7G7jdEgCCA89tzmVKTkA7fp2ufLVZ_ikBkyJAEl3o=.e2ec1300-070b-40f2-8e2e-9ecfb0c26de5@github.com>
Message-ID: <fwejigQkFBccrgzgp29_miweq0e8mX9FSJWox2-Jj-I=.b0fe4c4a-42f6-43ba-9cc8-298e0dd6a7fb@github.com>

On Fri, 24 Jun 2022 00:40:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request includes several improvements to reduce the likelihood of evacuation failures and to reduce the frequency of old-gen collections.  Key contributions:
> 1. If a PLAB allocation fails, resize the the thread's preferred PLAB size to minimum size and retry the allocation request
> 2. Place a limit on how large the preferred PLAB size grows for individual threads.  Otherwise a small number of threads can consume the full promotion budget, leaving nothing left for the PLABs required by other threads.
> 3. If a PLAB promotion fails, and the remaining words within the PLAB is greater than minimum size, that means this is a request to promote a relatively large object.  In this case, do not retire the PLAB.  Instead, use a shared allocation to promote this large object.
> 4. If a PLAB promotion fails and the remaining words is less than the PLAB minimum size, try to replace the PLAB and then retry the PLAB allocation.  If this still fails, evacuate the object to young-gen using a GCLAB.  Don't try to promote with a shared allocation because that is too "expensive".
> 
> This commit has demonstrated fairly significant benefits on certain workloads.  For specjbb2015, we got a 17% improvement in critical jops, from 3093.847 to 3622.  For an extremem 2020 workload,
> we improved p99.999 for customer preparation processing by more than four fold, from 607,107 microseconds to 142,286 microseconds, decreasing the number of concurrent GCs from 99 to 37, old GCs from 12 to 7, full GCs from 3 to 0.

This pull request has now been integrated.

Changeset: bd13ba31
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/bd13ba314482edf2be66ef7c4a2f7f5f60f3e93d
Stats:     763 lines in 16 files changed: 543 ins; 33 del; 187 mod

Pack old evacuations tightly

Reviewed-by: wkemper

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

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

From kdnilsen at openjdk.org  Fri Jun 24 19:46:03 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 19:46:03 GMT
Subject: RFR: Remove unnecessary checks identified by reviewer
Message-ID: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>

A previous pull request was integrated before all of the reviewer
comments had been addressed.  This commit addresses the lingering
request.

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

Commit messages:
 - Remove unnecessary checks identified by reviewer

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

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

From kdnilsen at openjdk.org  Fri Jun 24 20:34:21 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 20:34:21 GMT
Subject: RFR: Remove unnecessary checks identified by reviewer
In-Reply-To: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
References: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
Message-ID: <jk0E6LHlJTFL1iNKonogfHyuQp014NwE6tNeyEqLKk4=.ac3feeed-125a-47e6-b75f-3639232afb73@github.com>

On Fri, 24 Jun 2022 19:38:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> A previous pull request was integrated before all of the reviewer
> comments had been addressed.  This commit addresses the lingering
> request.

See https://urldefense.com/v3/__https://github.com/openjdk/shenandoah/pull/145/files/0d8c092e209f61f91ccb41312a028769147d0f4c*r906297895__;Iw!!ACWV5N9M2RV99hQ!N-0T1716i9EqfOK_8XEUg6vDwgr8jX0TXMiWzQrVTBAqyyCpDPsCrDyEXmdYLxZRrj69bkcy6gVL_F6a2bxaat-BJw$ 

for context of original feedback

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

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

From wkemper at openjdk.org  Fri Jun 24 20:44:36 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Jun 2022 20:44:36 GMT
Subject: RFR: Remove unnecessary checks identified by reviewer
In-Reply-To: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
References: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
Message-ID: <htM9xExzzzUVotyihSdPOqgrBVAFvTPMdLo5lekarKE=.55866600-3dcd-48e5-9785-2fcf8959ebcb@github.com>

On Fri, 24 Jun 2022 19:38:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> A previous pull request was integrated before all of the reviewer
> comments had been addressed.  This commit addresses the lingering
> request.

Thanks for the update

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

Marked as reviewed by wkemper (Committer).

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

From duke at openjdk.org  Fri Jun 24 20:59:34 2022
From: duke at openjdk.org (Y. S. Ramakrishna)
Date: Fri, 24 Jun 2022 20:59:34 GMT
Subject: RFR: Remove unnecessary checks identified by reviewer
In-Reply-To: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
References: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
Message-ID: <OchgE3GmEjSlV9-PaesyytjXx59Rn6fH6D-m5u9VWBg=.fbc9fb53-e09d-4184-8ca1-186f63eb6c88@github.com>

On Fri, 24 Jun 2022 19:38:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> A previous pull request was integrated before all of the reviewer
> comments had been addressed.  This commit addresses the lingering
> request.

Thanks for the context. This looks good!

For context, could you link to the previous reviewer feedback that this addresses? Thanks!

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

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

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

From kdnilsen at openjdk.org  Fri Jun 24 21:17:42 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Jun 2022 21:17:42 GMT
Subject: Integrated: Remove unnecessary checks identified by reviewer
In-Reply-To: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
References: <1elwPIUHZ92vHq6TJqgACUqbHx8AL8BRxIpRc3g6dk4=.eb3cbb25-cd2b-4ac3-bd15-0ef7509ff749@github.com>
Message-ID: <oeZr4uZn91ThRQzG55iRiW7lqobkSr7c_2JDzy7cSCg=.14b20788-d191-4de6-b85e-fab56a946c45@github.com>

On Fri, 24 Jun 2022 19:38:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> A previous pull request was integrated before all of the reviewer
> comments had been addressed.  This commit addresses the lingering
> request.

This pull request has now been integrated.

Changeset: 0fefe704
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/0fefe704c854f0273935a74b2bb72a50b8a716a4
Stats:     37 lines in 1 file changed: 0 ins; 8 del; 29 mod

Remove unnecessary checks identified by reviewer

Reviewed-by: wkemper

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

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

From wkemper at openjdk.org  Mon Jun 27 21:30:51 2022
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Jun 2022 21:30:51 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
Message-ID: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>

Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.

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

Commit messages:
 - Have all triggers look at available memory after adjusting for headroom and penalities
 - Heuristic should use freeset available if this is lower than heap available

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

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

From duke at openjdk.org  Mon Jun 27 22:46:18 2022
From: duke at openjdk.org (Y. S. Ramakrishna)
Date: Mon, 27 Jun 2022 22:46:18 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
In-Reply-To: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
Message-ID: <cp9dZQLxb3RsPfRI_cHjl3rZz_62VK72g45IqS7I0lc=.13d06f48-7f47-46e3-b2d8-ada4b79e4a34@github.com>

On Mon, 27 Jun 2022 21:24:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.

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

> 246:   //   2. Accumulated penalties from Degenerated and Full GC
> 247:   size_t allocation_headroom = available;
> 248:   size_t spike_headroom = capacity / 100 * ShenandoahAllocSpikeFactor;

Should you move the associated comments at lines 281-324 up here as well. The comment further below now dangles on its own.

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

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

From zgu at openjdk.org  Mon Jun 27 23:04:29 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 27 Jun 2022 23:04:29 GMT
Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v3]
In-Reply-To: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
Message-ID: <LbPYgi4h86T-Zf7XyTPm2BqJsJFE5qg1n6hExXD1yXU=.c888bd69-f38a-44ab-9bc4-658dd326f65e@github.com>

> Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64
> - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 
> - [x] hotspot_gc_shenandoah on AArch64

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

  Add assertion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9048/files
  - new: https://git.openjdk.org/jdk/pull/9048/files/b4ef6d63..b496a508

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

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

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

From wkemper at openjdk.org  Tue Jun 28 00:03:24 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Jun 2022 00:03:24 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
Message-ID: <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>

> Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.

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

  Adjust comments to stay with moved code

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/147/files
  - new: https://git.openjdk.org/shenandoah/pull/147/files/c2e6a856..28096c5f

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

  Stats: 32 lines in 1 file changed: 15 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/147.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/147/head:pull/147

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

From wkemper at openjdk.org  Tue Jun 28 00:03:24 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Jun 2022 00:03:24 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <cp9dZQLxb3RsPfRI_cHjl3rZz_62VK72g45IqS7I0lc=.13d06f48-7f47-46e3-b2d8-ada4b79e4a34@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
 <cp9dZQLxb3RsPfRI_cHjl3rZz_62VK72g45IqS7I0lc=.13d06f48-7f47-46e3-b2d8-ada4b79e4a34@github.com>
Message-ID: <Ra5LOdJ94QC06YXSzEHaBcTRev1kKYj-zxmB4YRMo4A=.01d1a85d-0ff7-41b1-a69e-15fd98cd6f3f@github.com>

On Mon, 27 Jun 2022 22:42:35 GMT, Y. S. Ramakrishna <duke at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust comments to stay with moved code
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 248:
> 
>> 246:   //   2. Accumulated penalties from Degenerated and Full GC
>> 247:   size_t allocation_headroom = available;
>> 248:   size_t spike_headroom = capacity / 100 * ShenandoahAllocSpikeFactor;
> 
> Should you move the associated comments at lines 281-324 up here as well. The comment further below now dangles on its own.

Sure, I've moved up the relevant comments.

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

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

From kdnilsen at openjdk.org  Tue Jun 28 03:27:55 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Jun 2022 03:27:55 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner
Message-ID: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>

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

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

Commit messages:
 - Refactor budgeting to make the logic cleaner

Changes: https://git.openjdk.org/shenandoah/pull/148/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=148&range=00
  Stats: 216 lines in 4 files changed: 12 ins; 196 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah/pull/148.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/148/head:pull/148

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

From iklam at openjdk.org  Tue Jun 28 06:28:35 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 06:28:35 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of os_xxx.hpp
Message-ID: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>

There are only two implementations of these classes (one for windows, and one for posix):

- PlatformEvent
- PlatformParker
- PlatformMutex
- PlatformMonitor
- ThreadCrashProtection

Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp

This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.

Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

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

Commit messages:
 - fixed windows
 - Moved PlatformMutex/PlatformMonitor
 - move-PlatformParker-out-of-os-xxx-hpp
 - Moved ThreadCrashProtection

Changes: https://git.openjdk.org/jdk/pull/9303/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9303&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289230
  Stats: 1168 lines in 35 files changed: 705 ins; 386 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

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

From dholmes at openjdk.org  Tue Jun 28 07:24:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Jun 2022 07:24:52 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>

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

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

Just took a quick skim through to get the general sense of things. Header file split is okay. Pity about the .cpp situation though - maybe move to platform_posix.cpp and platform_windows.cpp to at least get them out of the os_xxx.cpp file?

src/hotspot/os/posix/mutex_posix.hpp line 141:

> 139: };
> 140: 
> 141: #endif // OS_POSIX_PARK_POSIX_HPP

Wrong comment.

src/hotspot/os/posix/threadCrashProtection_posix.cpp line 38:

> 36: 
> 37: /*
> 38:  * See the caveats for this class in os_posix.hpp

Comment needs updating

src/hotspot/os/windows/mutex_windows.hpp line 64:

> 62: };
> 63: 
> 64: #endif // OS_WINDOWS_PARK_WINDOWS_HPP

Wrong comment

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

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

From rkennke at openjdk.org  Tue Jun 28 09:14:20 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Jun 2022 09:14:20 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
 <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
Message-ID: <9TkLr6DcYNNLks2vSwFJ4upYIrogXNBXKWkoEr_74V4=.fb7e5114-a023-4375-a159-cff2fccbd829@github.com>

On Tue, 28 Jun 2022 00:03:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments to stay with moved code

Is this something we should consider to put directly in upstream?

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

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

From rkennke at openjdk.org  Tue Jun 28 11:53:15 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Jun 2022 11:53:15 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <KSx3dA6fUuSPeKPif6mpjtjfeZoojpOPfv72FQJ2_zA=.3ed51412-ffd3-4105-b4cc-43fe8176ec9a@github.com>

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

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

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

> 687: 
> 688: void ShenandoahHeap::set_previous_promotion(size_t promoted_bytes) {
> 689:   shenandoah_assert_heaplocked();

Is this related and/or relevant?

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

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

From zgu at openjdk.org  Tue Jun 28 12:21:42 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 28 Jun 2022 12:21:42 GMT
Subject: Integrated: 8287818: Shenandoah: adapt nmethod arming from Loom
In-Reply-To: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
References: <Gdd2nPid06pDvxNbCovhiAQ9tjhpOAj1LJ9WPGc1-ZA=.2a6d2dee-f1fb-4973-bdad-aa29d13fd0e6@github.com>
Message-ID: <IwtSgM7VIW9vHvz-jEY2A2aprNiIWv-N_hKR3TA2bbg=.0f825dd2-a229-4b9d-921f-ca16ec104a53@github.com>

On Mon, 6 Jun 2022 23:29:10 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64
> - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 
> - [x] hotspot_gc_shenandoah on AArch64

This pull request has now been integrated.

Changeset: 549c6c22
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/549c6c22aedc5a7f2acd0b0ceabf956227e35cb3
Stats:     52 lines in 5 files changed: 4 ins; 40 del; 8 mod

8287818: Shenandoah: adapt nmethod arming from Loom

Reviewed-by: shade

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

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

From zgu at openjdk.org  Tue Jun 28 12:45:44 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Tue, 28 Jun 2022 12:45:44 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v3]
In-Reply-To: <XAlqh2NMI4bdskdY_QutYrW2W0j-2qzE_ij13jjicFk=.21f42dac-463d-4004-8d1c-c29f2a1b1657@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com>
 <XAlqh2NMI4bdskdY_QutYrW2W0j-2qzE_ij13jjicFk=.21f42dac-463d-4004-8d1c-c29f2a1b1657@github.com>
Message-ID: <Sz-7kvd-rpfiw0DXroHB7kZv5WWY4t9YCbwYvJyJuK4=.591a4d7c-5377-4f86-aaca-3c9eb669afe4@github.com>

On Fri, 24 Jun 2022 17:45:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I still dislike the fact we are calling `Thread::current()` on hotpath. I think we can do better. Consider this modification on top of your current PR: http://cr.openjdk.java.net/~shade/8287805/thread-1.patch -- does that look better?

Are your referring to `ShenandoahEvacuateUpdateRootsClosure`? It has to be context free closure, since it is a shared closure used by stack watermark processing.

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

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

From kdnilsen at openjdk.org  Tue Jun 28 13:50:15 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Jun 2022 13:50:15 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner
In-Reply-To: <KSx3dA6fUuSPeKPif6mpjtjfeZoojpOPfv72FQJ2_zA=.3ed51412-ffd3-4105-b4cc-43fe8176ec9a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <KSx3dA6fUuSPeKPif6mpjtjfeZoojpOPfv72FQJ2_zA=.3ed51412-ffd3-4105-b4cc-43fe8176ec9a@github.com>
Message-ID: <cS7EyWvmNBkwDqe23wV8e6-1kpk3iqhitAUMLlMPQ_c=.a5f06ffb-a78b-4bf7-9fd6-2a9e1bf7ab08@github.com>

On Tue, 28 Jun 2022 11:49:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 689:
> 
>> 687: 
>> 688: void ShenandoahHeap::set_previous_promotion(size_t promoted_bytes) {
>> 689:   shenandoah_assert_heaplocked();
> 
> Is this related and/or relevant?

We can remove that.  It was "somewhat" related to the historical progression that eventually resulted in this refactoring code.  At one point in my development, I had accidentally tried to set_previous_promotion() without having the heap lock, and the results were unpredictable.

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

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

From kdnilsen at openjdk.org  Tue Jun 28 15:40:17 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Jun 2022 15:40:17 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
 <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
Message-ID: <RVUtkH9IQo-N0arNqryfMYmBB0KZDp7-QINbfd5dS3c=.07e87ab6-a160-4c02-b54a-00b01d20f256@github.com>

On Tue, 28 Jun 2022 00:03:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments to stay with moved code

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.org  Tue Jun 28 15:55:26 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Jun 2022 15:55:26 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <9TkLr6DcYNNLks2vSwFJ4upYIrogXNBXKWkoEr_74V4=.fb7e5114-a023-4375-a159-cff2fccbd829@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
 <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
 <9TkLr6DcYNNLks2vSwFJ4upYIrogXNBXKWkoEr_74V4=.fb7e5114-a023-4375-a159-cff2fccbd829@github.com>
Message-ID: <pTc96HKFwHx4nc-AFMbrleGGda7S0BzPnMIweyv7kKA=.7faccc98-cd5b-4819-a6df-e51479bba1b0@github.com>

On Tue, 28 Jun 2022 09:10:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust comments to stay with moved code
>
> Is this something we should consider to put directly in upstream?

@rkennke - yes, I think it makes sense to make a similar change upstream. We wouldn't be able to apply this change directly because of surrounding generational changes. I will open a ticket and PR for this.

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

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

From wkemper at openjdk.org  Tue Jun 28 15:56:30 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Jun 2022 15:56:30 GMT
Subject: Integrated: Adaptive heuristic should take reserved memory into
 account
In-Reply-To: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
Message-ID: <lsnubVKAZRgj-7xdbd62VWhJIv7owCl2MKYgFd3D0fc=.bd536240-61b6-4e97-b7e8-b7d2f8514cc4@github.com>

On Mon, 27 Jun 2022 21:24:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.

This pull request has now been integrated.

Changeset: 3c066d43
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/3c066d43f2686a160f4a61acd6524b5acf79a8e7
Stats:     60 lines in 1 file changed: 32 ins; 26 del; 2 mod

Adaptive heuristic should take reserved memory into account

Reviewed-by: kdnilsen

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

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

From iklam at openjdk.org  Tue Jun 28 18:38:10 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 18:38:10 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>

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

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

  fixed comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9303/files
  - new: https://git.openjdk.org/jdk/pull/9303/files/27ddeb07..8ceda0f5

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

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

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

From iklam at openjdk.org  Tue Jun 28 18:38:11 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 18:38:11 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
Message-ID: <eDfvGWE0Ud3oL8xoERK7F9o64cRKUpAWa8mgaY4iFQE=.f5fc18f7-fbbf-4c80-844c-8138e89f0d3e@github.com>

On Tue, 28 Jun 2022 07:15:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comments
>
> src/hotspot/os/posix/mutex_posix.hpp line 141:
> 
>> 139: };
>> 140: 
>> 141: #endif // OS_POSIX_PARK_POSIX_HPP
> 
> Wrong comment.

Fixed.

> src/hotspot/os/posix/threadCrashProtection_posix.cpp line 38:
> 
>> 36: 
>> 37: /*
>> 38:  * See the caveats for this class in os_posix.hpp
> 
> Comment needs updating

Fixed.

> src/hotspot/os/windows/mutex_windows.hpp line 64:
> 
>> 62: };
>> 63: 
>> 64: #endif // OS_WINDOWS_PARK_WINDOWS_HPP
> 
> Wrong comment

Fixed.

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

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

From iklam at openjdk.org  Tue Jun 28 18:41:50 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 18:41:50 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <ZIKlmNLte2pF31H7gulNntJAId-feRBVLL1JPsNEVCQ=.afad4faf-e880-4761-92e3-a17fca8bdf0c@github.com>
Message-ID: <43iMsTyIQcqIf0SEztkB3zFld8tC6HERJyzeocytq4c=.8cbcd72f-642b-4af2-90fa-3f2c3f98e400@github.com>

On Tue, 28 Jun 2022 07:20:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Just took a quick skim through to get the general sense of things. Header file split is okay. Pity about the .cpp situation though - maybe move to platform_posix.cpp and platform_windows.cpp to at least get them out of the os_xxx.cpp file?

Unfortunately it's worse than I thought. There's a static function, `to_abstime()` that shared between `os::Posix::to_RTC_abstime()` and the `PlatformEvent::park()`.

To clean things up, I would need to move some static fields/functions into the `os::Posix` class. Maybe I should do the refactoring in a separate PR, to keep this PR simple?

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

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

From coleenp at openjdk.org  Tue Jun 28 19:42:44 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 28 Jun 2022 19:42:44 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
Message-ID: <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>

On Tue, 28 Jun 2022 18:38:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

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

I very much like this incremental approach to reducing our over-inclusion.

src/hotspot/share/runtime/mutex.hpp line 203:

> 201:   #ifndef PRODUCT
> 202:     void print_on(outputStream* st) const;
> 203:     void print() const                      { /*print_on(::tty); */ } // FIXME

Can you move this print implementation into the .cpp file?

src/hotspot/share/runtime/threadCrashProtection.hpp line 42:

> 40: #else
> 41: # error "No ThreadCrashProtection implementation provided for this OS"
> 42: #endif

Shouldn't you use this?
#define OS_HEADER(basename)            XSTR(OS_HEADER_STEM(basename).hpp)

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

Marked as reviewed by coleenp (Reviewer).

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

From iklam at openjdk.org  Tue Jun 28 20:13:01 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 20:13:01 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v3]
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <Z0lHSUzi5gdXlQ5_DMl6rO0hxg-b4rfeCX5hwZuHaHQ=.c267b32c-47bd-4efa-a248-aef033d64bf4@github.com>

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

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

  @coleenp comments

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

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

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

  Stats: 21 lines in 5 files changed: 4 ins; 11 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

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

From iklam at openjdk.org  Tue Jun 28 20:13:04 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 20:13:04 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
Message-ID: <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>

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

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comments
>
> src/hotspot/share/runtime/mutex.hpp line 203:
> 
>> 201:   #ifndef PRODUCT
>> 202:     void print_on(outputStream* st) const;
>> 203:     void print() const                      { /*print_on(::tty); */ } // FIXME
> 
> Can you move this print implementation into the .cpp file?

Fixed.

> src/hotspot/share/runtime/threadCrashProtection.hpp line 42:
> 
>> 40: #else
>> 41: # error "No ThreadCrashProtection implementation provided for this OS"
>> 42: #endif
> 
> Shouldn't you use this?
> #define OS_HEADER(basename)            XSTR(OS_HEADER_STEM(basename).hpp)

I fixed it as you suggested. I also fixed semaphore.hpp where I copied the old pattern from.

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

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

From wkemper at openjdk.org  Tue Jun 28 20:37:41 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Jun 2022 20:37:41 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
 <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
Message-ID: <SqKQu6_KeKd3iSPadfTlsGr9PHU7ODPzekf_l3vw_i0=.4a45e2d1-bea0-4541-8429-1c8a6347e084@github.com>

On Tue, 28 Jun 2022 00:03:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Before this change, the heuristic considered the memory available to both the collector and mutators. Since the collector memory is not available to mutators, they may experience an allocation failure before the heuristic could anticipate. With this change, the heuristic looks at the memory available to mutators only. This has the effect of making the heuristic tend to start cycles earlier, thus avoiding degenerated cycles.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments to stay with moved code

Just had a look at the heuristic in upstream and it _is_ using freeset available, so this change fixes a regression introduced only on the generational mode branch.

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

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

From rkennke at openjdk.org  Tue Jun 28 21:05:13 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Jun 2022 21:05:13 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner
In-Reply-To: <cS7EyWvmNBkwDqe23wV8e6-1kpk3iqhitAUMLlMPQ_c=.a5f06ffb-a78b-4bf7-9fd6-2a9e1bf7ab08@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <KSx3dA6fUuSPeKPif6mpjtjfeZoojpOPfv72FQJ2_zA=.3ed51412-ffd3-4105-b4cc-43fe8176ec9a@github.com>
 <cS7EyWvmNBkwDqe23wV8e6-1kpk3iqhitAUMLlMPQ_c=.a5f06ffb-a78b-4bf7-9fd6-2a9e1bf7ab08@github.com>
Message-ID: <lLQrWC6uoQUIqkoJn6IojxoBCbBG4Rgp-hCSYjKzPw4=.e0eedd98-44d9-4132-9cf5-aa8027820dd1@github.com>

On Tue, 28 Jun 2022 13:46:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 689:
>> 
>>> 687: 
>>> 688: void ShenandoahHeap::set_previous_promotion(size_t promoted_bytes) {
>>> 689:   shenandoah_assert_heaplocked();
>> 
>> Is this related and/or relevant?
>
> We can remove that.  It was "somewhat" related to the historical progression that eventually resulted in this refactoring code.  At one point in my development, I had accidentally tried to set_previous_promotion() without having the heap lock, and the results were unpredictable.

Hmm ok. No, leave it there. If it checks an important condition, then it should be useful.

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

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

From rkennke at openjdk.org  Tue Jun 28 21:07:15 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 28 Jun 2022 21:07:15 GMT
Subject: RFR: Adaptive heuristic should take reserved memory into account
 [v2]
In-Reply-To: <SqKQu6_KeKd3iSPadfTlsGr9PHU7ODPzekf_l3vw_i0=.4a45e2d1-bea0-4541-8429-1c8a6347e084@github.com>
References: <RzJenMkf7r7wFVmnMJERhBmc-1_kPuVRGxG-8Wnht4w=.0f055487-43b6-42ce-a237-58ee4ae24cf2@github.com>
 <yEyJyP-hN8YHpE_INqpap6UxIZEfHElXIq8RF8qpcn0=.1dd31224-4501-44d8-8df9-397b97d84e21@github.com>
 <SqKQu6_KeKd3iSPadfTlsGr9PHU7ODPzekf_l3vw_i0=.4a45e2d1-bea0-4541-8429-1c8a6347e084@github.com>
Message-ID: <6b9LBNrfSVgl-q8IoXa5XuKnRAVsBOR8cPSNsG4mohA=.4064503a-efb0-480e-8cde-9e3320895d09@github.com>

On Tue, 28 Jun 2022 20:34:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Just had a look at the heuristic in upstream and it _is_ using freeset available, so this change fixes a regression introduced only on the generational mode branch.

Ok great, then!
Thanks for checking!

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

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

From coleenp at openjdk.org  Tue Jun 28 21:10:43 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 28 Jun 2022 21:10:43 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
 <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
Message-ID: <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>

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

>> src/hotspot/share/runtime/threadCrashProtection.hpp line 42:
>> 
>>> 40: #else
>>> 41: # error "No ThreadCrashProtection implementation provided for this OS"
>>> 42: #endif
>> 
>> Shouldn't you use this?
>> #define OS_HEADER(basename)            XSTR(OS_HEADER_STEM(basename).hpp)
>
> I fixed it as you suggested. I also fixed semaphore.hpp where I copied the old pattern from.

Doesn't the OS_HEADER() -similar macro that handles the posix case too? I don't see it though.

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

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

From kdnilsen at openjdk.org  Tue Jun 28 21:16:15 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 28 Jun 2022 21:16:15 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v2]
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>

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

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

  Isolate the code that reserves evacuation budgets into functions

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

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

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

  Stats: 697 lines in 2 files changed: 358 ins; 336 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah/pull/148.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/148/head:pull/148

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

From iklam at openjdk.org  Tue Jun 28 22:47:42 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 28 Jun 2022 22:47:42 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
 <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
 <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>
Message-ID: <nudMvHCsxKwoGGyBWzt7FSJsAp16ryA8orOwCr6RZHU=.a31f1696-2ea2-4939-b87d-c0d658a8620e@github.com>

On Tue, 28 Jun 2022 21:02:53 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I fixed it as you suggested. I also fixed semaphore.hpp where I copied the old pattern from.
>
> Doesn't the OS_HEADER() -similar macro that handles the posix case too? I don't see it though.

` OS_HEADER(threadCrashProtection)` will give threadCrashProtection_linux.hpp, etc. It won't give us threadCrashProtection_posix.hpp. I didn't want to write three threadCrashProtection_{aix,bsd,linux}.hpp files that each just has a single line that includes the _posix version.

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

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

From dholmes at openjdk.org  Wed Jun 29 04:49:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 29 Jun 2022 04:49:23 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <nudMvHCsxKwoGGyBWzt7FSJsAp16ryA8orOwCr6RZHU=.a31f1696-2ea2-4939-b87d-c0d658a8620e@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
 <-31m1Wil4br9F1BYtK83rqQkl3BVNPHqgbyVt59LnFs=.5f27d919-2ce9-40c2-a72a-fb1fcc69cdc1@github.com>
 <JSjMzksj0vwbWWVEQEbtz1j23aVGvhOKmhcLMirvazg=.92088e3c-65f2-44a9-8933-33f25e3f877f@github.com>
 <nudMvHCsxKwoGGyBWzt7FSJsAp16ryA8orOwCr6RZHU=.a31f1696-2ea2-4939-b87d-c0d658a8620e@github.com>
Message-ID: <CeKhX5WDi1VH-bgCcmhw3Ljd733P8y439ShT63599Ro=.d5e8e436-4e88-4568-b439-49f3b9a33678@github.com>

On Tue, 28 Jun 2022 22:44:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Doesn't the OS_HEADER() -similar macro that handles the posix case too? I don't see it though.
>
> ` OS_HEADER(threadCrashProtection)` will give threadCrashProtection_linux.hpp, etc. It won't give us threadCrashProtection_posix.hpp. I didn't want to write three threadCrashProtection_{aix,bsd,linux}.hpp files that each just has a single line that includes the _posix version.

Yeah no posix support with OS_HEADER.

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

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

From rkennke at openjdk.org  Wed Jun 29 15:26:24 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 29 Jun 2022 15:26:24 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v2]
In-Reply-To: <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
Message-ID: <N4_PtVzyg22GPC3gV34CacNGX6aHtnS_89HfiEtY8EQ=.2e2593f0-805d-4288-b171-feeaad507361@github.com>

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

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

Marked as reviewed by rkennke (Lead).

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

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

From kemperw at amazon.com  Wed Jun 29 18:46:07 2022
From: kemperw at amazon.com (Kemper, William)
Date: Wed, 29 Jun 2022 18:46:07 +0000
Subject: CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna
Message-ID: <1656528367976.39213@amazon.com>

I hereby nominate Y. Srinivas Ramakrishna (Ramki) to Shenandoah Committer.


Ramki (ysr at openjdk.org) has made over 100 critical contributions in the area of garbage collection[1], [2] - especially for CMS. Ramki has joined us to help with the generational mode for Shenandoah.


Votes are due by Wednesday, 17 July 2022, 12:00:00 UTC.


Only current Shenandoah Committers [3] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4].


Thank you,

William


[1] https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits

[2] https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC

[3] https://openjdk.java.net/census
[4] https://openjdk.java.net/projects/#committer-vote

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20220629/eefe4c52/attachment-0001.htm>

From kdnilsen at amazon.com  Wed Jun 29 20:43:51 2022
From: kdnilsen at amazon.com (Nilsen, Kelvin)
Date: Wed, 29 Jun 2022 20:43:51 +0000
Subject: New Shenandoah Committer: Y. Srinivas Ramakrishna
In-Reply-To: <1656528367976.39213@amazon.com>
References: <1656528367976.39213@amazon.com>
Message-ID: <C1C6EA51-5111-4F97-ABFE-452DD532F546@amazon.com>

Thanks William,
I vote in favor.

From: shenandoah-dev <shenandoah-dev-retn at openjdk.org> on behalf of "Kemper, William" <kemperw at amazon.com>
Date: Wednesday, June 29, 2022 at 1:42 PM
To: "shenandoah-dev at openjdk.org" <shenandoah-dev at openjdk.org>
Subject: CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna


I hereby nominate Y. Srinivas Ramakrishna (Ramki) to Shenandoah Committer.



Ramki (ysr at openjdk.org) has made over 100 critical contributions in the area of garbage collection[1], [2] - especially for CMS. Ramki has joined us to help with the generational mode for Shenandoah.



Votes are due by Wednesday, 17 July 2022, 12:00:00 UTC.


Only current Shenandoah Committers [3] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4].



Thank you,

William



[1] https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits

[2] https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC
[3] https://openjdk.java.net/census
[4] https://openjdk.java.net/projects/#committer-vote


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20220629/f71444b0/attachment.htm>

From rkennke at redhat.com  Wed Jun 29 21:01:47 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 29 Jun 2022 23:01:47 +0200
Subject: CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna
In-Reply-To: <1656528367976.39213@amazon.com>
References: <1656528367976.39213@amazon.com>
Message-ID: <4cfb68ab-99f6-048e-0afc-f11e2a73ab18@redhat.com>

Hi William,

May I suggest that we first see a few (sponsored) contributions to 
Shenandoah by Ramki? This way, Ramki has a chance to become familiar 
with both Shenandoah and also with the process of getting a change 
reviewed, accepted, sponsored and integrated into a JDK project.

If it's useful, I'll be happy to appoint Ramki to Shenandoah Author.
https://openjdk.org/projects/#appointing-author

Does that make sense?

Thank you,
Roman

> I hereby nominate?Y. Srinivas Ramakrishna (Ramki) to Shenandoah Committer.
> 
> 
> Ramki (ysr at openjdk.org) has made over 100 critical contributions in the 
> area of garbage collection[1], [2] - especially for CMS. Ramki has 
> joined us to help with the generational mode for Shenandoah.
> 
> 
> Votes are due by Wednesday, 17?July 2022, 12:00:00 UTC.
> 
> 
> Only current Shenandoah?Committers [3] are eligible to vote on this 
> nomination.? Votes must be cast in the open by replying to this mailing 
> list.
> 
> For Lazy Consensus voting instructions, see [4].
> 
> 
> Thank you,
> 
> William
> 
> 
> [1] 
> https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits 
> <https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits>
> 
> [2] 
> https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC 
> <https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC>
> 
> [3] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [4] https://openjdk.java.net/projects/#committer-vote 
> <https://openjdk.java.net/projects/#committer-vote>
> 
> 


From kdnilsen at amazon.com  Wed Jun 29 21:06:35 2022
From: kdnilsen at amazon.com (Nilsen, Kelvin)
Date: Wed, 29 Jun 2022 21:06:35 +0000
Subject: New Shenandoah Committer: Y. Srinivas Ramakrishna
In-Reply-To: <1656528367976.39213@amazon.com>
References: <1656528367976.39213@amazon.com>
Message-ID: <18008980-1FE1-4379-900A-E421D84221C5@amazon.com>

Vote: yes

From: shenandoah-dev <shenandoah-dev-retn at openjdk.org> on behalf of "Kemper, William" <kemperw at amazon.com>
Date: Wednesday, June 29, 2022 at 1:42 PM
To: "shenandoah-dev at openjdk.org" <shenandoah-dev at openjdk.org>
Subject: CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna


I hereby nominate Y. Srinivas Ramakrishna (Ramki) to Shenandoah Committer.



Ramki (ysr at openjdk.org) has made over 100 critical contributions in the area of garbage collection[1], [2] - especially for CMS. Ramki has joined us to help with the generational mode for Shenandoah.



Votes are due by Wednesday, 17 July 2022, 12:00:00 UTC.


Only current Shenandoah Committers [3] are eligible to vote on this nomination.  Votes must be cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [4].



Thank you,

William



[1] https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits

[2] https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC
[3] https://openjdk.java.net/census
[4] https://openjdk.java.net/projects/#committer-vote


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20220629/0c619e47/attachment-0001.htm>

From kemperw at amazon.com  Wed Jun 29 21:09:49 2022
From: kemperw at amazon.com (Kemper, William)
Date: Wed, 29 Jun 2022 21:09:49 +0000
Subject: CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna
In-Reply-To: <4cfb68ab-99f6-048e-0afc-f11e2a73ab18@redhat.com>
References: <1656528367976.39213@amazon.com>,
 <4cfb68ab-99f6-048e-0afc-f11e2a73ab18@redhat.com>
Message-ID: <1656536988832.99504@amazon.com>

Yes, of course, that's fine. Please appoint him to be a Shenandoah Author. Do I need to do anything to rescind the nomination for committer? Will Ramki be able to participate in reviews as an author?

Thanks,
William

________________________________________
From: Roman Kennke <rkennke at redhat.com>
Sent: Wednesday, June 29, 2022 2:01 PM
To: Kemper, William; shenandoah-dev at openjdk.org
Subject: RE: [EXTERNAL]CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hi William,

May I suggest that we first see a few (sponsored) contributions to
Shenandoah by Ramki? This way, Ramki has a chance to become familiar
with both Shenandoah and also with the process of getting a change
reviewed, accepted, sponsored and integrated into a JDK project.

If it's useful, I'll be happy to appoint Ramki to Shenandoah Author.
https://openjdk.org/projects/#appointing-author

Does that make sense?

Thank you,
Roman

> I hereby nominate Y. Srinivas Ramakrishna (Ramki) to Shenandoah Committer.
>
>
> Ramki (ysr at openjdk.org) has made over 100 critical contributions in the
> area of garbage collection[1], [2] - especially for CMS. Ramki has
> joined us to help with the generational mode for Shenandoah.
>
>
> Votes are due by Wednesday, 17 July 2022, 12:00:00 UTC.
>
>
> Only current Shenandoah Committers [3] are eligible to vote on this
> nomination.  Votes must be cast in the open by replying to this mailing
> list.
>
> For Lazy Consensus voting instructions, see [4].
>
>
> Thank you,
>
> William
>
>
> [1]
> https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits
> <https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits>
>
> [2]
> https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC
> <https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC>
>
> [3] https://openjdk.java.net/census <https://openjdk.java.net/census>
> [4] https://openjdk.java.net/projects/#committer-vote
> <https://openjdk.java.net/projects/#committer-vote>
>
>


From rkennke at redhat.com  Wed Jun 29 21:47:56 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 29 Jun 2022 23:47:56 +0200
Subject: CFV: New Shenandoah Committer: Y. Srinivas Ramakrishna
In-Reply-To: <1656536988832.99504@amazon.com>
References: <1656528367976.39213@amazon.com>
 <4cfb68ab-99f6-048e-0afc-f11e2a73ab18@redhat.com>
 <1656536988832.99504@amazon.com>
Message-ID: <CAAN-KyhXqasQRSf4So5PsghagE0eiDORdRmQn5TQHLomrUcaHg@mail.gmail.com>

Hi William,

Yes, of course, that's fine. Please appoint him to be a Shenandoah Author.


I will need Ramki's email address for that.

Do I need to do anything to rescind the nomination for committer?


No.

Willl Ramki be able to participate in reviews as an author?
>

I think so, yes. I am not even sure if the Author role is required for
this, having a GitHub account may suffice (but I'm not sure). But it will
not be recorded as official review, and still require another committer to
ack it.

Thanks,
Roman




> Thanks,
> William
>
> ________________________________________
> From: Roman Kennke <rkennke at redhat.com>
> Sent: Wednesday, June 29, 2022 2:01 PM
> To: Kemper, William; shenandoah-dev at openjdk.org
> Subject: RE: [EXTERNAL]CFV: New Shenandoah Committer: Y. Srinivas
> Ramakrishna
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> Hi William,
>
> May I suggest that we first see a few (sponsored) contributions to
> Shenandoah by Ramki? This way, Ramki has a chance to become familiar
> with both Shenandoah and also with the process of getting a change
> reviewed, accepted, sponsored and integrated into a JDK project.
>
> If it's useful, I'll be happy to appoint Ramki to Shenandoah Author.
> https://openjdk.org/projects/#appointing-author
>
> Does that make sense?
>
> Thank you,
> Roman
>
> > I hereby nominate Y. Srinivas Ramakrishna (Ramki) to Shenandoah
> Committer.
> >
> >
> > Ramki (ysr at openjdk.org) has made over 100 critical contributions in the
> > area of garbage collection[1], [2] - especially for CMS. Ramki has
> > joined us to help with the generational mode for Shenandoah.
> >
> >
> > Votes are due by Wednesday, 17 July 2022, 12:00:00 UTC.
> >
> >
> > Only current Shenandoah Committers [3] are eligible to vote on this
> > nomination.  Votes must be cast in the open by replying to this mailing
> > list.
> >
> > For Lazy Consensus voting instructions, see [4].
> >
> >
> > Thank you,
> >
> > William
> >
> >
> > [1]
> >
> https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits
> > <
> https://github.com/openjdk/jdk/search?q=author-email%3Aysr%40openjdk.org&type=commits
> >
> >
> > [2]
> >
> https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC
> > <
> https://bugs.openjdk.org/browse/JDK-8178743?filter=-1&jql=assignee%20%3D%20ysr%20order%20by%20createdDate%20DESC
> >
> >
> > [3] https://openjdk.java.net/census <https://openjdk.java.net/census>
> > [4] https://openjdk.java.net/projects/#committer-vote
> > <https://openjdk.java.net/projects/#committer-vote>
> >
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20220629/7054adfb/attachment.htm>

From zgu at openjdk.org  Thu Jun 30 19:42:42 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 30 Jun 2022 19:42:42 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v4]
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <kawmCfep4sR3hXJ6_gaqYe5CnW1_tDjCxJ6aQpwcf5s=.95fc5e59-68b8-4c68-82fc-542c17f5189d@github.com>

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

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

 - Aleksey's comment
 - Merge branch 'master' into JDK-8287805-evac-updt-closures
 - v1
 - Remove unused impl
 - Review feedback
 - Merge branch 'master' into JDK-8287805-evac-updt-closures
 - 8287805: Shenandoah: consolidate evacuate-update-root closures
 - Merge branch 'master' into consolidate_evac_root_closures
 - v0
 - v0

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

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

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

  Stats: 26049 lines in 302 files changed: 23432 ins; 1854 del; 763 mod
  Patch: https://git.openjdk.org/jdk/pull/9023.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9023/head:pull/9023

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