From duke at openjdk.java.net  Mon Nov  1 06:26:12 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Mon, 1 Nov 2021 06:26:12 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <sJENvEavIhKtJcHT1PjKWH0PqC6vX1dmbudmSbpGDro=.5827979e-8e73-44ae-bd74-98a11801a141@github.com>

On Fri, 29 Oct 2021 08:23:30 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

src/hotspot/share/gc/g1/g1AllocRegion.cpp line 58:

> 56:   _alloc_region->update_bot_at(addr, size);
> 57: }
> 58: 

May I ask why do we need to update for the filler objects? Because we are not scanning them.

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

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


From duke at openjdk.java.net  Mon Nov  1 06:34:12 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Mon, 1 Nov 2021 06:34:12 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <p4ASb_jSfCb0HQtpZ6E93HKMJvgcfI0nQSsjre6RWMY=.26cc59d8-deb9-43fd-aef0-c7e90e165d28@github.com>

On Fri, 29 Oct 2021 08:23:30 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

Another thought is maybe ``G1BlockOffsetTable::set_offset_array/_raw`` don't need to be conservatively ordered, that is, they can be memory_order_relaxed. Since now all updates are in the pause and there is no concurrent readers.

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

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


From ayang at openjdk.java.net  Mon Nov  1 09:10:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 1 Nov 2021 09:10:13 GMT
Subject: RFR: 8276107: Preventive collections trigger before maxing out
 heap [v2]
In-Reply-To: <gpt2bWocco2KvAOos2ZDI29BUYDnHoxHWBdGVWQ4kHw=.3311f27f-04b5-42be-abb3-dbbb52ca14b6@github.com>
References: <MSlasvz7nkhAdfl98p4X4Nc-Y2wk4TTFXCce8Ug87Ag=.6c2bfbb7-cda2-4873-adff-0307f2025464@github.com>
 <gpt2bWocco2KvAOos2ZDI29BUYDnHoxHWBdGVWQ4kHw=.3311f27f-04b5-42be-abb3-dbbb52ca14b6@github.com>
Message-ID: <CCKA4IgTiTpv1zV_4NIcb4blLLEC2S7lWa22L5QApyQ=.e5d67956-c136-4f9c-b052-69206e58c2ec@github.com>

On Fri, 29 Oct 2021 09:31:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this small fix for an issue where preventive gcs that are supposed to prevent evacuation failure were also started if there were only not enough free committed regions available but more than enough uncommitted regions to expand the heap (to avoid the evacuation failure).
>> 
>> Testing: gha, tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix log message

Marked as reviewed by ayang (Reviewer).

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

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


From stefank at openjdk.java.net  Mon Nov  1 09:31:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 1 Nov 2021 09:31:14 GMT
Subject: RFR: 8275527: Refactor forward pointer access [v4]
In-Reply-To: <tu8-LJVLLI-0yU9Fsvdnqkx9sTkfarZu3XNIElJ0kak=.6c3578d7-0a9a-447e-a167-27c412ac200f@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
 <tu8-LJVLLI-0yU9Fsvdnqkx9sTkfarZu3XNIElJ0kak=.6c3578d7-0a9a-447e-a167-27c412ac200f@github.com>
Message-ID: <L12GPa4-qxtJlMxtEOEpiVc4v1TJ_-DwFqC5DWOarI4=.35af6235-3555-41e6-b0c6-67e011a83829@github.com>

On Thu, 28 Oct 2021 12:35:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.
>> 
>> This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.
>> 
>> Testing:
>>  - [x] tier
>>  - [x] tier2
>>  - [x] hotspot_gc
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move forward impl into markWord and add assert

Thanks for doing this change. This looks good to me. I've added a comment below that I think would be nice to get resolved somehow, though I don't need to re-review if you update with any of the suggestions.

src/hotspot/share/oops/markWord.hpp line 253:

> 251:     return cast_to_oop(decode_pointer());
> 252:   }
> 253: };

This brings the forwarded/forwardee terminology into the markWord. The markWord was previously decoupled from those to concepts. I would personally let those function names stay in oopDesc and not leak down into the markWord. If you do want to keep it here, could you update the comments at the top that describes the bits?

//    [ptr             | 11]  marked             used to mark an object

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

Marked as reviewed by stefank (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Nov  1 09:34:11 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 1 Nov 2021 09:34:11 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <sJENvEavIhKtJcHT1PjKWH0PqC6vX1dmbudmSbpGDro=.5827979e-8e73-44ae-bd74-98a11801a141@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <sJENvEavIhKtJcHT1PjKWH0PqC6vX1dmbudmSbpGDro=.5827979e-8e73-44ae-bd74-98a11801a141@github.com>
Message-ID: <GhYhyVseO7X8dv_VMoELRJiPsT2doBPsfCuYYFkRWM4=.648df03f-a743-4655-b947-52f5e4864fc6@github.com>

On Mon, 1 Nov 2021 06:22:51 GMT, Yude Lin <duke at openjdk.java.net> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> src/hotspot/share/gc/g1/g1AllocRegion.cpp line 58:
> 
>> 56:   _alloc_region->update_bot_at(addr, size);
>> 57: }
>> 58: 
> 
> May I ask why do we need to update for the filler objects? Because we are not scanning them.

Good question. You are correct in that we never need to scan these parts because of dirty cards, but during remembered set rebuilding (_see_: `G1RebuildRemSetHeapRegionClosure::rebuild_rem_set_in_region(...)`) we include the whole region when looking for references to other heap regions. 

There might be some good way to avoid scanning those parts during rebuild, but such investigation is out of scope for this PR.

Thanks for reviewing ?

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

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


From sjohanss at openjdk.java.net  Mon Nov  1 09:37:08 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 1 Nov 2021 09:37:08 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <p4ASb_jSfCb0HQtpZ6E93HKMJvgcfI0nQSsjre6RWMY=.26cc59d8-deb9-43fd-aef0-c7e90e165d28@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <p4ASb_jSfCb0HQtpZ6E93HKMJvgcfI0nQSsjre6RWMY=.26cc59d8-deb9-43fd-aef0-c7e90e165d28@github.com>
Message-ID: <v4u-NsjKAqkQnc6j71apcbwlvpughr8dm29tCfLT3u0=.28fb419a-2829-4636-9a7b-8d047ce1d7c9@github.com>

On Mon, 1 Nov 2021 06:31:18 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Another thought is maybe `G1BlockOffsetTable::set_offset_array/_raw` don't need to be conservatively ordered, that is, they can be memory_order_relaxed. Since now all updates are in the pause and there is no concurrent readers.

Another good point. I think such change should also be done as a separate PR and we should probably also look at hardening the code to not allow updates because the BOT is not precise (because it should be). I will file issues for these two things.

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

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


From shade at openjdk.java.net  Mon Nov  1 11:30:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Nov 2021 11:30:09 GMT
Subject: RFR: 8276201: Shenandoah: Race results degenerated GC to enter
 wrong entry point
In-Reply-To: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
References: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
Message-ID: <w1nGzVFK8IRH84TgGmFG5fpW6K36CNyqEeqwqZ45bTA=.a7f11edd-988e-4b50-83c3-1a38040f780b@github.com>

On Sat, 30 Oct 2021 12:56:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point.
> 
> Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion.
> 
> The solution is to consult concurrent_mark_in_progress flag when selects degen-point.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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


From zgu at openjdk.java.net  Mon Nov  1 12:21:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 12:21:19 GMT
Subject: RFR: 8276201: Shenandoah: Race results degenerated GC to enter
 wrong entry point
In-Reply-To: <w1nGzVFK8IRH84TgGmFG5fpW6K36CNyqEeqwqZ45bTA=.a7f11edd-988e-4b50-83c3-1a38040f780b@github.com>
References: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
 <w1nGzVFK8IRH84TgGmFG5fpW6K36CNyqEeqwqZ45bTA=.a7f11edd-988e-4b50-83c3-1a38040f780b@github.com>
Message-ID: <z22ZOFiVtF_ap5OK36jVhy25GxDo52Luftl9-SL5Okc=.0adc3d4b-7254-4783-8183-464a8448693f@github.com>

On Mon, 1 Nov 2021 11:27:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point.
>> 
>> Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion.
>> 
>> The solution is to consult concurrent_mark_in_progress flag when selects degen-point.
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>
> Looks fine.

Thanks, @shipilev

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

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


From zgu at openjdk.java.net  Mon Nov  1 12:21:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 12:21:19 GMT
Subject: Integrated: 8276201: Shenandoah: Race results degenerated GC to enter
 wrong entry point
In-Reply-To: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
References: <VluuLdWky3-uk2sIm4QcCcZx35lmBujemyPgVtAmD1I=.07a08cc7-2c70-4b42-a9aa-e16f27112a6c@github.com>
Message-ID: <Pmw4HY0RiFymeYUzN_9Syeffw3r7DLa6D9EPjlBF_BY=.619b12c2-af25-4aea-89c4-edc08a2c2806@github.com>

On Sat, 30 Oct 2021 12:56:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point.
> 
> Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion.
> 
> The solution is to consult concurrent_mark_in_progress flag when selects degen-point.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

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

8276201: Shenandoah: Race results degenerated GC to enter wrong entry point

Reviewed-by: shade

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

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


From zgu at openjdk.java.net  Mon Nov  1 15:28:24 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 15:28:24 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
Message-ID: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>

There are few bugs in current implementation:
1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.

2) Does not notify waiters upon completion of iteration at safepoints

3) Unnecessary held CodeCache_lock during concurrent code cache iteration.

Test:
- [x] hotspot_gc_shenandoah on Linux x86_64
- [x] hotspot_gc_shenandoah on Linux aarch64

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

Commit messages:
 - v0

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

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


From lkorinth at openjdk.java.net  Mon Nov  1 15:41:27 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 1 Nov 2021 15:41:27 GMT
Subject: Integrated: 8276121: G1: Remove unused and uninitialized _g1h in
 g1SATBMarkQueueSet.hpp
In-Reply-To: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com>
References: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com>
Message-ID: <YEwadz0h-DkApRdRmsayslPQ5rm0dHnWMQJPSx63ccA=.3665e9f6-1889-40c4-9f0c-e9d92d4e5650@github.com>

On Fri, 29 Oct 2021 12:18:22 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Code seems to compile without the field.

This pull request has now been integrated.

Changeset: c8abe354
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8abe354c1ddc988ff54b9a96a4a825e2aa70f4b
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp

Reviewed-by: ayang, tschatzl

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

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


From shade at openjdk.java.net  Mon Nov  1 15:55:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Nov 2021 15:55:09 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
Message-ID: <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>

On Mon, 1 Nov 2021 15:19:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are few bugs in current implementation:
> 1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.
> 
> 2) Does not notify waiters upon completion of iteration at safepoints
> 
> 3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64
> - [x] hotspot_gc_shenandoah on Linux aarch64

Looks okay. Do we miss `_codecache_snapshot = NULL;` in  `~ShenandoahConcurrentRootScanner`?

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

Marked as reviewed by shade (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Nov  1 16:52:23 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 1 Nov 2021 16:52:23 GMT
Subject: RFR: 8276107: Preventive collections trigger before maxing out
 heap [v2]
In-Reply-To: <CCKA4IgTiTpv1zV_4NIcb4blLLEC2S7lWa22L5QApyQ=.e5d67956-c136-4f9c-b052-69206e58c2ec@github.com>
References: <MSlasvz7nkhAdfl98p4X4Nc-Y2wk4TTFXCce8Ug87Ag=.6c2bfbb7-cda2-4873-adff-0307f2025464@github.com>
 <gpt2bWocco2KvAOos2ZDI29BUYDnHoxHWBdGVWQ4kHw=.3311f27f-04b5-42be-abb3-dbbb52ca14b6@github.com>
 <CCKA4IgTiTpv1zV_4NIcb4blLLEC2S7lWa22L5QApyQ=.e5d67956-c136-4f9c-b052-69206e58c2ec@github.com>
Message-ID: <oDcKJxMgGIbUxEZu4iFQIqTcOC9j97trOKmdkJ9adX8=.9a06ebc3-3c29-418b-80d2-57d9839088f9@github.com>

On Mon, 1 Nov 2021 09:07:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix log message
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Nov  1 16:52:24 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 1 Nov 2021 16:52:24 GMT
Subject: Integrated: 8276107: Preventive collections trigger before maxing out
 heap
In-Reply-To: <MSlasvz7nkhAdfl98p4X4Nc-Y2wk4TTFXCce8Ug87Ag=.6c2bfbb7-cda2-4873-adff-0307f2025464@github.com>
References: <MSlasvz7nkhAdfl98p4X4Nc-Y2wk4TTFXCce8Ug87Ag=.6c2bfbb7-cda2-4873-adff-0307f2025464@github.com>
Message-ID: <kSV-7GxhOkzfY0TEaQDG8p0oNtupYoVa8RzRZx4teu4=.97380fec-f396-4d4a-babd-b4dcf1c4ca15@github.com>

On Thu, 28 Oct 2021 16:09:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this small fix for an issue where preventive gcs that are supposed to prevent evacuation failure were also started if there were only not enough free committed regions available but more than enough uncommitted regions to expand the heap (to avoid the evacuation failure).
> 
> Testing: gha, tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: e265f838
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e265f83858b84451258677f130f98be5375a417a
Stats:     13 lines in 1 file changed: 2 ins; 0 del; 11 mod

8276107: Preventive collections trigger before maxing out heap

Reviewed-by: sjohanss, ayang

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

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


From zgu at openjdk.java.net  Mon Nov  1 16:53:22 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 16:53:22 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
 <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
Message-ID: <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>

On Mon, 1 Nov 2021 15:52:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ShenandoahConcurrentRootScanner

Does it matter?

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

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


From shade at openjdk.java.net  Mon Nov  1 16:53:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Nov 2021 16:53:22 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
 <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
 <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>
Message-ID: <AWyBBKXOnRf3_PPIk6pkH4lV5qOc1OI6VRHhzqbpCGM=.b3ff8dd8-b74b-47c6-8adf-7355688781a0@github.com>

On Mon, 1 Nov 2021 16:48:03 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > ShenandoahConcurrentRootScanner
> 
> Does it matter?

You tell me, I think it would be full of dangling references after we are done with scanner? The similar reason why we do `_table = NULL` in a similar method in another iterator. You don't have to change it here, but maybe a simple cleanup for later.

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

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


From zgu at openjdk.java.net  Mon Nov  1 19:42:18 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 19:42:18 GMT
Subject: RFR: 8276205: Shenandoah: CodeCache_lock should always be held for
 initializing code cache iteration
In-Reply-To: <AWyBBKXOnRf3_PPIk6pkH4lV5qOc1OI6VRHhzqbpCGM=.b3ff8dd8-b74b-47c6-8adf-7355688781a0@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
 <sZaU-VddY-JPLl2FXIqp0rQWwfrFKJLC5lBsWQy0Wos=.adafcc9b-4ab9-40ec-9d6c-c222e01962e5@github.com>
 <BQ_s4IYENcR-hXjnAjXLLQkKvN28GIPDui7TStkMu18=.faceae96-e468-47b3-ad40-b7c65136cd93@github.com>
 <AWyBBKXOnRf3_PPIk6pkH4lV5qOc1OI6VRHhzqbpCGM=.b3ff8dd8-b74b-47c6-8adf-7355688781a0@github.com>
Message-ID: <9EKpAOjDkyBJXPSt1VO3U9_tmuXzJLdHVGxbetTYF1g=.cdd67c2e-0ca7-407f-8d88-888d15c1c0b0@github.com>

On Mon, 1 Nov 2021 16:49:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > ShenandoahConcurrentRootScanner
> > 
> > 
> > Does it matter?
> 
> You tell me, I think it would be full of dangling references after we are done with scanner? The similar reason why we do `_table = NULL` in a similar method in another iterator. You don't have to change it here, but maybe a simple cleanup for later.

Yea, there is inconsistent among these iterators. The code is in destructors, I don't see it matters, cause accessing dangling references in a deallocated object is a fatal bug.

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

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


From zgu at openjdk.java.net  Mon Nov  1 19:42:19 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 1 Nov 2021 19:42:19 GMT
Subject: Integrated: 8276205: Shenandoah: CodeCache_lock should always be held
 for initializing code cache iteration
In-Reply-To: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
References: <4we-MwSKlilF2l7r0Ot-5SFbYGeZBQnD4N0tGoOiKGQ=.59b2a5f8-bc43-4947-abf3-d6b76c447700@github.com>
Message-ID: <ECwA5mrvfSWvzMRJ3ruY4Zupk81ejq_tZ0F_v2o3Qv8=.bc3897b8-7f98-4b25-b4b0-c2f89c290804@github.com>

On Mon, 1 Nov 2021 15:19:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are few bugs in current implementation:
> 1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.
> 
> 2) Does not notify waiters upon completion of iteration at safepoints
> 
> 3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
> 
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64
> - [x] hotspot_gc_shenandoah on Linux aarch64

This pull request has now been integrated.

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

8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration

Reviewed-by: shade

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

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


From sjohanss at openjdk.java.net  Mon Nov  1 20:01:11 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 1 Nov 2021 20:01:11 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <v4u-NsjKAqkQnc6j71apcbwlvpughr8dm29tCfLT3u0=.28fb419a-2829-4636-9a7b-8d047ce1d7c9@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <p4ASb_jSfCb0HQtpZ6E93HKMJvgcfI0nQSsjre6RWMY=.26cc59d8-deb9-43fd-aef0-c7e90e165d28@github.com>
 <v4u-NsjKAqkQnc6j71apcbwlvpughr8dm29tCfLT3u0=.28fb419a-2829-4636-9a7b-8d047ce1d7c9@github.com>
Message-ID: <VzP62HsfjG-Z8jSc8nX9oUycmzYa6GvKT6qtMt6_SWc=.a16de804-1ec3-41c9-9660-a137eee6e224@github.com>

On Mon, 1 Nov 2021 09:34:16 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Another thought is maybe `G1BlockOffsetTable::set_offset_array/_raw` don't need to be conservatively ordered, that is, they can be memory_order_relaxed. Since now all updates are in the pause and there is no concurrent readers.

Took a closer look at `G1BlockOffsetTable::set_offset_array/_raw`, it uses `Atomic::store(...)` and if I'm not mistaken that will not be "conservatively ordered".

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

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


From kbarrett at openjdk.java.net  Tue Nov  2 01:36:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 2 Nov 2021 01:36:28 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size
Message-ID: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>

Please review this change to PretouchTask to page-align the chunk size.
Aligning down is used because it's easy; aligning up would require dealing
with possible overflow or verifying that overflow isn't possible.

Testing:
mach5 tier1

Locally (linux-x64) java -version with pretouch task logging and various
chunk sizes, manually verifying the number of workers was as expected.

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

Commit messages:
 - page-align chunk size

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

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


From duke at openjdk.java.net  Tue Nov  2 03:44:08 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 2 Nov 2021 03:44:08 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <VzP62HsfjG-Z8jSc8nX9oUycmzYa6GvKT6qtMt6_SWc=.a16de804-1ec3-41c9-9660-a137eee6e224@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <p4ASb_jSfCb0HQtpZ6E93HKMJvgcfI0nQSsjre6RWMY=.26cc59d8-deb9-43fd-aef0-c7e90e165d28@github.com>
 <v4u-NsjKAqkQnc6j71apcbwlvpughr8dm29tCfLT3u0=.28fb419a-2829-4636-9a7b-8d047ce1d7c9@github.com>
 <VzP62HsfjG-Z8jSc8nX9oUycmzYa6GvKT6qtMt6_SWc=.a16de804-1ec3-41c9-9660-a137eee6e224@github.com>
Message-ID: <NUcM_yivoaf0JdmxUzy_TBkvRALyc29Q4SUR3jH1K6o=.653e428b-def8-4eb6-8d88-62edcd8cfc0e@github.com>

On Mon, 1 Nov 2021 19:58:13 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > Another thought is maybe `G1BlockOffsetTable::set_offset_array/_raw` don't need to be conservatively ordered, that is, they can be memory_order_relaxed. Since now all updates are in the pause and there is no concurrent readers.
> 
> Took a closer look at `G1BlockOffsetTable::set_offset_array/_raw`, it uses `Atomic::store(...)` and if I'm not mistaken that will not be "conservatively ordered".

You are right, it's not conservatively ordered. My bad : )

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

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


From stefank at openjdk.java.net  Tue Nov  2 07:42:13 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 2 Nov 2021 07:42:13 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size
In-Reply-To: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
Message-ID: <G8npnt5Ih7wwgG-cLMIbykhmi7O2Kfd5cXdbR6MrGqY=.55353752-6c8d-4cb5-accd-9ebe4662f843@github.com>

On Tue, 2 Nov 2021 01:28:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to PretouchTask to page-align the chunk size.
> Aligning down is used because it's easy; aligning up would require dealing
> with possible overflow or verifying that overflow isn't possible.
> 
> Testing:
> mach5 tier1
> 
> Locally (linux-x64) java -version with pretouch task logging and various
> chunk sizes, manually verifying the number of workers was as expected.

Marked as reviewed by stefank (Reviewer).

src/hotspot/share/gc/shared/pretouchTask.cpp line 73:

> 71:   // Page-align the chunk size, so if start_address is also page-aligned (as
> 72:   // is common) then there won't be any pages shared by multiple chunks.
> 73:   chunk_size = align_down(chunk_size, page_size);

This looks like a place where align_down_bounded could be used. Something like this:

size_t chunk_size = align_down_bounded(PretouchTask::chunk_size(), page_size);

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

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


From mli at openjdk.java.net  Wed Nov  3 01:09:34 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 01:09:34 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v18]
In-Reply-To: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
Message-ID: <AmifFFQAiAS8b5Go2vi0_wNI2qw7GmACek9CUaPgA-Q=.1beadb39-818d-49e8-8747-911280650133@github.com>

> This is a try to optimize evcuation failure for regions.
> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
> 
> I have tested it with following parameters, 
> 
> -   -XX:+ParallelGCThreads=1/32/64
> -   -XX:G1EvacuationFailureALotInterval=1
> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
> 
> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
> 
> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.

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

 - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
 - Refine code based on Thomas' suggestion
 - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
 - Fix compilation error
 - Fix compilation error
 - Refactor as Thomas suggested
 - Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR
 - Add asserts, comments
 - Use refactored G1SegmentedArray rather than home-made Array+Node
 - Fix wrong merge
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bb92fb02...d33f87b4

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

Changes: https://git.openjdk.java.net/jdk/pull/5181/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=17
  Stats: 349 lines in 12 files changed: 311 ins; 5 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5181.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181

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


From mli at openjdk.java.net  Wed Nov  3 03:33:27 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 03:33:27 GMT
Subject: RFR: 8276298: G1: Fix or remove G1SegmentedArrayBufferList::add
Message-ID: <jtx-etg0XrYG77ApmVKSQW-P-mKSLz0GFpdHOqduWb4=.145c2080-50dd-4b6a-818d-bac996c3c921@github.com>

This is minor removal of unused method G1SegmentedArrayBufferList::add.

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

Commit messages:
 - Merge branch 'openjdk:master' into refine-G1CardSetFreePool-memory_sizes
 - Initial commits

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

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


From mli at openjdk.java.net  Wed Nov  3 03:45:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 03:45:41 GMT
Subject: RFR: 8276298: G1: Fix or remove G1SegmentedArrayBufferList::add
 [v2]
In-Reply-To: <jtx-etg0XrYG77ApmVKSQW-P-mKSLz0GFpdHOqduWb4=.145c2080-50dd-4b6a-818d-bac996c3c921@github.com>
References: <jtx-etg0XrYG77ApmVKSQW-P-mKSLz0GFpdHOqduWb4=.145c2080-50dd-4b6a-818d-bac996c3c921@github.com>
Message-ID: <t57AqxpUV18rydQViSDnNicOMaw5dsMD5NHUjZolC3M=.d5c957a2-50ec-4fe6-8b94-c233a87a3e5c@github.com>

> This is minor removal of unused method G1SegmentedArrayBufferList::add.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Add assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6223/files
  - new: https://git.openjdk.java.net/jdk/pull/6223/files/b3c46246..b48a4e4d

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

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

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


From mli at openjdk.java.net  Wed Nov  3 03:45:42 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 03:45:42 GMT
Subject: Withdrawn: 8276298: G1: Fix or remove G1SegmentedArrayBufferList::add
In-Reply-To: <jtx-etg0XrYG77ApmVKSQW-P-mKSLz0GFpdHOqduWb4=.145c2080-50dd-4b6a-818d-bac996c3c921@github.com>
References: <jtx-etg0XrYG77ApmVKSQW-P-mKSLz0GFpdHOqduWb4=.145c2080-50dd-4b6a-818d-bac996c3c921@github.com>
Message-ID: <3d2lbBwFl_5zSf5S3EsPjVvNoK6Smk4bFbL6eVD_Ggg=.2a6b2b31-5ba2-434e-81a2-b9c428707401@github.com>

On Wed, 3 Nov 2021 03:25:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is minor removal of unused method G1SegmentedArrayBufferList::add.

This pull request has been closed without being integrated.

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

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


From mli at openjdk.java.net  Wed Nov  3 03:53:31 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 03:53:31 GMT
Subject: RFR: 8276298: G1: Fix or remove G1SegmentedArrayBufferList::add
Message-ID: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>

This is minor removal of unused method G1SegmentedArrayBufferList::add.

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

Commit messages:
 - Merge branch 'openjdk:master' into remove-G1SegmentedArrayBufferList-add
 - Initial commit

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

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


From mli at openjdk.java.net  Wed Nov  3 03:54:21 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 03:54:21 GMT
Subject: RFR: 8276301: G1: Refine implementation of
 G1CardSetFreePool::memory_sizes()
Message-ID: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>

Implementation of G1CardSetFreePool::memory_sizes() is not straight, this is to refine the implementation.

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

Commit messages:
 - Add assert
 - Merge branch 'openjdk:master' into refine-G1CardSetFreePool-memory_sizes
 - Initial commits

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

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


From mli at openjdk.java.net  Wed Nov  3 03:59:15 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 03:59:15 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v18]
In-Reply-To: <AmifFFQAiAS8b5Go2vi0_wNI2qw7GmACek9CUaPgA-Q=.1beadb39-818d-49e8-8747-911280650133@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <AmifFFQAiAS8b5Go2vi0_wNI2qw7GmACek9CUaPgA-Q=.1beadb39-818d-49e8-8747-911280650133@github.com>
Message-ID: <Vz6Hgd01eSKYZqkQYiMPt6MoVEB1yX-mpxA3cV9b7-U=.492c6a41-2a21-4d2c-8492-a68c9860ce6d@github.com>

On Wed, 3 Nov 2021 01:09:34 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a try to optimize evcuation failure for regions.
>> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
>> 
>> I have tested it with following parameters, 
>> 
>> -   -XX:+ParallelGCThreads=1/32/64
>> -   -XX:G1EvacuationFailureALotInterval=1
>> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
>> 
>> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
>> 
>> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
>  - Refine code based on Thomas' suggestion
>  - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
>  - Fix compilation error
>  - Fix compilation error
>  - Refactor as Thomas suggested
>  - Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR
>  - Add asserts, comments
>  - Use refactored G1SegmentedArray rather than home-made Array+Node
>  - Fix wrong merge
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bb92fb02...d33f87b4

Kindly reminder ~

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

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


From tschatzl at openjdk.java.net  Wed Nov  3 10:57:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 10:57:20 GMT
Subject: RFR: 8276540: Howl Full CardSet container iteration marks too many
 cards
Message-ID: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>

Hi all,

  can I have reviews for this change that fixes how many cards are being iterated over during Howl Full CardSet container iteration? There is no need to iterate over `max_cards_in_region()` cards, it is sufficient to iterate just over the area that this Howl partition represents, i.e. `num_cards_in_howl_bitmap()`.

I will change the way to iterate over this card set container in JDK-8276548 to keep this change small.

Testing: tier1-5 (with JDK-8276548).

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

Commit messages:
 - Fix

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

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


From ayang at openjdk.java.net  Wed Nov  3 11:33:20 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 3 Nov 2021 11:33:20 GMT
Subject: RFR: 8276540: Howl Full CardSet container iteration marks too many
 cards
In-Reply-To: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
References: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
Message-ID: <oWFHsmU7twKJ6kboO4pA7Vg5d0gFLgFniLrqUWwnPGE=.490ae10d-0660-4071-afac-7d575f2f760a@github.com>

On Wed, 3 Nov 2021 10:49:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that fixes how many cards are being iterated over during Howl Full CardSet container iteration? There is no need to iterate over `max_cards_in_region()` cards, it is sufficient to iterate just over the area that this Howl partition represents, i.e. `num_cards_in_howl_bitmap()`.
> 
> I will change the way to iterate over this card set container within the howl container in JDK-8276548 to keep this change small.
> 
> Testing: tier1-5 (with JDK-8276548).

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Nov  3 12:11:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 12:11:12 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v18]
In-Reply-To: <AmifFFQAiAS8b5Go2vi0_wNI2qw7GmACek9CUaPgA-Q=.1beadb39-818d-49e8-8747-911280650133@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <AmifFFQAiAS8b5Go2vi0_wNI2qw7GmACek9CUaPgA-Q=.1beadb39-818d-49e8-8747-911280650133@github.com>
Message-ID: <L9EcZrrz59QiGZ7feb3muhupxdR7ZYXp3x8EdsWY5eQ=.1865852d-63d0-4ee4-8986-a98fb54ab444@github.com>

On Wed, 3 Nov 2021 01:09:34 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a try to optimize evcuation failure for regions.
>> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
>> 
>> I have tested it with following parameters, 
>> 
>> -   -XX:+ParallelGCThreads=1/32/64
>> -   -XX:G1EvacuationFailureALotInterval=1
>> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
>> 
>> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
>> 
>> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
>  - Refine code based on Thomas' suggestion
>  - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
>  - Fix compilation error
>  - Fix compilation error
>  - Refactor as Thomas suggested
>  - Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR
>  - Add asserts, comments
>  - Use refactored G1SegmentedArray rather than home-made Array+Node
>  - Fix wrong merge
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bb92fb02...d33f87b4

I think this is good now - great!

There is one minor comment for some refactoring that you may want to consider.

src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 114:

> 112:   void iterate(ObjectClosure* closure) {
> 113:     join_and_sort();
> 114:     iterate_internal(closure);

I would probably move the array allocation and freeing here instead of having this at the start and end of `join_and_sort` and `iterate_internal` respectively. Otherwise there is a hidden dependency on the first method allocating and the second freeing it, and looks cleaner as allocation and deallocation is obvious and on the same call level.

I.e.


  void iterate(ObjectClosure* closure) {
     uint num = _segments->num_allocated_nodes();
    _offset_array = NEW_C_HEAP_ARRAY(OffsetInRegion, num, mtGC);

    join_and_sort();
    iterate_internal(closure);

    FREE_C_HEAP_ARRAY(OffsetInRegion, _offset_array);
  }

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Nov  3 12:15:19 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 12:15:19 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size
In-Reply-To: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
Message-ID: <4m8xgQYGL6_iSgWX5PlbRM520-q2oF6KNqopFZcFP_4=.4e926cd5-31b5-4f42-b25e-07f6a010c3fa@github.com>

On Tue, 2 Nov 2021 01:28:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to PretouchTask to page-align the chunk size.
> Aligning down is used because it's easy; aligning up would require dealing
> with possible overflow or verifying that overflow isn't possible.
> 
> Testing:
> mach5 tier1
> 
> Locally (linux-x64) java -version with pretouch task logging and various
> chunk sizes, manually verifying the number of workers was as expected.

Lgtm independent of whether you want to incorporate @stefank 's suggestion.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Nov  3 12:21:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 12:21:08 GMT
Subject: RFR: 8276298: G1: Fix or remove G1SegmentedArrayBufferList::add
In-Reply-To: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>
References: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>
Message-ID: <23QKUnPtafk2KaTdqwLuUhSGem_9VHQ_E_eGyfL1gmM=.2d6959ec-d01c-4c45-a4b9-23100f100fb5@github.com>

On Wed, 3 Nov 2021 03:44:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is minor removal of unused method G1SegmentedArrayBufferList::add.

Lgtm, thanks, and trivial. Please adjust the title of this PR to the CR title I renamed this to (just "remove") and then you can immediately push (trivial removal rule).

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

Marked as reviewed by tschatzl (Reviewer).

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


From mli at openjdk.java.net  Wed Nov  3 12:39:46 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 12:39:46 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
Message-ID: <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>

> This is a try to optimize evcuation failure for regions.
> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
> 
> I have tested it with following parameters, 
> 
> -   -XX:+ParallelGCThreads=1/32/64
> -   -XX:G1EvacuationFailureALotInterval=1
> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
> 
> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
> 
> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Move allocation/deallocation in one place

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5181/files
  - new: https://git.openjdk.java.net/jdk/pull/5181/files/d33f87b4..e588cad2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=17-18

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

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


From mli at openjdk.java.net  Wed Nov  3 12:39:51 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 12:39:51 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v18]
In-Reply-To: <L9EcZrrz59QiGZ7feb3muhupxdR7ZYXp3x8EdsWY5eQ=.1865852d-63d0-4ee4-8986-a98fb54ab444@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <AmifFFQAiAS8b5Go2vi0_wNI2qw7GmACek9CUaPgA-Q=.1beadb39-818d-49e8-8747-911280650133@github.com>
 <L9EcZrrz59QiGZ7feb3muhupxdR7ZYXp3x8EdsWY5eQ=.1865852d-63d0-4ee4-8986-a98fb54ab444@github.com>
Message-ID: <6LhZa6dkj8nspiGxcLZ2DHyWfniPxpe5RoL0QPWmcUo=.52caad98-d499-4818-8e85-3c214a2ea83b@github.com>

On Wed, 3 Nov 2021 12:03:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
>> 
>>  - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
>>  - Refine code based on Thomas' suggestion
>>  - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region
>>  - Fix compilation error
>>  - Fix compilation error
>>  - Refactor as Thomas suggested
>>  - Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR
>>  - Add asserts, comments
>>  - Use refactored G1SegmentedArray rather than home-made Array+Node
>>  - Fix wrong merge
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/bb92fb02...d33f87b4
>
> src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 114:
> 
>> 112:   void iterate(ObjectClosure* closure) {
>> 113:     join_and_sort();
>> 114:     iterate_internal(closure);
> 
> I would probably move the array allocation and freeing here instead of having this at the start and end of `join_and_sort` and `iterate_internal` respectively. Otherwise there is a hidden dependency on the first method allocating and the second freeing it, and looks cleaner as allocation and deallocation is obvious and on the same call level.
> 
> I.e.
> 
> 
>   void iterate(ObjectClosure* closure) {
>      uint num = _segments->num_allocated_nodes();
>     _offset_array = NEW_C_HEAP_ARRAY(OffsetInRegion, num, mtGC);
> 
>     join_and_sort();
>     iterate_internal(closure);
> 
>     FREE_C_HEAP_ARRAY(OffsetInRegion, _offset_array);
>   }

Thanks Thomas, good catch.

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

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


From mli at openjdk.java.net  Wed Nov  3 12:42:11 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 12:42:11 GMT
Subject: RFR: 8276298: G1: Remove unused G1SegmentedArrayBufferList::add
In-Reply-To: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>
References: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>
Message-ID: <loIFV6Hihh9Ib0dxo3il1uvbk2CSSZtc2b6Pp9Zinsk=.67048297-19dd-4335-ac54-b270aedf1d01@github.com>

On Wed, 3 Nov 2021 03:44:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is minor removal of unused method G1SegmentedArrayBufferList::add.

Thanks Thomas for your review.

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

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


From mli at openjdk.java.net  Wed Nov  3 12:42:11 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 3 Nov 2021 12:42:11 GMT
Subject: Integrated: 8276298: G1: Remove unused G1SegmentedArrayBufferList::add
In-Reply-To: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>
References: <QmbHrFzr4ApvOITKTr4KndVPaGSUD-smy3YhOfRzrJc=.e058c464-aaa0-410c-b5b1-45775ce6fe04@github.com>
Message-ID: <m_wYzIXshPsx33Gdt2RlNjPtz9n9d-noVn042ZEMKGE=.dcd9de59-8b85-4a07-aaeb-c225ac8ccf86@github.com>

On Wed, 3 Nov 2021 03:44:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is minor removal of unused method G1SegmentedArrayBufferList::add.

This pull request has now been integrated.

Changeset: be1ca2bd
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be1ca2bd201170b0d280030a2aae4c8d1da9f4af
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8276298: G1: Remove unused G1SegmentedArrayBufferList::add

Reviewed-by: tschatzl

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

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


From tschatzl at openjdk.java.net  Wed Nov  3 12:47:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 12:47:20 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
Message-ID: <0SFxWP_0ZmxgqhGl1OFit4LRucaQDtbeEy79JDSKaWE=.cb870a07-984d-4c04-b793-b793d619631f@github.com>

On Wed, 3 Nov 2021 12:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a try to optimize evcuation failure for regions.
>> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
>> 
>> I have tested it with following parameters, 
>> 
>> -   -XX:+ParallelGCThreads=1/32/64
>> -   -XX:G1EvacuationFailureALotInterval=1
>> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
>> 
>> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
>> 
>> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move allocation/deallocation in one place

Still good.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Nov  3 13:15:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 13:15:10 GMT
Subject: RFR: 8276301: G1: Refine implementation of
 G1CardSetFreePool::memory_sizes()
In-Reply-To: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
References: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
Message-ID: <uvuA-vkNlCFvF4altFUUo1aT_DH0hGb8dIFjWUe3BcI=.9556c7d7-e1b4-4853-b811-dd8149d181f0@github.com>

On Wed, 3 Nov 2021 03:46:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Implementation of G1CardSetFreePool::memory_sizes() is not straight, this is to refine the implementation.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Nov  3 16:12:25 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 3 Nov 2021 16:12:25 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <sp6aTbeC9VGIgjBEsWYx5xtLxlXmWceVWkuMs6CEog8=.b8bc832d-8886-466b-ae2c-31adb42a6c17@github.com>

On Fri, 29 Oct 2021 08:23:30 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

This is a first cut of ideas to improve the change a bit - I really like it from a technical point of view. However it feels kind of patched in instead of some part of a whole.

Particularly one issue I would like to discuss in detail is that we now do bot updates at different levels (`G1PLABAllocator`, `G1AllocRegion`). The suggestion to move the BOT update for the waste into `G1PLAB::retire_internal` could fix that though. Could you look into this refactoring suggestion in more detail please?

Other comments may be outdated if/after this change.

src/hotspot/share/gc/g1/g1Allocator.hpp line 155:

> 153:   bool is_allocated();
> 154:   HeapWord* get_filler();
> 155:   size_t get_filler_size();

Maybe instead of two methods that return the remaining space, one that returns a `MemRegion` would be nicer? Also call it something like `remainder` or so.

What about making `PLAB::retire_internal` virtual and override here, so that the explicit call in `G1PLABAllocator::allocate_direct_or_new_plab` goes away? (and these two helpers, and probably also `is_allocated()`).

Also the explict call in `G1PLABAllocator::flush_and_retire_stats` could maybe be hidden too. You could store the `G1PLABAllocator` in `G1PLAB` so that it can call the `update_bot....` method in `retire_internal`.

src/hotspot/share/gc/g1/g1Allocator.hpp line 170:

> 168: 
> 169:   // Region where the current old generation PLAB is allocated. Used to do BOT updates.
> 170:   HeapRegion* _bot_plab_region;

I think it is a breakage of abstraction if we only store this information for old gen - we after all allocate the `G1PLAB` for all `G1HeapRegionAttr::num` destination areas.
What about putting all that stuff into `G1PLAB` and initializing it appropriately?

src/hotspot/share/gc/g1/g1Allocator.hpp line 173:

> 171:   // Current BOT threshold, a PLAB allocation crossing this threshold will cause a BOT
> 172:   // update.
> 173:   HeapWord* _bot_plab_threshold;

This is also only interesting for the old generation, isn't it? Same issue as above.

src/hotspot/share/gc/g1/g1Allocator.inline.hpp line 137:

> 135: 
> 136: inline void G1PLABAllocator::update_bot_for_plab_waste(G1HeapRegionAttr attr, G1PLAB* plab) {
> 137:   if (!attr.is_old()) {

I would prefer to make an extra predicate like `needs_bot_update()` for this instead of explictly replicating the code in a few places (and always adding the comment).

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 503:

> 501:     } else {
> 502:       assert(dest_attr.is_old(), "Only update bot for allocations in old");
> 503:       _plab_allocator->update_bot_for_object(obj_ptr, word_sz);

Maybe it would be good if the `PLABAllocator` returned a struct instead of just a pointer that contains
- the HeapWord
- word_sz
- whether it was a direct allocation
?

Then this struct could be passed in here again instead of the code for `update_bot_for_object` trying to reconstruct whether it has been an out-of-plab allocation or not.

Or just skip the `word_sz` in that struct. Alternatively add a return value whether this allocation has been out-of-plab. But this method already has lots of locals (is too long?), so starting to group them might be a good idea.

I think explicitly carrying this information around would be much much cleaner to understand than trying to reconstruct that information later in `update_bot_for_object? via


  if (!alloc_buffer(G1HeapRegionAttr::Old, 0)->contains(obj_start)) {
    // Out of PLAB allocation, BOT already updated.
    return;
  }

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

Changes requested by tschatzl (Reviewer).

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


From pliden at openjdk.java.net  Wed Nov  3 16:47:28 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 3 Nov 2021 16:47:28 GMT
Subject: RFR: 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1
 failed with "OutOfMemoryError: Java heap space"
Message-ID: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>

Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.

If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.

Testing:
 - Tier 1-7 with ZGC on Linux/x86_64.
 - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.

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

Commit messages:
 - 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space"

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

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


From eosterlund at openjdk.java.net  Wed Nov  3 19:07:08 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 3 Nov 2021 19:07:08 GMT
Subject: RFR: 8268779: ZGC:
 runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with
 "OutOfMemoryError: Java heap space"
In-Reply-To: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
References: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
Message-ID: <x1pN3V6Dmudcna0yU9NL2ldnqtvhwP9xS1hJPB0cBDc=.5bf38a45-d66b-45b9-81bc-238099ead789@github.com>

On Wed, 3 Nov 2021 16:39:51 GMT, Per Liden <pliden at openjdk.org> wrote:

> Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.
> 
> If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.
> 
> Testing:
>  - Tier 1-7 with ZGC on Linux/x86_64.
>  - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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


From mli at openjdk.java.net  Thu Nov  4 01:02:17 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Nov 2021 01:02:17 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
Message-ID: <P1UPWqDYD_1MdN-Kg7V3wo2fg-_NrasOtpdZ6rxAzLs=.8dd2ca8e-282c-4150-8ab2-a1d9a0318352@github.com>

On Wed, 3 Nov 2021 12:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a try to optimize evcuation failure for regions.
>> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
>> 
>> I have tested it with following parameters, 
>> 
>> -   -XX:+ParallelGCThreads=1/32/64
>> -   -XX:G1EvacuationFailureALotInterval=1
>> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
>> 
>> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
>> 
>> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move allocation/deallocation in one place

Is someone else available to have a look on this change? Thanks

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

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


From mli at openjdk.java.net  Thu Nov  4 01:03:18 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Nov 2021 01:03:18 GMT
Subject: RFR: 8276301: G1: Refine implementation of
 G1CardSetFreePool::memory_sizes()
In-Reply-To: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
References: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
Message-ID: <-aD1oPcdkeMrSNqNKF6oRntiFP9k8Y4hs4LZ96Y3s9A=.aae12c70-96d7-4217-85f5-70ebfec7934f@github.com>

On Wed, 3 Nov 2021 03:46:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Implementation of G1CardSetFreePool::memory_sizes() is not straight, this is to refine the implementation.

Is someone else available to have a look on this change? Thanks

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

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


From dholmes at openjdk.java.net  Thu Nov  4 06:19:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Nov 2021 06:19:09 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <HvHvpajrdVqkR5KkKf39n4o-XsWV72s6iedYDQu_NVg=.1a1b2778-e0de-4179-af5a-bdf12cead26b@github.com>

On Thu, 4 Nov 2021 05:09:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Thread::_rcu_counter is not padded by cacheline, it should be beneficail to do so.
> 
> The initial spebjbb test shows about 10.5% improvement of critical, and 0.7% improvement of max in specjbb2015, specjbb arguments:
>   GROUP_COUNT=4
>   TI_JVM_COUNT=1
>   JAVA_OPTS_BE="-server -XX:+UseG1GC -Xms32g -Xmx32g"
>   MODE_ARGS="-ikv"

Hi Hamlin,

This seems reasonable to me, however whenever we add padding to optimise the placement of one field, I always wonder if that same padding has de-optimised the placement of other fields? I think we need to see a broader run of benchmarks here and across more than just x86_64.

I will see if I can assist on the benchmark front.

Thanks,
David

src/hotspot/share/runtime/thread.hpp line 253:

> 251: 
> 252:   // Support for GlobalCounter
> 253:  private:

pre-existing nit: this private is not needed; nor is the public at line 260.

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

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


From mli at openjdk.java.net  Thu Nov  4 07:30:09 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Nov 2021 07:30:09 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <Sd7NmZNhMf-2k9Wk5zCsfAbeAnC41_g-UCAsRcrPJDM=.ff93b7b9-10d0-4976-8f1a-aac52266cc3c@github.com>

On Thu, 4 Nov 2021 05:09:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Thread::_rcu_counter is not padded by cacheline, it should be beneficail to do so.
> 
> The initial spebjbb test shows about 10.5% improvement of critical, and 0.7% improvement of max in specjbb2015, specjbb arguments:
>   GROUP_COUNT=4
>   TI_JVM_COUNT=1
>   JAVA_OPTS_BE="-server -XX:+UseG1GC -Xms32g -Xmx32g"
>   MODE_ARGS="-ikv"

Thanks a lot David, it will be very helpful.
BTW, I will modify as you suggested later together with other's comments.

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

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


From tschatzl at openjdk.java.net  Thu Nov  4 08:04:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 4 Nov 2021 08:04:10 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <q1dzITw2hj4IrHHw27tnX_i8b7K2RMMKv0ry8LcUQS0=.034351a8-a500-4753-9ea4-8ce38c81bb5b@github.com>

On Thu, 4 Nov 2021 05:09:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Thread::_rcu_counter is not padded by cacheline, it should be beneficail to do so.
> 
> The initial spebjbb test shows about 10.5% improvement of critical, and 0.7% improvement of max in specjbb2015, specjbb arguments:
>   GROUP_COUNT=4
>   TI_JVM_COUNT=1
>   JAVA_OPTS_BE="-server -XX:+UseG1GC -Xms32g -Xmx32g"
>   MODE_ARGS="-ikv"

I'll push it through our perf testing.

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

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


From mli at openjdk.java.net  Thu Nov  4 08:38:19 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Nov 2021 08:38:19 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <rijAs5XL51ssillS9ou1JY8NVYCHVeKNYwNiqIul7p0=.ecee3616-5647-4924-b86c-455519dce192@github.com>

On Thu, 4 Nov 2021 05:09:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Thread::_rcu_counter is not padded by cacheline, it should be beneficail to do so.
> 
> The initial spebjbb test shows about 10.5% improvement of critical, and 0.7% improvement of max in specjbb2015, specjbb arguments:
>   GROUP_COUNT=4
>   TI_JVM_COUNT=1
>   JAVA_OPTS_BE="-server -XX:+UseG1GC -Xms32g -Xmx32g"
>   MODE_ARGS="-ikv"

Thanks a lot Thomas. :)

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

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


From ihse at openjdk.java.net  Thu Nov  4 10:51:27 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 10:51:27 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
Message-ID: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>

I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

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

Commit messages:
 - 8276628: Use blessed modifier order in serviceability code

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

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


From ayang at openjdk.java.net  Thu Nov  4 11:05:10 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 4 Nov 2021 11:05:10 GMT
Subject: RFR: 8276301: G1: Refine implementation of
 G1CardSetFreePool::memory_sizes()
In-Reply-To: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
References: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
Message-ID: <FMpu3xy2xsH46WMNB2o9u8LVo2fQ7027QNRWLY4O3c8=.858ca8e9-3937-40ed-be5b-94b3bcbe7152@github.com>

On Wed, 3 Nov 2021 03:46:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Implementation of G1CardSetFreePool::memory_sizes() is not straight, this is to refine the implementation.

Nice cleanup.

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

Marked as reviewed by ayang (Reviewer).

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


From pliden at openjdk.java.net  Thu Nov  4 11:10:37 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 4 Nov 2021 11:10:37 GMT
Subject: RFR: 8268779: ZGC:
 runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with
 "OutOfMemoryError: Java heap space" [v2]
In-Reply-To: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
References: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
Message-ID: <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>

> Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.
> 
> If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.
> 
> Testing:
>  - Tier 1-7 with ZGC on Linux/x86_64.
>  - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.

Per Liden has updated the pull request incrementally with one additional commit since the last revision:

  Alternative

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6236/files
  - new: https://git.openjdk.java.net/jdk/pull/6236/files/29035be4..2ee45cb9

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

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

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


From eosterlund at openjdk.java.net  Thu Nov  4 11:10:38 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 4 Nov 2021 11:10:38 GMT
Subject: RFR: 8268779: ZGC:
 runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with
 "OutOfMemoryError: Java heap space" [v2]
In-Reply-To: <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>
References: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
 <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>
Message-ID: <BfFeXXBJQlhY5duvza8pcrwHckUnVw9ss6GvAZ6VqnM=.88063bab-ae09-473d-931c-f6e2bec34783@github.com>

On Thu, 4 Nov 2021 11:07:32 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.
>> 
>> If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.
>> 
>> Testing:
>>  - Tier 1-7 with ZGC on Linux/x86_64.
>>  - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alternative

Looks... even better.

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

Marked as reviewed by eosterlund (Reviewer).

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


From dholmes at openjdk.java.net  Thu Nov  4 12:23:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Nov 2021 12:23:23 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <U_K0loGNtPPxro0uV5tcd2s8TJvDoA2niwrl2wOp0RE=.6610b7a7-0d97-4172-b7be-35b2f5aba7c2@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Looks fine to me.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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


From mli at openjdk.java.net  Thu Nov  4 12:35:16 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Nov 2021 12:35:16 GMT
Subject: RFR: 8276301: G1: Refine implementation of
 G1CardSetFreePool::memory_sizes()
In-Reply-To: <uvuA-vkNlCFvF4altFUUo1aT_DH0hGb8dIFjWUe3BcI=.9556c7d7-e1b4-4853-b811-dd8149d181f0@github.com>
References: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
 <uvuA-vkNlCFvF4altFUUo1aT_DH0hGb8dIFjWUe3BcI=.9556c7d7-e1b4-4853-b811-dd8149d181f0@github.com>
Message-ID: <jlhqGs1sT6ZwuLKAMFezJxSLWAaCPRrZP7ZWBENtIWM=.ea0f903b-96c5-402e-8884-7646960fbfc2@github.com>

On Wed, 3 Nov 2021 13:12:23 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Implementation of G1CardSetFreePool::memory_sizes() is not straight, this is to refine the implementation.
>
> Lgtm.

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Thu Nov  4 12:35:17 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 4 Nov 2021 12:35:17 GMT
Subject: Integrated: 8276301: G1: Refine implementation of
 G1CardSetFreePool::memory_sizes()
In-Reply-To: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
References: <2QCvh1Rsie-nr-1SLFMxqkous9Ht8UcMBNEFR25S9sw=.4b509ce5-4868-4863-b2ae-c10cd726342b@github.com>
Message-ID: <DM3S3RrgQMgG3bjpvYOE4lBsnm8uAMx9TBT8MuW-JX8=.25aede11-d231-40a7-a8df-464a285f204d@github.com>

On Wed, 3 Nov 2021 03:46:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Implementation of G1CardSetFreePool::memory_sizes() is not straight, this is to refine the implementation.

This pull request has now been integrated.

Changeset: 7de653e4
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7de653e428ee38339ec38533659b23a52e275f3f
Stats:     30 lines in 2 files changed: 6 ins; 22 del; 2 mod

8276301: G1: Refine implementation of G1CardSetFreePool::memory_sizes()

Reviewed-by: tschatzl, ayang

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

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


From stefank at openjdk.java.net  Thu Nov  4 13:36:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 4 Nov 2021 13:36:10 GMT
Subject: RFR: 8268779: ZGC:
 runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with
 "OutOfMemoryError: Java heap space" [v2]
In-Reply-To: <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>
References: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
 <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>
Message-ID: <l4b9JzVx59Za55CAav2Y71nK1zMA_RdwiDCMtV6Uy7U=.dee4f0cf-93ce-4e45-b03f-d5ebcf47d5f3@github.com>

On Thu, 4 Nov 2021 11:10:37 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.
>> 
>> If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.
>> 
>> Testing:
>>  - Tier 1-7 with ZGC on Linux/x86_64.
>>  - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alternative

Marked as reviewed by stefank (Reviewer).

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

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


From pliden at openjdk.java.net  Thu Nov  4 13:51:17 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 4 Nov 2021 13:51:17 GMT
Subject: RFR: 8268779: ZGC:
 runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with
 "OutOfMemoryError: Java heap space" [v2]
In-Reply-To: <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>
References: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
 <8oIpgyy1xE1IxDxka-oRELgKVXCQPpXAAAsQEEwmd88=.829d03d4-7e3a-4ddb-9aee-926df978a212@github.com>
Message-ID: <EC3932FgEf68fW2rlok_9cNF1LbaO10gMceKoVHfXTE=.eb795c89-2919-4c06-b016-0e58573df193@github.com>

On Thu, 4 Nov 2021 11:10:37 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.
>> 
>> If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.
>> 
>> Testing:
>>  - Tier 1-7 with ZGC on Linux/x86_64.
>>  - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alternative

Thanks for reviewing!

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

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


From pliden at openjdk.java.net  Thu Nov  4 13:51:18 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 4 Nov 2021 13:51:18 GMT
Subject: Integrated: 8268779: ZGC:
 runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with
 "OutOfMemoryError: Java heap space"
In-Reply-To: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
References: <Ah9mlm7kIe3mx3l-344zXsChhc2rEpIG0Iu8EtbjZbE=.041fb7a4-7614-418a-aac0-23b61fc91baa@github.com>
Message-ID: <WTOXqma2CkuLMhY9EB_qxL6yuhST9VQqKO5V6tMi6mM=.317c6913-0bf5-4f67-97da-63455401193f@github.com>

On Wed, 3 Nov 2021 16:39:51 GMT, Per Liden <pliden at openjdk.org> wrote:

> Please review this fix for a ZGC shutdown/abort issue, introduced by JDK-8261759.
> 
> If a GC cycle has aborted, we should not notify that it completed and we should not check for out of memory condition. Doing so can cause pre-mature `OutOfMemoryError`.
> 
> Testing:
>  - Tier 1-7 with ZGC on Linux/x86_64.
>  - Wrote a small reproducer that provokes the problem fairly quickly. With this patch, I can no longer reproduced the issue.

This pull request has now been integrated.

Changeset: a6fa6ed1
Author:    Per Liden <pliden at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6fa6ed1edc6f473a7fea1fa00edd467ab778983
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space"

Reviewed-by: eosterlund, stefank

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

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


From lmesnik at openjdk.java.net  Thu Nov  4 14:26:10 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 4 Nov 2021 14:26:10 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <eUAIYw2CAhxBKXU3qG24cChmOkmFuZBtom-XT-XRXkA=.5ac70260-2594-4230-b6e1-103bb5c260b2@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Marked as reviewed by lmesnik (Reviewer).

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

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


From cjplummer at openjdk.java.net  Thu Nov  4 16:03:21 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Nov 2021 16:03:21 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Copyright updates?

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

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


From ihse at openjdk.java.net  Thu Nov  4 17:07:24 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:07:24 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <hmxwr3jQe794BxOkQUXi0LpT66GtoXocolr2OolRFUw=.e861733a-47ca-4b80-88ee-68ac506fc731@github.com>
Message-ID: <NX5Z8gVBGw82IJ7UtNOmZPwzD6D---Nj3uiBZQeEhqU=.8bbccacb-32bd-4bbb-9c66-a6ef20a32eda@github.com>

On Thu, 4 Nov 2021 15:59:48 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Copyright updates?

@plummercj That's really kind of an edge case, considering the triviality of these changes. But yes, the norm in the JDK is to update the copyright year for all changes, so you're right, I should do that.

(And we *really* ought to wrangle free some resources to write tooling for us to do all the copyright dances...)

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

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


From ihse at openjdk.java.net  Thu Nov  4 17:36:52 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Nov 2021 17:36:52 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6249/files
  - new: https://git.openjdk.java.net/jdk/pull/6249/files/cf5db105..8a5ff8a5

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

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

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


From cjplummer at openjdk.java.net  Thu Nov  4 18:08:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 4 Nov 2021 18:08:11 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <-iSUoILuWhTb2AgWH-HGAsEm4Nvo8Fl6NIVaiFTY3Lo=.5ec41a0d-e7f3-4f57-b651-7c1971f48e3c@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Marked as reviewed by cjplummer (Reviewer).

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

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


From dholmes at openjdk.java.net  Fri Nov  5 00:38:13 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 5 Nov 2021 00:38:13 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <7jntohY4FpQYK4L1W1l8wkvamKZhSTjXqtS0CEYIJ7k=.0e5e17bf-d6e5-41dc-8ffd-e30fb4803a29@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

Good catch on copyright updates @plummercj ! We always have to update when we modify a file - the one exception is changing the wording of the copyright notice itself.

Looks good.

David

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

Marked as reviewed by dholmes (Reviewer).

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


From kbarrett at openjdk.java.net  Fri Nov  5 00:53:33 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 5 Nov 2021 00:53:33 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size [v2]
In-Reply-To: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
Message-ID: <oWqW0p4yF8pwlzpjPHY3ndUKz-GtnaRF4zm9qtU3v3M=.1907fe65-50ea-4fd7-b658-dd5c7cf94688@github.com>

> Please review this change to PretouchTask to page-align the chunk size.
> Aligning down is used because it's easy; aligning up would require dealing
> with possible overflow or verifying that overflow isn't possible.
> 
> Testing:
> mach5 tier1
> 
> Locally (linux-x64) java -version with pretouch task logging and various
> chunk sizes, manually verifying the number of workers was as expected.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  use align_down_bounded

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6204/files
  - new: https://git.openjdk.java.net/jdk/pull/6204/files/ee12018b..ce8ad82b

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

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

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


From kbarrett at openjdk.java.net  Fri Nov  5 00:53:34 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 5 Nov 2021 00:53:34 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size [v2]
In-Reply-To: <G8npnt5Ih7wwgG-cLMIbykhmi7O2Kfd5cXdbR6MrGqY=.55353752-6c8d-4cb5-accd-9ebe4662f843@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
 <G8npnt5Ih7wwgG-cLMIbykhmi7O2Kfd5cXdbR6MrGqY=.55353752-6c8d-4cb5-accd-9ebe4662f843@github.com>
Message-ID: <GtRutNep12VHQtKD-dD6EI6721gqQOUyE8SSHw_hZM4=.f828d7bc-b3e8-4506-9152-cdb97c84fdc2@github.com>

On Tue, 2 Nov 2021 07:38:31 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use align_down_bounded
>
> src/hotspot/share/gc/shared/pretouchTask.cpp line 73:
> 
>> 71:   // Page-align the chunk size, so if start_address is also page-aligned (as
>> 72:   // is common) then there won't be any pages shared by multiple chunks.
>> 73:   chunk_size = align_down(chunk_size, page_size);
> 
> This looks like a place where align_down_bounded could be used. Something like this:
> 
> size_t chunk_size = align_down_bounded(PretouchTask::chunk_size(), page_size);

I either forgot about or never noticed that function.  Changed to use it.

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

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


From stefank at openjdk.java.net  Fri Nov  5 08:33:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 5 Nov 2021 08:33:14 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size [v2]
In-Reply-To: <oWqW0p4yF8pwlzpjPHY3ndUKz-GtnaRF4zm9qtU3v3M=.1907fe65-50ea-4fd7-b658-dd5c7cf94688@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
 <oWqW0p4yF8pwlzpjPHY3ndUKz-GtnaRF4zm9qtU3v3M=.1907fe65-50ea-4fd7-b658-dd5c7cf94688@github.com>
Message-ID: <yEwf4Tj8tm5CXqMFKcU_qQXf0XylLJNK4LozPsGhvkQ=.31d03fb1-58b9-444b-854d-d213bd916d70@github.com>

On Fri, 5 Nov 2021 00:53:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to PretouchTask to page-align the chunk size.
>> Aligning down is used because it's easy; aligning up would require dealing
>> with possible overflow or verifying that overflow isn't possible.
>> 
>> Testing:
>> mach5 tier1
>> 
>> Locally (linux-x64) java -version with pretouch task logging and various
>> chunk sizes, manually verifying the number of workers was as expected.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use align_down_bounded

Marked as reviewed by stefank (Reviewer).

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

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


From tschatzl at openjdk.java.net  Fri Nov  5 08:34:28 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 5 Nov 2021 08:34:28 GMT
Subject: RFR: 8276548: Use range based visitor for Howl-Full cards
Message-ID: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>

Hi all,

  can I have reviews for this change that improves the way G1 iterates over Howl-Full containers (i.e. "Full" cardsetptrs within a Howl cardset container)? Instead of calling the visitor method `do_card` to mark a single card for all cards in the range, just call the range-based visitor method `do_card_range`. This is also a little bit more efficient.

This change is a requirement for [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056).

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - Merge branch '8276540-howl-full-bitmap' into 8276548-range-based-visitor
 - Fix
 - Remove debug code
 - Fix length of entry

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

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


From ayang at openjdk.java.net  Fri Nov  5 09:43:15 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 5 Nov 2021 09:43:15 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
Message-ID: <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>

On Wed, 3 Nov 2021 12:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a try to optimize evcuation failure for regions.
>> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
>> 
>> I have tested it with following parameters, 
>> 
>> -   -XX:+ParallelGCThreads=1/32/64
>> -   -XX:G1EvacuationFailureALotInterval=1
>> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
>> 
>> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
>> 
>> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move allocation/deallocation in one place

Only some subjective and minor comments.

src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 131:

> 129: 
> 130:   _offsets.drop_all();
> 131: }

Having some destructive operations (`drop_all`) inside a method named `iterate` could come as a surprise, IMO. If I understand this correctly, the following would be problematic.


evac_failed_objects.iterate(closure1);
...
evac_failed_objects.iterate(closure2);

src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 264:

> 262: template <class Elem, MEMFLAGS flag>
> 263: template <typename BufferClosure>
> 264: void G1SegmentedArray<Elem, flag>::iterate_nodes(BufferClosure& cloure) const {

Typo: `cloure`.

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

Marked as reviewed by ayang (Reviewer).

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


From mli at openjdk.java.net  Fri Nov  5 10:23:11 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 10:23:11 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
Message-ID: <hYwuvFpCFffpwBL1X363DuYro4BHU1W9_eD2hhxydj4=.ddc43e4c-46e1-4662-b6b4-b3ae510d336d@github.com>

On Fri, 5 Nov 2021 09:31:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move allocation/deallocation in one place
>
> src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 264:
> 
>> 262: template <class Elem, MEMFLAGS flag>
>> 263: template <typename BufferClosure>
>> 264: void G1SegmentedArray<Elem, flag>::iterate_nodes(BufferClosure& cloure) const {
> 
> Typo: `cloure`.

good catch.

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

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


From mli at openjdk.java.net  Fri Nov  5 10:38:13 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 10:38:13 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
Message-ID: <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>

On Fri, 5 Nov 2021 09:39:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move allocation/deallocation in one place
>
> src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 131:
> 
>> 129: 
>> 130:   _offsets.drop_all();
>> 131: }
> 
> Having some destructive operations (`drop_all`) inside a method named `iterate` could come as a surprise, IMO. If I understand this correctly, the following would be problematic.
> 
> 
> evac_failed_objects.iterate(closure1);
> ...
> evac_failed_objects.iterate(closure2);

drop_all just returns buffers to free list, it will not destruct the buffers. So, iterate multiple times is OK, because next time it will get memory from free list or allocate a new buffer. Hope this answer your question.

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

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


From mli at openjdk.java.net  Fri Nov  5 10:59:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 10:59:41 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v20]
In-Reply-To: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
Message-ID: <0KYJiLE8ZAuK8Vu4aXr7gvoW1Pg0wuoQPxgf0cnViMg=.d939e6aa-79f6-4f80-ac4c-52bf282360f8@github.com>

> This is a try to optimize evcuation failure for regions.
> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
> 
> I have tested it with following parameters, 
> 
> -   -XX:+ParallelGCThreads=1/32/64
> -   -XX:G1EvacuationFailureALotInterval=1
> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
> 
> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
> 
> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5181/files
  - new: https://git.openjdk.java.net/jdk/pull/5181/files/e588cad2..3efa90b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=18-19

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

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


From ayang at openjdk.java.net  Fri Nov  5 10:59:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 5 Nov 2021 10:59:42 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
Message-ID: <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>

On Fri, 5 Nov 2021 10:34:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 131:
>> 
>>> 129: 
>>> 130:   _offsets.drop_all();
>>> 131: }
>> 
>> Having some destructive operations (`drop_all`) inside a method named `iterate` could come as a surprise, IMO. If I understand this correctly, the following would be problematic.
>> 
>> 
>> evac_failed_objects.iterate(closure1);
>> ...
>> evac_failed_objects.iterate(closure2);
>
> drop_all just returns buffers to free list, it will not destruct the buffers. So, iterate multiple times is OK, because next time it will get memory from free list or allocate a new buffer. Hope this answer your question.

Since `drop_all()` resets all counters (e.g. `_num_allocated_nodes`), the subsequent iteration will think the array is empty, won't it?

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

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


From mli at openjdk.java.net  Fri Nov  5 11:06:19 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 11:06:19 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
 <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
Message-ID: <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>

On Fri, 5 Nov 2021 10:54:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> drop_all just returns buffers to free list, it will not destruct the buffers. So, iterate multiple times is OK, because next time it will get memory from free list or allocate a new buffer. Hope this answer your question.
>
> Since `drop_all()` resets all counters (e.g. `_num_allocated_nodes`), the subsequent iteration will think the array is empty, won't it?

For example, we modify the code as below:

> void HeapRegion::iterate_evac_failure_objs(ObjectClosure* closure) {
>   _evac_failure_objs.iterate(closure);
>   _evac_failure_objs.iterate(closure);
> }

For the second time iteration, all thing will be empty, so iterate_nodes will be an empty operation, QuickSort::sort too,  and iterate_internal too. These empty operations will not do harm things.

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

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


From tschatzl at openjdk.java.net  Fri Nov  5 11:15:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 5 Nov 2021 11:15:20 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
 <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
 <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>
Message-ID: <dzPwW8DeqCBZhEkEIwKyX-IqY43pLY8Y9RLGttoNMIA=.6c41f017-ae2b-40f0-9f66-26ece7fbd202@github.com>

On Fri, 5 Nov 2021 11:02:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Since `drop_all()` resets all counters (e.g. `_num_allocated_nodes`), the subsequent iteration will think the array is empty, won't it?
>
> For example, we modify the code as below:
> 
>> void HeapRegion::iterate_evac_failure_objs(ObjectClosure* closure) {
>>   _evac_failure_objs.iterate(closure);
>>   _evac_failure_objs.iterate(closure);
>> }
> 
> For the second time iteration, all thing will be empty, so iterate_nodes will be an empty operation, QuickSort::sort too,  and iterate_internal too. These empty operations will not do harm things.

@Hamlin-Li : I think @albertnetymk concern is that typically an `iterate` method does not modify the list itself. That is surprising for readers. The documentation also does not indicate any of that. I do not think he believes this will cause a VM failure.

Maybe change `HeapRegion::iterate_evac_failure_objs` to call a (new) `drop()` method on `_evac_failure_objs`?

I think such a change would solve Albert's concerns.

An alternative could be renaming `iterate` to something else.

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

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


From ayang at openjdk.java.net  Fri Nov  5 11:21:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 5 Nov 2021 11:21:13 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <dzPwW8DeqCBZhEkEIwKyX-IqY43pLY8Y9RLGttoNMIA=.6c41f017-ae2b-40f0-9f66-26ece7fbd202@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
 <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
 <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>
 <dzPwW8DeqCBZhEkEIwKyX-IqY43pLY8Y9RLGttoNMIA=.6c41f017-ae2b-40f0-9f66-26ece7fbd202@github.com>
Message-ID: <8a9nTnnjZXEVg7aATVKONQgYkx6-Jfqrfh_0NnuWGWY=.52e35129-975c-4e66-a642-bc151ad08081@github.com>

On Fri, 5 Nov 2021 11:12:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> For example, we modify the code as below:
>> 
>>> void HeapRegion::iterate_evac_failure_objs(ObjectClosure* closure) {
>>>   _evac_failure_objs.iterate(closure);
>>>   _evac_failure_objs.iterate(closure);
>>> }
>> 
>> For the second time iteration, all thing will be empty, so iterate_nodes will be an empty operation, QuickSort::sort too,  and iterate_internal too. These empty operations will not do harm things.
>
> @Hamlin-Li : I think @albertnetymk concern is that typically an `iterate` method does not modify the list itself. That is surprising for readers. The documentation also does not indicate any of that. I do not think he believes this will cause a VM failure.
> 
> Maybe change `HeapRegion::iterate_evac_failure_objs` to call a (new) `drop()` method on `_evac_failure_objs`?
> 
> I think such a change would solve Albert's concerns.
> 
> An alternative could be renaming `iterate` to something else.

Thank Thomas for unpacking my concern more precisely. I used "problematic" to mean the second iteration will not do what developers expect it to do, not necessarily a VM crash.

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

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


From mli at openjdk.java.net  Fri Nov  5 11:27:11 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 11:27:11 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <8a9nTnnjZXEVg7aATVKONQgYkx6-Jfqrfh_0NnuWGWY=.52e35129-975c-4e66-a642-bc151ad08081@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
 <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
 <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>
 <dzPwW8DeqCBZhEkEIwKyX-IqY43pLY8Y9RLGttoNMIA=.6c41f017-ae2b-40f0-9f66-26ece7fbd202@github.com>
 <8a9nTnnjZXEVg7aATVKONQgYkx6-Jfqrfh_0NnuWGWY=.52e35129-975c-4e66-a642-bc151ad08081@github.com>
Message-ID: <m1FS-SxSmaeHpgDu5ybroZK-wHSicvy6HbMUv42KXt0=.0abc5991-9e38-4aaf-a490-95ae2a503948@github.com>

On Fri, 5 Nov 2021 11:18:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @Hamlin-Li : I think @albertnetymk concern is that typically an `iterate` method does not modify the list itself. That is surprising for readers. The documentation also does not indicate any of that. I do not think he believes this will cause a VM failure.
>> 
>> Maybe change `HeapRegion::iterate_evac_failure_objs` to call a (new) `drop()` method on `_evac_failure_objs`?
>> 
>> I think such a change would solve Albert's concerns.
>> 
>> An alternative could be renaming `iterate` to something else.
>
> Thank Thomas for unpacking my concern more precisely. I used "problematic" to mean the second iteration will not do what developers expect it to do, not necessarily a VM crash.

Thanks for your clarification, Albert, Thomas, I see your point, it make sense to me.

As this patch has been blocking some other issues for a while, and I think it's better to think of some good solution for Albert's concern (seems add a drop is a little bit redundant for me :).) 

If you don't mind, can I do this refinement later in another issue? Thanks

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

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


From ayang at openjdk.java.net  Fri Nov  5 11:34:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 5 Nov 2021 11:34:13 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <m1FS-SxSmaeHpgDu5ybroZK-wHSicvy6HbMUv42KXt0=.0abc5991-9e38-4aaf-a490-95ae2a503948@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
 <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
 <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>
 <dzPwW8DeqCBZhEkEIwKyX-IqY43pLY8Y9RLGttoNMIA=.6c41f017-ae2b-40f0-9f66-26ece7fbd202@github.com>
 <8a9nTnnjZXEVg7aATVKONQgYkx6-Jfqrfh_0NnuWGWY=.52e35129-975c-4e66-a642-bc151ad08081@github.com>
 <m1FS-SxSmaeHpgDu5ybroZK-wHSicvy6HbMUv42KXt0=.0abc5991-9e38-4aaf-a490-95ae2a503948@github.com>
Message-ID: <fmxgVlcrhPgxvzryZ3hU8wwTQIYJn5CgEI2THmS3pr8=.b447ad5b-567c-4dbc-b84b-2ceecb7336f8@github.com>

On Fri, 5 Nov 2021 11:24:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Thank Thomas for unpacking my concern more precisely. I used "problematic" to mean the second iteration will not do what developers expect it to do, not necessarily a VM crash.
>
> Thanks for your clarification, Albert, Thomas, I see your point, it make sense to me.
> 
> As this patch has been blocking some other issues for a while, and I think it's better to think of some good solution for Albert's concern (seems add a drop is a little bit redundant for me :).) 
> 
> If you don't mind, can I do this refinement later in another issue? Thanks

It's a rather minor issue as I stated originally; I am fine either way.

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

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


From mli at openjdk.java.net  Fri Nov  5 11:47:14 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 11:47:14 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v19]
In-Reply-To: <fmxgVlcrhPgxvzryZ3hU8wwTQIYJn5CgEI2THmS3pr8=.b447ad5b-567c-4dbc-b84b-2ceecb7336f8@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <dVJ1d8Gh3juNpsHevjGhn2yvXdPjfiiQIG1CsHivglI=.e134c77a-15f6-4f3e-ad62-45e6cd43045d@github.com>
 <PinEMsjAjNXmZlF7-0ob1Ew7rGbh5FYJ3gXNSMEfI5M=.0895c99e-911d-4c55-bbdc-ada7e63064dc@github.com>
 <_k3J515iK0ZBsaVqs312Bl7oDPZd8thKB70pvoiXURU=.dbbf2139-085e-4000-b43e-0fc53072258e@github.com>
 <jlHtGk9Per8aN0OvRXpmQ9dRo6c3ldqhhA6RDXX3FPU=.b9060e69-90a2-4577-816d-642cce66f941@github.com>
 <82c8XPwqxlnN-3wL9OW4U1s8fuT_iraSyNlXzAUt1Ug=.6dbad985-0337-45f5-8bde-9f896f270bdf@github.com>
 <dzPwW8DeqCBZhEkEIwKyX-IqY43pLY8Y9RLGttoNMIA=.6c41f017-ae2b-40f0-9f66-26ece7fbd202@github.com>
 <8a9nTnnjZXEVg7aATVKONQgYkx6-Jfqrfh_0NnuWGWY=.52e35129-975c-4e66-a642-bc151ad08081@github.com>
 <m1FS-SxSmaeHpgDu5ybroZK-wHSicvy6HbMUv42KXt0=.0abc5991-9e38-4aaf-a490-95ae2a503948@github.com>
 <fmxgVlcrhPgxvzryZ3hU8wwTQIYJn5CgEI2THmS3pr8=.b447ad5b-567c-4dbc-b84b-2ceecb7336f8@github.com>
Message-ID: <JiwiZ1VRwoa3d6E-iRw80fW9K_sU_39tWjlOcvOlN20=.0e613de4-c9e3-4ada-a15e-504238b2e5e9@github.com>

On Fri, 5 Nov 2021 11:30:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thanks for your clarification, Albert, Thomas, I see your point, it make sense to me.
>> 
>> As this patch has been blocking some other issues for a while, and I think it's better to think of some good solution for Albert's concern (seems add a drop is a little bit redundant for me :).) 
>> 
>> If you don't mind, can I do this refinement later in another issue? Thanks
>
> It's a rather minor issue as I stated originally; I am fine either way.

Thanks, I created JDK-8276721 to track it.

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

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


From ihse at openjdk.java.net  Fri Nov  5 12:11:18 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 5 Nov 2021 12:11:18 GMT
Subject: Integrated: 8276628: Use blessed modifier order in serviceability code
In-Reply-To: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
Message-ID: <2SDPO7MFjKGYKDVlnVRdStd7XwlgsX3XA9PMfIGph5g=.8efd0769-4b5b-4014-b4ea-b6043f45b97f@github.com>

On Thu, 4 Nov 2021 10:44:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.

This pull request has now been integrated.

Changeset: 7023b3f8
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b
Stats:     284 lines in 89 files changed: 0 ins; 0 del; 284 mod

8276628: Use blessed modifier order in serviceability code

Reviewed-by: dholmes, lmesnik, cjplummer

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

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


From ayang at openjdk.java.net  Fri Nov  5 13:50:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 5 Nov 2021 13:50:14 GMT
Subject: RFR: 8276548: Use range based visitor for Howl-Full cards
In-Reply-To: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
References: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
Message-ID: <qjRLdnFID75a4mCMGlV4Xy5_BQeCNwWkhz7fJOkAtHo=.ae07766f-5c0c-4cb0-8444-8fdf24a53f3b@github.com>

On Wed, 3 Nov 2021 11:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that improves the way G1 iterates over Howl-Full containers (i.e. "Full" cardsetptrs within a Howl cardset container)? Instead of calling the visitor method `do_card` to mark a single card for all cards in the range, just call the range-based visitor method `do_card_range`. This is also a little bit more efficient.
> 
> This change is a requirement for [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056).
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Fri Nov  5 14:37:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 5 Nov 2021 14:37:48 GMT
Subject: RFR: 8276548: Use range based visitor for Howl-Full cards [v2]
In-Reply-To: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
References: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
Message-ID: <qzGGfLGbAs5IXG8evbqPNCoJ_AT4iPILWMVe1Auwrso=.1dcf87c2-f8e2-4de1-8484-1cf8738d2caa@github.com>

> Hi all,
> 
>   can I have reviews for this change that improves the way G1 iterates over Howl-Full containers (i.e. "Full" cardsetptrs within a Howl cardset container)? Instead of calling the visitor method `do_card` to mark a single card for all cards in the range, just call the range-based visitor method `do_card_range`. This is also a little bit more efficient.
> 
> This change is a requirement for [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056).
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Improve chunk marking

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6230/files
  - new: https://git.openjdk.java.net/jdk/pull/6230/files/a51ec682..f78e74b6

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

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

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


From kbarrett at openjdk.java.net  Fri Nov  5 21:18:18 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 5 Nov 2021 21:18:18 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size [v3]
In-Reply-To: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
Message-ID: <vVCh5uo8UHzQvv2ob_xCKphTcF3EkqpVJte1bzoCltg=.d7e0267e-0608-4a8f-bb45-49ef71086129@github.com>

> Please review this change to PretouchTask to page-align the chunk size.
> Aligning down is used because it's easy; aligning up would require dealing
> with possible overflow or verifying that overflow isn't possible.
> 
> Testing:
> mach5 tier1
> 
> Locally (linux-x64) java -version with pretouch task logging and various
> chunk sizes, manually verifying the number of workers was as expected.

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

 - Merge branch 'master' into align_pretouch_chunk_size
 - use align_down_bounded
 - page-align chunk size

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6204/files
  - new: https://git.openjdk.java.net/jdk/pull/6204/files/ce8ad82b..d1b3048c

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

  Stats: 396716 lines in 494 files changed: 195083 ins; 193711 del; 7922 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6204/head:pull/6204

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


From kbarrett at openjdk.java.net  Fri Nov  5 21:24:44 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 5 Nov 2021 21:24:44 GMT
Subject: RFR: 8276129: PretouchTask should page-align the chunk size [v2]
In-Reply-To: <yEwf4Tj8tm5CXqMFKcU_qQXf0XylLJNK4LozPsGhvkQ=.31d03fb1-58b9-444b-854d-d213bd916d70@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
 <oWqW0p4yF8pwlzpjPHY3ndUKz-GtnaRF4zm9qtU3v3M=.1907fe65-50ea-4fd7-b658-dd5c7cf94688@github.com>
 <yEwf4Tj8tm5CXqMFKcU_qQXf0XylLJNK4LozPsGhvkQ=.31d03fb1-58b9-444b-854d-d213bd916d70@github.com>
Message-ID: <c6nHccya8CfqkZ6mXYMApfBq-haLneZehTpd_U5AhQI=.80f587af-680d-4ec8-8b83-92f2a2dd0b5f@github.com>

On Fri, 5 Nov 2021 08:30:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use align_down_bounded
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank and @tschatzl for reviews.

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

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


From kbarrett at openjdk.java.net  Fri Nov  5 21:24:45 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 5 Nov 2021 21:24:45 GMT
Subject: Integrated: 8276129: PretouchTask should page-align the chunk size
In-Reply-To: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
References: <D4XWPfBVHsAQK5bWKlJDqlAsdpHmbRKBamMkaGIYRjU=.a9f95536-5bc2-45b7-acdd-d0a5f5c6662c@github.com>
Message-ID: <-Uj5bc4VOA_k5bXPq_PntnwPQ-gdQ6gdm07o0WpHzLw=.62f1d766-f902-4b5c-b6ad-ecdfef13ffdd@github.com>

On Tue, 2 Nov 2021 01:28:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to PretouchTask to page-align the chunk size.
> Aligning down is used because it's easy; aligning up would require dealing
> with possible overflow or verifying that overflow isn't possible.
> 
> Testing:
> mach5 tier1
> 
> Locally (linux-x64) java -version with pretouch task logging and various
> chunk sizes, manually verifying the number of workers was as expected.

This pull request has now been integrated.

Changeset: 0e0dd33f
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e0dd33fff9922a086968cfa6ccd27727f979c83
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8276129: PretouchTask should page-align the chunk size

Reviewed-by: stefank, tschatzl

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

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


From mli at openjdk.java.net  Fri Nov  5 23:28:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 23:28:44 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v20]
In-Reply-To: <0KYJiLE8ZAuK8Vu4aXr7gvoW1Pg0wuoQPxgf0cnViMg=.d939e6aa-79f6-4f80-ac4c-52bf282360f8@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <0KYJiLE8ZAuK8Vu4aXr7gvoW1Pg0wuoQPxgf0cnViMg=.d939e6aa-79f6-4f80-ac4c-52bf282360f8@github.com>
Message-ID: <W9JUdg593NqQOxBNj0USziiT0LbwB38-QJXaM6r-xyk=.786197e7-feed-4054-baf7-0da4181e383e@github.com>

On Fri, 5 Nov 2021 10:59:41 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a try to optimize evcuation failure for regions.
>> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
>> 
>> I have tested it with following parameters, 
>> 
>> -   -XX:+ParallelGCThreads=1/32/64
>> -   -XX:G1EvacuationFailureALotInterval=1
>> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
>> 
>> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
>> 
>> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

I think the windows build failure is not related to this change, will push it.

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

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


From mli at openjdk.java.net  Fri Nov  5 23:28:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 23:28:44 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few
 failed objects [v7]
In-Reply-To: <RaSkKR9yZYtLJoW_AArG8LEOAsD3rIc3YcEgsFex5d8=.b320091f-835d-4b37-b872-1507ba95f70a@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
 <YOB-Mulmp43htos_qIbvhLr8OhA-ax_SCF-dRhh3BFw=.3e05bca1-fbb5-4f12-9943-4f2b51ef4a2f@github.com>
 <RaSkKR9yZYtLJoW_AArG8LEOAsD3rIc3YcEgsFex5d8=.b320091f-835d-4b37-b872-1507ba95f70a@github.com>
Message-ID: <lPcRCoIJmsrlsa1Afiq9Eylu3pLO22UbdVH7NJ9Jxeg=.b649343b-55c3-4dfa-927b-cdcdfb39b1f0@github.com>

On Fri, 29 Oct 2021 10:11:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Performance is good as is, particularly the Remove self-forwards phase is much much faster now. I added a figure to the CR [here](https://bugs.openjdk.java.net/secure/attachment/96321/20210902-remove-self-forwards-improvement.png). Really nice.
>> 
>> Although there are a few existing abnormalities with this change (not newly introduced, the old code is as bad), see [JDK-8273309](https://bugs.openjdk.java.net/browse/JDK-8273309).
>> 
>> There are a few things that need to be improved:
>> * we talked about this before, but I do not think putting `G1EvacuationFailureObjsInHR`, which is something only used in evacuation failure, into `HeapRegion`, should be done. At least at the moment, it is almost never used.
>> * I do not like the use and the implementation of `G1EvacuationFailureObjsInHR`: it recreates something thatt is done better elsewhere (mark stack, DCQS buffer allocator, and in particular in the remembered set cardset allocator) with less features, in a non-fitting style.
>> Examples are something like reuse of available chunks, concurrent freeing of chunks, automatic resizing of blocks on demand to decrease allocations and potentially other stuff seems something we would really really want.
>> * as far as I understand the implementation of `G1EvacuationFailureObjsInHR` ;) - there is zero documentation about the basic structure - it seems to allocate quite a lot of memory that is almost never used. Even in the case of evacuation failure it's likely to be almost empty.
>> `G1EvacuationFailureObjsInHR` seems to basically be a preallocated `ArrayList` of chunks (the `_array_list` member).
>> Afaict it uses like 1/256 of total heap size (i.e. 0.3%), that's way way too much ( 1 / (256 * sizeof(HeapWord)) * sizeof(pointer); in `G1EvacuationFailureObjsInHR.cpp:86`; the `Array` constructor in `G1EvacuationFailureObjsInHR.hpp:124)) ). We will also get into trouble about startup time about this, I'm sure. That, tbh, alone makes it a no-go if I did not miscalculate.
>> 
>> Let's work on renaming and reusing the infrastructure provided by the remembered set (`G1CardSetAllocator` etc) in `g1CardSetMemory.hpp`.
>
>> @tschatzl Hi Thomas, is there any way I can reproduce this compilation error (drop_all reference) on my local? I use "bash configure; make images CONF=rel", there is no error on linux x86_64.
> 
> Probably try to compile with `--disable-precompiled-headers` (i.e. add to `configure` options). I had this issue yesterday too, but it went away after some changes (and I've been running our CI successfully with my changes).
> 
> Dug into that a bit deeper - can you try
> https://github.com/tschatzl/jdk/commit/bc79db0cd8c4eff8b0273e50046b212d201467c0 ?
> 
> The `g1SegmentedArray.inline.hpp` was not included in `heapregion.inline.hpp`, and that test was missing tons of includes anyway. Also we should clean up the `.hpp` files to not use methods from `.inline.hpp` - if so, they need to be moved to the `.inline.hpp` file too.

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Fri Nov  5 23:28:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 5 Nov 2021 23:28:47 GMT
Subject: Integrated: 8254739: G1: Optimize evacuation failure for regions with
 few failed objects
In-Reply-To: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
Message-ID: <RJ9tOg-vOniL1mRL-J3BluEewsPFvIginP9oKObu3HM=.7208f363-1027-4831-8d01-75d23ab37d20@github.com>

On Thu, 19 Aug 2021 08:11:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a try to optimize evcuation failure for regions.
> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure.
> 
> I have tested it with following parameters, 
> 
> -   -XX:+ParallelGCThreads=1/32/64
> -   -XX:G1EvacuationFailureALotInterval=1
> -   -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000
> 
> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. 
> 
> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure.

This pull request has now been integrated.

Changeset: ed7ecca4
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed7ecca401e5f4c3c07dc98e05a21396c6cdf594
Stats:     349 lines in 12 files changed: 311 ins; 5 del; 33 mod

8254739: G1: Optimize evacuation failure for regions with few failed objects

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Mon Nov  8 02:18:04 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Nov 2021 02:18:04 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes
Message-ID: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>

This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
Rename from G1CardSetXxx -> G1BufferListXxx.

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

Commit messages:
 - Fix typos
 - Fix gtest tests
 - Fix missing in test
 - Fix missing files
 - move g1CardSetFreeMemoryTask.*
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6289&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276670
  Stats: 1228 lines in 20 files changed: 641 ins; 554 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6289/head:pull/6289

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


From mli at openjdk.java.net  Mon Nov  8 02:21:48 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Nov 2021 02:21:48 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v2]
In-Reply-To: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
Message-ID: <DxIbFf45OzwEiZafQLOaZ6rWvcxl7EJfaI3aBd26Tds=.d9a04c74-4b80-41da-b9fa-4266b0ddd5fa@github.com>

> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
> Rename from G1CardSetXxx -> G1BufferListXxx.

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

 - Merge branch 'master' into rename-move-G1CardSetFreePool-out
 - Fix typos
 - Fix gtest tests
 - Fix missing in test
 - Fix missing files
 - move g1CardSetFreeMemoryTask.*
 - Initial commit

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

Changes: https://git.openjdk.java.net/jdk/pull/6289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6289&range=01
  Stats: 1228 lines in 20 files changed: 641 ins; 555 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6289/head:pull/6289

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


From mli at openjdk.java.net  Mon Nov  8 03:12:12 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Nov 2021 03:12:12 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
Message-ID: <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>

> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
> Rename from G1CardSetXxx -> G1BufferListXxx.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6289/files
  - new: https://git.openjdk.java.net/jdk/pull/6289/files/02c2b940..c15129e4

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

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

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


From asarkar at openjdk.java.net  Mon Nov  8 04:20:39 2021
From: asarkar at openjdk.java.net (Anirvan Sarkar)
Date: Mon, 8 Nov 2021 04:20:39 GMT
Subject: RFR: 8276628: Use blessed modifier order in serviceability code
 [v2]
In-Reply-To: <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
References: <J7lTd2Az2EyTgvxqsHoxm_Dy5xfrbCSY-JHuQ0RNwtI=.9b33f2ee-d1b4-4be9-99fb-97f755b500a5@github.com>
 <isoxE5rqQr7FOs4jVAbwGKXSv27in2YZnWNuu3mM6Ko=.7be91348-f31d-4f2a-9d30-3c5c7803bd76@github.com>
Message-ID: <c_E3qAG1nXTRWsQtbzJRtlEfQ7QBdawM4TWIzwaR1Mo=.5d37fd57-cf4f-4193-8ecb-8be0b169b989@github.com>

On Thu, 4 Nov 2021 17:36:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I ran bin/blessed-modifier-order.sh on source owned by serviceability. This scripts verifies that modifiers are in the "blessed" order, and fixes it otherwise. I have manually checked the changes made by the script to make sure they are sound.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also update copyright year

> (And we _really_ ought to wrangle free some resources to write tooling for us to do all the copyright dances...)

OpenJFX team seems to have a copyright update script[1].
Maybe @kevinrushforth can tell if it can be retrofitted and used by OpenJDK project.

[1] : https://bugs.openjdk.java.net/browse/JDK-8214793?focusedCommentId=14233661&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14233661

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

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


From mli at openjdk.java.net  Mon Nov  8 08:04:33 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Nov 2021 08:04:33 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
Message-ID: <P0TJimNQImCaJq6o7lFrqYjJzt6tS6LzeEgrd2pRb7U=.80772647-1592-4ed2-aff4-bae6a4923586@github.com>

On Mon, 8 Nov 2021 03:12:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Seems windows x64 build failure is not related to this change.

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 09:51:36 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 09:51:36 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <KIMR7OXS5ynzzBmyIPXIgB2nBx7FNvgVk7Rug2DMOBQ=.a831d649-f2fa-442f-83f9-879ee0a4dc81@github.com>

On Thu, 4 Nov 2021 05:09:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Thread::_rcu_counter is not padded by cacheline, it should be beneficail to do so.
> 
> The initial spebjbb test shows about 10.5% improvement of critical, and 0.7% improvement of max in specjbb2015, specjbb arguments:
>   GROUP_COUNT=4
>   TI_JVM_COUNT=1
>   JAVA_OPTS_BE="-server -XX:+UseG1GC -Xms32g -Xmx32g"
>   MODE_ARGS="-ikv"

Hi,

  we tried to reproduce your numbers internally, but failed to do so. Differences seem to be within noise.
  
  We tried with specjbb2015 multi-jvm on a fairly large machine (152 threads; it was what has been "on hand") and multiple runs of our internal benchmarks and specjbb2015 composite runs on various (not-so-large but still fairly big sized machines).

Could you post or send more details about your configuration?

The other concern that has been brought up internally has been that this increases the size of Thread by ~40% from 624 to 872 bytes; do you think there a way to save some memory by reorganizing the fields so that the counter is on a separate cache line "naturally"?

Thanks,
  Thomas

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

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


From mli at openjdk.java.net  Mon Nov  8 12:36:36 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Nov 2021 12:36:36 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <89OJo1V3vrvkTQ-dU-97B54AVaFV7eBlBe_vp6oXRmU=.f3918f6a-290c-4c85-b25b-3eef082a82fc@github.com>

On Thu, 4 Nov 2021 05:09:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Thread::_rcu_counter is not padded by cacheline, it should be beneficail to do so.
> 
> The initial spebjbb test shows about 10.5% improvement of critical, and 0.7% improvement of max in specjbb2015.
> 
> 
> 
> ========= test result (1st round) ==========
> rcu		base
> 45096		38980
> 41741		41468
> 42349		41053
> 44485		42030
> 47103		39915
> 43864		36004
> 
> ==== average ====
> 44106.33333		39908.33333
> 
> ==== improvement ====
> 10.5%
> 
> ========= test result (2nd round) ==========
> Second round of run includes 3 types: 
> 1. pad gc data & pad rcu
> 2. pad rcu only
> 3. base
> 
> Although the improvement is not that much as the previous round (10%), but still got about 3~4% improvement.
> 
> gc data + rcu	rcu	base
> 41284	41860	37099
> 42296	42166	44692
> 42810	43423	41801
> 43492	45603	40274
> 43808	40641	39627
> 43029	40242	39793
> 42543	41662	41544
> 43420	42702	37991
> 44212	43354	40319
> 42692	43442	45264
> 44773	44577	44213
> 40835	41870	42008
> 44282	44167	42527
> 
> ==== average ====
> 43036.61538	42746.84615	41319.38462
> 
> ==== improvement ====
> gc data + rcu / base: 4.156%
> rcu / base: 3.45%
> 
> 
> 
> 
> ========= configuration and environment ==========
> specjbb arguments:
>   GROUP_COUNT=4
>   TI_JVM_COUNT=1
> 
>   SPEC_OPTS_C="-Dspecjbb.group.count=$GROUP_COUNT -Dspecjbb.txi.pergroup.count=$TI_JVM_COUNT"
>   SPEC_OPTS_TI=""
>   SPEC_OPTS_BE=""
> 
>   JAVA_OPTS_C="-server -Xms2g -Xmx2g -XX:+UseParallelGC"
>   JAVA_OPTS_TI="-server -Xms2g -Xmx2g -XX:+UseParallelGC"
>   JAVA_OPTS_BE="-server -XX:+UseG1GC -Xms32g -Xmx32g"
> 
>   MODE_ARGS_C="-ikv"
>   MODE_ARGS_TI="-ikv"
>   MODE_ARGS_BE="-ikv"
> 
>   NUM_OF_RUNS=1
> 
> HW:
>   Architecture:        x86_64
>   CPU op-mode(s):      32-bit, 64-bit
>   Byte Order:          Little Endian
>   CPU(s):              224
>   On-line CPU(s) list: 0-223
>   Thread(s) per core:  2
>   Core(s) per socket:  28
>   Socket(s):           4
>   NUMA node(s):        4
>   Vendor ID:           GenuineIntel
>   CPU family:          6
>   Model:               85
>   Model name:          Intel(R) Xeon(R) Platinum 8176M CPU @ 2.10GHz
>   Stepping:            4
>   CPU MHz:             1001.925
>   CPU max MHz:         2101.0000
>   CPU min MHz:         1000.0000
>   BogoMIPS:            4200.00
>   Virtualization:      VT-x
>   L1d cache:           32K
>   L1i cache:           32K
>   L2 cache:            1024K
>   L3 cache:            39424K
>   NUMA node0 CPU(s):   0-27,112-139
>   NUMA node1 CPU(s):   28-55,140-167
>   NUMA node2 CPU(s):   56-83,168-195
>   NUMA node3 CPU(s):   84-111,196-223
> 
>               total        used        free      shared  buff/cache   available
> Mem:           3.0T        3.8G        2.9T         18M         25G        2.9T
> Swap:           99G          0B         99G

Thanks Thomas for the feedback.

I have updated the summary of this PR with more configuration and environment info, and I also updated the 2nd round of run. Although the improvement is not that much as the previous round (10%), but still got about 3~4% improvement, and seems the data is more stable than the 1st round of run.
(JBS is not available currently, will update JBS too later)

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

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


From mli at openjdk.java.net  Mon Nov  8 12:41:34 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 8 Nov 2021 12:41:34 GMT
Subject: RFR: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <KIMR7OXS5ynzzBmyIPXIgB2nBx7FNvgVk7Rug2DMOBQ=.a831d649-f2fa-442f-83f9-879ee0a4dc81@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
 <KIMR7OXS5ynzzBmyIPXIgB2nBx7FNvgVk7Rug2DMOBQ=.a831d649-f2fa-442f-83f9-879ee0a4dc81@github.com>
Message-ID: <DOcHtmUiWEiVVFK9wZxb38Qd8Cx0Qz-tqtI4lqmhk4A=.dc24908d-3388-4a5f-add4-88e778663dfc@github.com>

On Mon, 8 Nov 2021 09:48:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The other concern that has been brought up internally has been that this increases the size of Thread by ~40% from 624 to 872 bytes; do you think there a way to save some memory by reorganizing the fields so that the counter is on a separate cache line "naturally"?

Sure, if current change is proven to bring some performance benefit, let me do some more research in this direction.

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

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


From sjohanss at openjdk.java.net  Mon Nov  8 12:47:37 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 8 Nov 2021 12:47:37 GMT
Subject: RFR: 8276548: Use range based visitor for Howl-Full cards [v2]
In-Reply-To: <qzGGfLGbAs5IXG8evbqPNCoJ_AT4iPILWMVe1Auwrso=.1dcf87c2-f8e2-4de1-8484-1cf8738d2caa@github.com>
References: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
 <qzGGfLGbAs5IXG8evbqPNCoJ_AT4iPILWMVe1Auwrso=.1dcf87c2-f8e2-4de1-8484-1cf8738d2caa@github.com>
Message-ID: <qJDkLOGPlwa0Xx9AuIpzqfMNsZHnrgnlXyOeR12QoF4=.d8b4d4f5-2e85-4f39-a74f-57233763a9c8@github.com>

On Fri, 5 Nov 2021 14:37:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that improves the way G1 iterates over Howl-Full containers (i.e. "Full" cardsetptrs within a Howl cardset container)? Instead of calling the visitor method `do_card` to mark a single card for all cards in the range, just call the range-based visitor method `do_card_range`. This is also a little bit more efficient.
>> 
>> This change is a requirement for [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056).
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve chunk marking

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Nov  8 12:52:41 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 8 Nov 2021 12:52:41 GMT
Subject: RFR: 8276540: Howl Full CardSet container iteration marks too many
 cards
In-Reply-To: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
References: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
Message-ID: <G-wcJbXNlqwJoOPUkWiCWOSfHAMnz65h5MhrE0rwxR4=.5c75af0d-4fbc-4a19-b707-63eff7b1cfee@github.com>

On Wed, 3 Nov 2021 10:49:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that fixes how many cards are being iterated over during Howl Full CardSet container iteration? There is no need to iterate over `max_cards_in_region()` cards, it is sufficient to iterate just over the area that this Howl partition represents, i.e. `num_cards_in_howl_bitmap()`.
> 
> I will change the way to iterate over this card set container within the howl container in JDK-8276548 to keep this change small.
> 
> Testing: tier1-5 (with JDK-8276548).

Marked as reviewed by sjohanss (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 13:02:41 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 13:02:41 GMT
Subject: RFR: 8276540: Howl Full CardSet container iteration marks too many
 cards
In-Reply-To: <oWFHsmU7twKJ6kboO4pA7Vg5d0gFLgFniLrqUWwnPGE=.490ae10d-0660-4071-afac-7d575f2f760a@github.com>
References: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
 <oWFHsmU7twKJ6kboO4pA7Vg5d0gFLgFniLrqUWwnPGE=.490ae10d-0660-4071-afac-7d575f2f760a@github.com>
Message-ID: <KxfqcDNZYVXWKOOKwlDtTwSRjUjIMVOA4PHt_QPOuEo=.0f3eb3d2-e5c6-4d2c-9185-3ea343e513ab@github.com>

On Wed, 3 Nov 2021 11:30:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes how many cards are being iterated over during Howl Full CardSet container iteration? There is no need to iterate over `max_cards_in_region()` cards, it is sufficient to iterate just over the area that this Howl partition represents, i.e. `num_cards_in_howl_bitmap()`.
>> 
>> I will change the way to iterate over this card set container within the howl container in JDK-8276548 to keep this change small.
>> 
>> Testing: tier1-5 (with JDK-8276548).
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 13:02:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 13:02:42 GMT
Subject: Integrated: 8276540: Howl Full CardSet container iteration marks too
 many cards
In-Reply-To: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
References: <sbz-DrPCYWYenypAo_91OQcKHBYk24x5N0Ze3I4SKGc=.dd7025bc-adef-41d8-b030-821587052924@github.com>
Message-ID: <r4X_hwX7E04Iq_J7q_uVMr58xiuWARAyeVO_7wko1RE=.83c93b58-725f-4eb8-9bee-5dbcda2fddf2@github.com>

On Wed, 3 Nov 2021 10:49:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that fixes how many cards are being iterated over during Howl Full CardSet container iteration? There is no need to iterate over `max_cards_in_region()` cards, it is sufficient to iterate just over the area that this Howl partition represents, i.e. `num_cards_in_howl_bitmap()`.
> 
> I will change the way to iterate over this card set container within the howl container in JDK-8276548 to keep this change small.
> 
> Testing: tier1-5 (with JDK-8276548).

This pull request has now been integrated.

Changeset: ff6863c9
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff6863c98dbd15c4f3920402eb0991727d1a380c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8276540: Howl Full CardSet container iteration marks too many cards

Reviewed-by: ayang, sjohanss

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 13:05:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 13:05:55 GMT
Subject: RFR: 8276548: Use range based visitor for Howl-Full cards [v3]
In-Reply-To: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
References: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
Message-ID: <i2T4HZId_icCUd5VP77OrRtPR3Q6DUGodOquoYsLQKs=.7e15e018-ff82-4b4f-9588-d4ec70425446@github.com>

> Hi all,
> 
>   can I have reviews for this change that improves the way G1 iterates over Howl-Full containers (i.e. "Full" cardsetptrs within a Howl cardset container)? Instead of calling the visitor method `do_card` to mark a single card for all cards in the range, just call the range-based visitor method `do_card_range`. This is also a little bit more efficient.
> 
> This change is a requirement for [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056).
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

 - Merge branch 'master' into 8276548-range-based-visitor
 - Improve chunk marking
 - Merge branch '8276540-howl-full-bitmap' into 8276548-range-based-visitor
 - Fix
 - Remove debug code
 - Fix length of entry

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

Changes: https://git.openjdk.java.net/jdk/pull/6230/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6230&range=02
  Stats: 17 lines in 2 files changed: 4 ins; 5 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6230.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6230/head:pull/6230

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


From sjohanss at openjdk.java.net  Mon Nov  8 13:29:07 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 8 Nov 2021 13:29:07 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v2]
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <C2T3y30Jg24S73nhWK8W3yHzJXywhVEYViYyICAdnF8=.d126e738-59b4-4e84-81f8-b0c02d1420b1@github.com>

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

Stefan Johansson has updated the pull request incrementally with four additional commits since the last revision:

 - Move BOT info into PLAB
 - Predicate for needs_bot_update
 - Rename allocate_no_bot_updates
 - Handle waste when filling in dummy objects

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6166/files
  - new: https://git.openjdk.java.net/jdk/pull/6166/files/1fba1027..e6ec3bd9

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

  Stats: 185 lines in 14 files changed: 56 ins; 77 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6166/head:pull/6166

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


From tschatzl at openjdk.java.net  Mon Nov  8 13:43:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 13:43:39 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v2]
In-Reply-To: <C2T3y30Jg24S73nhWK8W3yHzJXywhVEYViYyICAdnF8=.d126e738-59b4-4e84-81f8-b0c02d1420b1@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <C2T3y30Jg24S73nhWK8W3yHzJXywhVEYViYyICAdnF8=.d126e738-59b4-4e84-81f8-b0c02d1420b1@github.com>
Message-ID: <366R80HSWT-wyHSd4X3tI73N-q67_Pj8Ktuw-mc_Ac8=.f93a8e67-2f8c-403b-9978-e47f07dcc24f@github.com>

On Mon, 8 Nov 2021 13:29:07 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Move BOT info into PLAB
>  - Predicate for needs_bot_update
>  - Rename allocate_no_bot_updates
>  - Handle waste when filling in dummy objects

Lgtm. Some minor naming/method location suggestions.

src/hotspot/share/gc/g1/g1Allocator.hpp line 221:

> 219: 
> 220:   // Update the BOT for the last PLAB allocation.
> 221:   inline void update_bot_for_allocation(G1HeapRegionAttr dest, size_t word_sz, uint node_index);

Suggestion:

  inline void update_bot_for_allocation(G1HeapRegionAttr dest, size_t word_sz, uint node_index);

Suggestion:

  inline void update_bot_for_plab_allocation(G1HeapRegionAttr dest, size_t word_sz, uint node_index);


I would explicitly call this out as to be used for PLAB allocation. If changed, obviously needs updates to the callers as well.

src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp line 106:

> 104:   bool is_old() const                  { return type() == Old; }
> 105:   bool is_optional() const             { return type() == Optional; }
> 106:   bool needs_bot_update() const        { return is_old(); }

Not sure if that predicate needs to be here, I'd probably just add a method to `G1PLABAllocator`. But it is fine to me.

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

Marked as reviewed by tschatzl (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Nov  8 14:02:38 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 8 Nov 2021 14:02:38 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v2]
In-Reply-To: <366R80HSWT-wyHSd4X3tI73N-q67_Pj8Ktuw-mc_Ac8=.f93a8e67-2f8c-403b-9978-e47f07dcc24f@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <C2T3y30Jg24S73nhWK8W3yHzJXywhVEYViYyICAdnF8=.d126e738-59b4-4e84-81f8-b0c02d1420b1@github.com>
 <366R80HSWT-wyHSd4X3tI73N-q67_Pj8Ktuw-mc_Ac8=.f93a8e67-2f8c-403b-9978-e47f07dcc24f@github.com>
Message-ID: <YpZjdYrfv6c1T4lYuqxaDUaYrK1zwEdnjYhncNRzLE8=.16746280-25c8-483e-a29e-ba9257200e1f@github.com>

On Mon, 8 Nov 2021 13:40:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Move BOT info into PLAB
>>  - Predicate for needs_bot_update
>>  - Rename allocate_no_bot_updates
>>  - Handle waste when filling in dummy objects
>
> Lgtm. Some minor naming/method location suggestions.

Me and @tschatzl have discussed this offline and the above changes are the outcome of that. I will redo testing and if anything doesn't look good I'll update the PR.

To summarize the changes a bit:
* The new G1 PLAB is changed to hold the region and threshold information and is only used for old generation PLABs.
* BOT updates for PLAB and region waste is handled by making sure any filler objects get updates if in old regions.
* No need to filter direct allocations when updating BOT for PLAB allocation since a direct allocation will never alter the PLAB `_top`.

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

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


From sjohanss at openjdk.java.net  Mon Nov  8 14:47:08 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 8 Nov 2021 14:47:08 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  Thomas review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6166/files
  - new: https://git.openjdk.java.net/jdk/pull/6166/files/e6ec3bd9..df900c6e

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

  Stats: 18 lines in 4 files changed: 10 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6166.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6166/head:pull/6166

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


From tschatzl at openjdk.java.net  Mon Nov  8 15:00:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 15:00:42 GMT
Subject: RFR: 8276548: Use range based visitor for Howl-Full cards [v3]
In-Reply-To: <qjRLdnFID75a4mCMGlV4Xy5_BQeCNwWkhz7fJOkAtHo=.ae07766f-5c0c-4cb0-8444-8fdf24a53f3b@github.com>
References: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
 <qjRLdnFID75a4mCMGlV4Xy5_BQeCNwWkhz7fJOkAtHo=.ae07766f-5c0c-4cb0-8444-8fdf24a53f3b@github.com>
Message-ID: <sswl-CLd3rQ7IMjX0hIm_nlYEgQlcneeOtcQstX5ufY=.38fcb280-e6d1-407f-ac22-8fcc2e78fb19@github.com>

On Fri, 5 Nov 2021 13:46:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into 8276548-range-based-visitor
>>  - Improve chunk marking
>>  - Merge branch '8276540-howl-full-bitmap' into 8276548-range-based-visitor
>>  - Fix
>>  - Remove debug code
>>  - Fix length of entry
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 15:03:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 15:03:43 GMT
Subject: Integrated: 8276548: Use range based visitor for Howl-Full cards
In-Reply-To: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
References: <7mHC8rvSrR39p_jxnQa3YkajWShKQ2HqQGoNRq7r2zs=.dbd7c2ae-e2e2-4cb1-9a62-e5015fe3e23f@github.com>
Message-ID: <_iZholfs3M39EEeYB_rGyhxf2bIsDtEkTIBPEOF9BaY=.3fb664ee-fc32-4897-b4c6-9417e72e8457@github.com>

On Wed, 3 Nov 2021 11:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that improves the way G1 iterates over Howl-Full containers (i.e. "Full" cardsetptrs within a Howl cardset container)? Instead of calling the visitor method `do_card` to mark a single card for all cards in the range, just call the range-based visitor method `do_card_range`. This is also a little bit more efficient.
> 
> This change is a requirement for [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056).
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 7320b77b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7320b77b3e451932ee8befa7af4b80593725761e
Stats:     17 lines in 2 files changed: 4 ins; 5 del; 8 mod

8276548: Use range based visitor for Howl-Full cards

Reviewed-by: ayang, sjohanss

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 15:11:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 15:11:53 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v8]
In-Reply-To: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
Message-ID: <wZEGwq_b1crh1_QJhxM0xdZ-hJkvOI5RoBRQVyrU6T8=.42a1b251-dd9c-4d9c-a082-b1345a9915a1@github.com>

> Hi all,
> 
> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region?
> 
> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`.
> 
> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`).
> 
> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected.
> 
> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?).
> 
> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
> 
> There is also a CSR to look at.
> 
> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
> 
> Thanks,
> Thomas

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

 - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
 - ayang review1
 - Limit ergonomics to 32m regions
 - sjohanss review
 - Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor
 - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
 - 32 bit compatibility - limit region size to 32M there as before. Fix test.
 - Virtual heap regions in remembered sets

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

Changes: https://git.openjdk.java.net/jdk/pull/6059/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=07
  Stats: 242 lines in 12 files changed: 148 ins; 68 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6059.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059

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


From tschatzl at openjdk.java.net  Mon Nov  8 15:11:54 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 15:11:54 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v7]
In-Reply-To: <edpyM6cJI4F5reakxeRTcqJOAuGt-lR-PkYbL4PMNPw=.988cd099-f760-4b97-bfdf-b932569bce88@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
 <edpyM6cJI4F5reakxeRTcqJOAuGt-lR-PkYbL4PMNPw=.988cd099-f760-4b97-bfdf-b932569bce88@github.com>
Message-ID: <ATGdINeqn0bJLPnxR8JRXmDBpHGwE86fwIgwaiFASWY=.85312a0f-b0a9-4b8e-b511-094d85dca2fa@github.com>

On Thu, 28 Oct 2021 14:54:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region?
>> 
>> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`.
>> 
>> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`).
>> 
>> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected.
>> 
>> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?).
>> 
>> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
>> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
>> 
>> There is also a CSR to look at.
>> 
>> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
>> 
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review1

With the change for JDK-8276548 / PR#6230 now in (I merged it for your convenience), this change works now :) There has been no change in this PR, but the processing of "Full" cards has been wrong with region virtualization.

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

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


From tschatzl at openjdk.java.net  Mon Nov  8 15:12:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 8 Nov 2021 15:12:37 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
Message-ID: <F1c_GdIAHM13X1Ge-Yg8waQK5JXyxxqCESqzAuRPalw=.c3212c5c-255a-4bcd-a0a4-f9bca464e1ba@github.com>

On Mon, 8 Nov 2021 14:47:08 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

Even better :)

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Nov  8 15:34:37 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 8 Nov 2021 15:34:37 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
Message-ID: <hTQ7vuARrKPcuR-6-Wix_-VZflz1UJ90jqODQlRl75U=.379923d8-3402-485e-b3c2-5fb31bcbbcef@github.com>

On Mon, 8 Nov 2021 14:47:08 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

Just some minor comments/suggestions.

src/hotspot/share/gc/g1/g1Allocator.cpp line 308:

> 306:       } else {
> 307:         _alloc_buffers[state][node_index] = new PLAB(_g1h->desired_plab_sz(state));
> 308:       }

I think ternary operator can be used here:

word_sz = _g1h->desired_plab_sz(state);
// ...
_alloc_buffers[state][node_index] = (state == G1HeapRegionAttr::Old)
                                  ? new G1BotUpdatingPLAB(word_sz)
                                  : new PLAB(word_sz);

src/hotspot/share/gc/g1/g1Allocator.hpp line 159:

> 157:   G1BotUpdatingPLAB(size_t word_sz) : PLAB(word_sz) { }
> 158:   // Sets the new PLAB buffer as well as updates the threshold and region.
> 159:   virtual void set_buf(HeapWord* buf, size_t word_sz);

Is `override` better here?

src/hotspot/share/gc/g1/heapRegion.inline.hpp line 248:

> 246:          "Should only calculate BOT threshold for old regions. addr: " PTR_FORMAT " region:" HR_FORMAT,
> 247:          p2i(addr), HR_FORMAT_PARAMS(this));
> 248:   return _bot_part.threshold_for_addr(addr);

Instead of calling `_bot_part.threshold_for_addr` multiple times, storing the result in a local var could be cleaner.

src/hotspot/share/gc/shared/plab.hpp line 122:

> 120: 
> 121:   // Sets the space of the buffer to be [buf, space+word_sz()).
> 122:   virtual void set_buf(HeapWord* buf, size_t new_word_sz) {

I wonder if `override` is better.

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

Changes requested by ayang (Reviewer).

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


From mli at openjdk.java.net  Tue Nov  9 03:10:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 03:10:47 GMT
Subject: RFR: 8276833: G1: make G1EvacFailureRegions::par_iterate const
Message-ID: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>

This is a trivial code enhancement to make G1EvacFailureRegions::par_iterate const.

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

Commit messages:
 - Initial commit

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

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


From mli at openjdk.java.net  Tue Nov  9 03:54:46 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 03:54:46 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate
Message-ID: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>

Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
We should refine it in some way.

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

Commit messages:
 - Refine code
 - Initial commit

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

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


From mli at openjdk.java.net  Tue Nov  9 06:50:57 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 06:50:57 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
Message-ID: <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>

> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
> We should refine it in some way.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6303/files
  - new: https://git.openjdk.java.net/jdk/pull/6303/files/d496ded4..4b33882b

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

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

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


From duke at openjdk.java.net  Tue Nov  9 07:41:38 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 9 Nov 2021 07:41:38 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
Message-ID: <ov6_t5uS-8_ujEGlFH_BqzBMoukju2_23kkRR-FodtY=.f7bf9ede-e1e4-4810-8100-9520f164b5df@github.com>

On Mon, 8 Nov 2021 14:47:08 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

First of all, pause time looks good from my test~

I was thinking that ``forward_to_block_containing_addr_slow`` should never be reached now, since all entries are now precise. However, when I add ShouldNotReachHere before ``forward_to_block_containing_addr_slow`` in ``G1BlockOffsetTablePart::forward_to_block_containing_addr`` I noticed that there are some exceptional cases and in these cases ``n`` always equals to ``addr``. Not sure if this is expected? I'll continue looking, just want to report this very quickly.

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

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


From mli at openjdk.java.net  Tue Nov  9 07:57:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 07:57:59 GMT
Subject: RFR: 8276842 G1: Only calculate size in bytes from words when needed
Message-ID: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>

This is a minor improvement in RemoveSelfForwardPtrObjClosure.
Currently, RemoveSelfForwardPtrObjClosure::do_object calculates from size in words to size in bytes every time, it's not necessary to do so, only needs to calculate the size when needed.

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

Commit messages:
 - Initial commit

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 08:53:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 08:53:39 GMT
Subject: RFR: 8276842 G1: Only calculate size in bytes from words when
 needed
In-Reply-To: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
References: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
Message-ID: <2SFg28NZSWHFw1eZlSw8V6rjW8_DQLOU6XPRusgWv14=.d84fb9c4-6bee-44d9-925c-80d1dcf073a9@github.com>

On Tue, 9 Nov 2021 07:49:15 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement in RemoveSelfForwardPtrObjClosure.
> Currently, RemoveSelfForwardPtrObjClosure::do_object calculates from size in words to size in bytes every time, it's not necessary to do so, only needs to calculate the size when needed.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Nov  9 08:55:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 08:55:37 GMT
Subject: RFR: 8276833: G1: Make G1EvacFailureRegions::par_iterate const
In-Reply-To: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
References: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
Message-ID: <6gpHnYiyTQuH66GuzltcugeHNgObP9p61ARXHj-Vhp8=.0b066849-580a-47fa-b15c-6cf37c7aed8e@github.com>

On Tue, 9 Nov 2021 03:02:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial code enhancement to make G1EvacFailureRegions::par_iterate const.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Nov  9 08:57:16 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 08:57:16 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <hTQ7vuARrKPcuR-6-Wix_-VZflz1UJ90jqODQlRl75U=.379923d8-3402-485e-b3c2-5fb31bcbbcef@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
 <hTQ7vuARrKPcuR-6-Wix_-VZflz1UJ90jqODQlRl75U=.379923d8-3402-485e-b3c2-5fb31bcbbcef@github.com>
Message-ID: <VcHC6UAtmDVyjPOkpX24Kgq8u4mCvZbhfHgGktDNBdA=.58a6463d-b79e-4821-b800-b0c361212428@github.com>

On Mon, 8 Nov 2021 15:30:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Thomas review
>
> src/hotspot/share/gc/shared/plab.hpp line 122:
> 
>> 120: 
>> 121:   // Sets the space of the buffer to be [buf, space+word_sz()).
>> 122:   virtual void set_buf(HeapWord* buf, size_t new_word_sz) {
> 
> I wonder if `override` is better.

This is the base class so this is not an `override` but declaring the function as `virtual`.

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

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


From sjohanss at openjdk.java.net  Tue Nov  9 09:03:37 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 09:03:37 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <hTQ7vuARrKPcuR-6-Wix_-VZflz1UJ90jqODQlRl75U=.379923d8-3402-485e-b3c2-5fb31bcbbcef@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
 <hTQ7vuARrKPcuR-6-Wix_-VZflz1UJ90jqODQlRl75U=.379923d8-3402-485e-b3c2-5fb31bcbbcef@github.com>
Message-ID: <ZwagS5uLUXzlOUOYu3SLWRbxB6nNAR1KwjqdXSiwBdc=.5c1742ba-5c73-4f6c-9468-1335a2ac9ae1@github.com>

On Mon, 8 Nov 2021 15:30:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Thomas review
>
> src/hotspot/share/gc/g1/g1Allocator.hpp line 159:
> 
>> 157:   G1BotUpdatingPLAB(size_t word_sz) : PLAB(word_sz) { }
>> 158:   // Sets the new PLAB buffer as well as updates the threshold and region.
>> 159:   virtual void set_buf(HeapWord* buf, size_t word_sz);
> 
> Is `override` better here?

I can change this to `override` if you prefer. I see that we have some uses of it in G1 already.

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 09:16:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 09:16:44 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
Message-ID: <8rDd5gpL0bQsZvbElXvXkqwiOEj_-aa8VWHytmec92c=.0175d14a-c70e-46f7-9d56-65b3c60502a1@github.com>

On Tue, 9 Nov 2021 06:50:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
>> We should refine it in some way.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

I do not think this change solves what it was intended to do: `G1EvacFailureObjectsSet:handle_iteration()` is still destructive, and the rest of the changes seem to just be moving around code, and making more stuff visible in the header file, overall complicating the code imho.

What about renaming `G1EvacFailureObjectsSet:iterate` to `G1EvacFailureObjectsSet:iterate_and_drop/empty/remove`? Or, as mentioned earlier, have an explicit `drop/remove/emtpy` method in `G1EvacFailureObjectsSet` and call it appropriately?
The former would be my preferred solution because it is then called distinctively enough from a normal `iterate` method, and does not completely mess up current code.

The cause of all this may have been the decision to put `G1EvacFailureObjectsSet`, a data structure only interesting during (young) gc that needs some per-gc handling, into the permanently valid `HeapRegion` data structure - I'll handle this refactoring though as mentioned. 

Let's sync with @albertnetymk about this before continuing.

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

Changes requested by tschatzl (Reviewer).

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


From duke at openjdk.java.net  Tue Nov  9 09:21:43 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 9 Nov 2021 09:21:43 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <ov6_t5uS-8_ujEGlFH_BqzBMoukju2_23kkRR-FodtY=.f7bf9ede-e1e4-4810-8100-9520f164b5df@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
 <ov6_t5uS-8_ujEGlFH_BqzBMoukju2_23kkRR-FodtY=.f7bf9ede-e1e4-4810-8100-9520f164b5df@github.com>
Message-ID: <Djq3ibBrJsdZ58ndM_YVXvkc9uFB2m2sajIz6L2AqjU=.0ded0e28-f6fd-42e9-949a-06770e51c8ef@github.com>

On Tue, 9 Nov 2021 07:39:03 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> I was thinking that `forward_to_block_containing_addr_slow` should never be reached now, since all entries are now precise. However, when I add ShouldNotReachHere before `forward_to_block_containing_addr_slow` in `G1BlockOffsetTablePart::forward_to_block_containing_addr` I noticed that there are some exceptional cases and in these cases `n` always equals to `addr`. Not sure if this is expected? I'll continue looking, just want to report this very quickly.

Okay, it's actually not relevant to this patch. ``G1ScanHRForRegionClosure::do_claimed_block`` has made an unaligned request to BOT because of ``_scanned_to``. That is, ``_scanned_to`` is not aligned on card boundary. And this causes a slow path. I think there might be an easy way to prevent slow path, e.g., make a special case for unaligned mr.start() in ``HeapRegion::oops_on_memregion_seq_iterate_careful``. But that might be another topic.

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

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


From ayang at openjdk.java.net  Tue Nov  9 09:21:43 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 09:21:43 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <ZwagS5uLUXzlOUOYu3SLWRbxB6nNAR1KwjqdXSiwBdc=.5c1742ba-5c73-4f6c-9468-1335a2ac9ae1@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
 <hTQ7vuARrKPcuR-6-Wix_-VZflz1UJ90jqODQlRl75U=.379923d8-3402-485e-b3c2-5fb31bcbbcef@github.com>
 <ZwagS5uLUXzlOUOYu3SLWRbxB6nNAR1KwjqdXSiwBdc=.5c1742ba-5c73-4f6c-9468-1335a2ac9ae1@github.com>
Message-ID: <TuSjEFgfNmll6-3gVE8xKq6TEafPTIOdJFrMlDLrWvA=.e9f60a8a-e642-4d1a-88fd-adb8a9767c9c@github.com>

On Tue, 9 Nov 2021 09:00:21 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Allocator.hpp line 159:
>> 
>>> 157:   G1BotUpdatingPLAB(size_t word_sz) : PLAB(word_sz) { }
>>> 158:   // Sets the new PLAB buffer as well as updates the threshold and region.
>>> 159:   virtual void set_buf(HeapWord* buf, size_t word_sz);
>> 
>> Is `override` better here?
>
> I can change this to `override` if you prefer. I see that we have some uses of it in G1 already.

Yes please, since it makes the intention explicit and enforces it in compile-time.

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

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


From ayang at openjdk.java.net  Tue Nov  9 09:26:38 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 09:26:38 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <8rDd5gpL0bQsZvbElXvXkqwiOEj_-aa8VWHytmec92c=.0175d14a-c70e-46f7-9d56-65b3c60502a1@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
 <8rDd5gpL0bQsZvbElXvXkqwiOEj_-aa8VWHytmec92c=.0175d14a-c70e-46f7-9d56-65b3c60502a1@github.com>
Message-ID: <ZPDd3o1rwgDnAwwPZZyEGnbPsRY2bIJdIv8tlY__fU8=.6e947b79-e770-416e-8cf2-ea46dd486020@github.com>

On Tue, 9 Nov 2021 09:13:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The former would be my preferred solution

Agree; I prefer not having `iterate` in the name, sth like `process_and_drop/empty/remove`, but either is fine to me.

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

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


From mli at openjdk.java.net  Tue Nov  9 09:26:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 09:26:38 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
Message-ID: <6Z1gCr0v15ktqo5dFUGa5IhS1AhvwAagoNuV6JZZkbI=.589faa89-9b7e-43b2-85f3-167e6e19b6dc@github.com>

On Tue, 9 Nov 2021 06:50:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
>> We should refine it in some way.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

I was thinking handle_iteration() will be not that surprising for users as iterate(), but seems it's not.
Sure, let me just rename it as process_and_drop.

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 09:34:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 09:34:37 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <6Z1gCr0v15ktqo5dFUGa5IhS1AhvwAagoNuV6JZZkbI=.589faa89-9b7e-43b2-85f3-167e6e19b6dc@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
 <6Z1gCr0v15ktqo5dFUGa5IhS1AhvwAagoNuV6JZZkbI=.589faa89-9b7e-43b2-85f3-167e6e19b6dc@github.com>
Message-ID: <W0_SciS1MAz8PqrX06OWzp_ur2ryjxSqssY6gXujSf0=.fdf11af3-a6de-496f-a7a5-5cf81e617420@github.com>

On Tue, 9 Nov 2021 09:23:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> I was thinking handle_iteration() will be not that surprising for users as iterate(), but seems it's not. Sure, let me just rename it as process_and_drop.

The main issue I have with the current change is that this is a changeset with 160 changed lines for the purpose of renaming two methods which are each called once. That seems completely off.

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 09:39:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 09:39:39 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <Djq3ibBrJsdZ58ndM_YVXvkc9uFB2m2sajIz6L2AqjU=.0ded0e28-f6fd-42e9-949a-06770e51c8ef@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
 <ov6_t5uS-8_ujEGlFH_BqzBMoukju2_23kkRR-FodtY=.f7bf9ede-e1e4-4810-8100-9520f164b5df@github.com>
 <Djq3ibBrJsdZ58ndM_YVXvkc9uFB2m2sajIz6L2AqjU=.0ded0e28-f6fd-42e9-949a-06770e51c8ef@github.com>
Message-ID: <M9or38xtscUgW2m6B2cyGOzu81RA1dh5QYKU1yNLgu4=.75499d3d-ef1e-434f-890c-4e6ec809069e@github.com>

On Tue, 9 Nov 2021 09:18:58 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Okay, it's actually not relevant to this patch. `G1ScanHRForRegionClosure::do_claimed_block` has made an unaligned request to BOT because of `_scanned_to`. That is, `_scanned_to` is not aligned on card boundary. And this causes a slow path. I think there might be an easy way to prevent slow path, e.g., make a special case for unaligned mr.start() in `HeapRegion::oops_on_memregion_seq_iterate_careful`. But that might be another topic.

In this case `_scanned_to` points to a valid object anyway; from just reading the code, possibly the `block_start()` call in `HeapRegion::oops_on_memregion_seq_iterate_careful` shouldn't be done in this case. Maybe if the caller of `HeapRegion::oops_on_memregion_seq_iterate_careful` already finds the necessary start.

Or `block_start` could be changed to `block_start_const` in this case.

However this is a different issue I think.

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

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


From sjohanss at openjdk.java.net  Tue Nov  9 09:50:01 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 09:50:01 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:

  Albert review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6166/files
  - new: https://git.openjdk.java.net/jdk/pull/6166/files/df900c6e..83049e18

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

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

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


From sjohanss at openjdk.java.net  Tue Nov  9 10:00:42 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 10:00:42 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v3]
In-Reply-To: <M9or38xtscUgW2m6B2cyGOzu81RA1dh5QYKU1yNLgu4=.75499d3d-ef1e-434f-890c-4e6ec809069e@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <xjAOinH1a51Dx25CtaegOOVivq5rt-mVblmZphTcmPA=.778fc635-6c2e-4850-92b1-f198076b132c@github.com>
 <ov6_t5uS-8_ujEGlFH_BqzBMoukju2_23kkRR-FodtY=.f7bf9ede-e1e4-4810-8100-9520f164b5df@github.com>
 <Djq3ibBrJsdZ58ndM_YVXvkc9uFB2m2sajIz6L2AqjU=.0ded0e28-f6fd-42e9-949a-06770e51c8ef@github.com>
 <M9or38xtscUgW2m6B2cyGOzu81RA1dh5QYKU1yNLgu4=.75499d3d-ef1e-434f-890c-4e6ec809069e@github.com>
Message-ID: <-I_SewX2YyP5kqAkoSysmGPufqhvz4A9rxnpg2o0wD8=.9ce497ac-7f1a-4bc2-959d-b5a7cb33141d@github.com>

On Tue, 9 Nov 2021 09:36:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> > Okay, it's actually not relevant to this patch. `G1ScanHRForRegionClosure::do_claimed_block` has made an unaligned request to BOT because of `_scanned_to`. That is, `_scanned_to` is not aligned on card boundary. And this causes a slow path. I think there might be an easy way to prevent slow path, e.g., make a special case for unaligned mr.start() in `HeapRegion::oops_on_memregion_seq_iterate_careful`. But that might be another topic.
> 
> In this case `_scanned_to` points to a valid object anyway; from just reading the code, possibly the `block_start()` call in `HeapRegion::oops_on_memregion_seq_iterate_careful` shouldn't be done in this case. Maybe if the caller of `HeapRegion::oops_on_memregion_seq_iterate_careful` already finds the necessary start.
> 
> Or `block_start` could be changed to `block_start_const` in this case.
> 
> However this is a different issue I think.

I've created [JDK-8276229](https://bugs.openjdk.java.net/browse/JDK-8276229) and I plan to open a PR for this once this issue has been resolved. 

I also noticed that we sometimes still enter `forward_to_block_containing_addr_slow` and my solution is (as Thomas suggest) to use the "const" versions of the functions, but renamed without "const".

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

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


From mli at openjdk.java.net  Tue Nov  9 10:13:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 10:13:01 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v3]
In-Reply-To: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
Message-ID: <uxY6m-0WzwkR-LOU5BQ125etUqpi_ktieoNUqzdnLLo=.faccfe36-2990-49db-a4e8-4d5592871068@github.com>

> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
> We should refine it in some way.

Hamlin Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Just rename to remove iterate in names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6303/files
  - new: https://git.openjdk.java.net/jdk/pull/6303/files/4b33882b..21188299

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

  Stats: 127 lines in 5 files changed: 22 ins; 64 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6303/head:pull/6303

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


From mli at openjdk.java.net  Tue Nov  9 10:13:06 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 9 Nov 2021 10:13:06 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
Message-ID: <VF3TANjvUwmav5_L39Y0Q3o0c12r2etq3dVBzCB9Nq0=.e1c2106c-23a0-41a7-ace3-257486dd8786@github.com>

On Tue, 9 Nov 2021 06:50:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
>> We should refine it in some way.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos

Agree, seems it's too much code for such a trivial issue. :)

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

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


From duke at openjdk.java.net  Tue Nov  9 10:14:42 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 9 Nov 2021 10:14:42 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
Message-ID: <MA98v4hCIfo9bRXyLxxrSJoZWoTdtVxTtdAYNTx2zbs=.27541410-5ba5-420c-9329-a12fc9593cbd@github.com>

On Tue, 9 Nov 2021 09:50:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Okay, thanks for clarifying :)

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 10:20:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 10:20:37 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
Message-ID: <iYDB8HolHwOwEV9ogxqhpTwiK_fEIeByAfU7pW1VGY4=.9098448f-baa8-461c-a797-5f26eb014ed2@github.com>

On Tue, 9 Nov 2021 09:50:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

As mentioned, in this particular case even the `block_start_const` call would be unnecessary (in `oops_on_memregion_seq_iterate_careful`), but that's just another optimization specially for walking through the cards during scanning.

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 10:24:35 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 10:24:35 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v3]
In-Reply-To: <uxY6m-0WzwkR-LOU5BQ125etUqpi_ktieoNUqzdnLLo=.faccfe36-2990-49db-a4e8-4d5592871068@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <uxY6m-0WzwkR-LOU5BQ125etUqpi_ktieoNUqzdnLLo=.faccfe36-2990-49db-a4e8-4d5592871068@github.com>
Message-ID: <S4cy6EVt9gSzquu7VPnEGxB9ErSfUb45bee8iC9RsTw=.960680c0-0c87-4c16-ad9c-c85e4bd057d5@github.com>

On Tue, 9 Nov 2021 10:13:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
>> We should refine it in some way.
>
> Hamlin Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Lgtm apart from the one comment about the comment.

src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp line 77:

> 75:   // Apply the given ObjectClosure to all objects that failed evacuation. Objects
> 76:   // are passed in increasing address order.
> 77:   void process_and_drop(ObjectClosure* closure);

The comment needs some update, something like: "Apply the given ObjectClosure to all objects that failed evacuation and empties the list after processing. Objects are passed in increasing address order."

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

Marked as reviewed by tschatzl (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Nov  9 10:48:35 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 10:48:35 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <MA98v4hCIfo9bRXyLxxrSJoZWoTdtVxTtdAYNTx2zbs=.27541410-5ba5-420c-9329-a12fc9593cbd@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
 <MA98v4hCIfo9bRXyLxxrSJoZWoTdtVxTtdAYNTx2zbs=.27541410-5ba5-420c-9329-a12fc9593cbd@github.com>
Message-ID: <tlGV4CltkYZUEQcnUKx4uR4AQ4nUYbot-gqsZFDa2Rs=.6bc3c1f7-6065-4daa-a771-aea6903d5d2e@github.com>

On Tue, 9 Nov 2021 10:11:52 GMT, Yude Lin <duke at openjdk.java.net> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert review
>
> Okay, thanks for clarifying :)

@linade, also many thanks for verifying that the pause times look good on your side as well. 

If you want to get credited as a reviewer for this change you need to change your review response to be approved.

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

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


From ayang at openjdk.java.net  Tue Nov  9 11:08:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 11:08:35 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
Message-ID: <uQjoOh4B8jl6WkpeDmgdesz1exiVhgD0JMYuuwYxWcE=.7fce8f5d-a8de-4c51-9b7b-6c2eca9a130f@github.com>

On Tue, 9 Nov 2021 09:50:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

It took me a while to understand what `G1BlockOffsetTablePart::threshold_for_addr` does is essentially `align_up`. Maybe another PR to make the intention more explicit.

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

Marked as reviewed by ayang (Reviewer).

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


From duke at openjdk.java.net  Tue Nov  9 11:08:35 2021
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 9 Nov 2021 11:08:35 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
Message-ID: <pNiOl8IOcs4jo5VomUldm14O9i2sGl_6F-uPppjSm6E=.11175536-b226-4d9e-b198-8fcdd804de5c@github.com>

On Tue, 9 Nov 2021 09:50:01 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Please review this change to do precise BOT updates in the G1 evacuation phase.
>> 
>> **Summary**
>> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
>> 
>> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
>> 
>> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
>> 
>> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
>> 
>> **Testing**
>> All testing look good:
>> - [x] Mach5 tier1-5
>> - [x] Local stress testing
>> - [x] Performance testing and pause time comparisons
>
> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Marked as reviewed by linade at github.com (no known OpenJDK username).

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

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


From ayang at openjdk.java.net  Tue Nov  9 11:13:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 11:13:42 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v3]
In-Reply-To: <uxY6m-0WzwkR-LOU5BQ125etUqpi_ktieoNUqzdnLLo=.faccfe36-2990-49db-a4e8-4d5592871068@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <uxY6m-0WzwkR-LOU5BQ125etUqpi_ktieoNUqzdnLLo=.faccfe36-2990-49db-a4e8-4d5592871068@github.com>
Message-ID: <phc995aTnq6h_0nDWE7M6Oq4f5U_C8EWb9bO3C6UKRg=.eea0dcd1-390b-4a6f-960c-e79c7d4472bf@github.com>

On Tue, 9 Nov 2021 10:13:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
>> We should refine it in some way.
>
> Hamlin Li has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by ayang (Reviewer).

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

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


From ayang at openjdk.java.net  Tue Nov  9 11:13:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 11:13:42 GMT
Subject: RFR: 8276842 G1: Only calculate size in bytes from words when
 needed
In-Reply-To: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
References: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
Message-ID: <hKp4rSqGRx7k_wLNMAfh9cb6nV5N5uvM5DeVXQh3xxU=.d7fee8df-ff21-4b9e-ba88-70a19ca3fd62@github.com>

On Tue, 9 Nov 2021 07:49:15 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement in RemoveSelfForwardPtrObjClosure.
> Currently, RemoveSelfForwardPtrObjClosure::do_object calculates from size in words to size in bytes every time, it's not necessary to do so, only needs to calculate the size when needed.

Marked as reviewed by ayang (Reviewer).

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

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


From ayang at openjdk.java.net  Tue Nov  9 11:14:40 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 11:14:40 GMT
Subject: RFR: 8276833: G1: Make G1EvacFailureRegions::par_iterate const
In-Reply-To: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
References: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
Message-ID: <ubmBeoqj9XZLjHOjQOWwayEI8gsQ63C3ulk478iLHkY=.59e2135a-8c19-4359-b5c0-503c8833141c@github.com>

On Tue, 9 Nov 2021 03:02:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial code enhancement to make G1EvacFailureRegions::par_iterate const.

Marked as reviewed by ayang (Reviewer).

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

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


From sjohanss at openjdk.java.net  Tue Nov  9 11:14:45 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 11:14:45 GMT
Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase [v4]
In-Reply-To: <MA98v4hCIfo9bRXyLxxrSJoZWoTdtVxTtdAYNTx2zbs=.27541410-5ba5-420c-9329-a12fc9593cbd@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
 <pvMZJteNzAZD1VQ485O-iebOdhy8yQxSbF-ea8lx7p0=.6b60a4e4-0554-4bd6-81c1-a61c9334173e@github.com>
 <MA98v4hCIfo9bRXyLxxrSJoZWoTdtVxTtdAYNTx2zbs=.27541410-5ba5-420c-9329-a12fc9593cbd@github.com>
Message-ID: <g0pDqgV2toU9Y2VjYdz0QdAcW5ppTYbvgdJsP-P5-LY=.664d2b6e-a4d6-45fd-bef7-f4829a96461a@github.com>

On Tue, 9 Nov 2021 10:11:52 GMT, Yude Lin <duke at openjdk.java.net> wrote:

>> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert review
>
> Okay, thanks for clarifying :)

Thanks @linade, @albertnetymk and @tschatzl for the reviews.

My additional testing all looks good so I'll integrate straight away.

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

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


From sjohanss at openjdk.java.net  Tue Nov  9 11:14:46 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 11:14:46 GMT
Subject: Integrated: 8276098: Do precise BOT updates in G1 evacuation phase
In-Reply-To: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
References: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com>
Message-ID: <7qzk-R2h7z1Hlc6xFJoAvCelTS5GonRrD3pPbvwNlG0=.bf99a483-e8a7-4497-b2b6-b67c2816cc17@github.com>

On Fri, 29 Oct 2021 08:23:30 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to do precise BOT updates in the G1 evacuation phase.
> 
> **Summary**
> In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs).
> 
> The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs.
> 
> With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. 
> 
> Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions.
> 
> **Testing**
> All testing look good:
> - [x] Mach5 tier1-5
> - [x] Local stress testing
> - [x] Performance testing and pause time comparisons

This pull request has now been integrated.

Changeset: 945f4085
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/945f4085e5c51f37c2048bb221a1521895ba28c6
Stats:     243 lines in 15 files changed: 161 ins; 51 del; 31 mod

8276098: Do precise BOT updates in G1 evacuation phase

Reviewed-by: tschatzl, ayang

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

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


From duke at openjdk.java.net  Tue Nov  9 11:33:58 2021
From: duke at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Tue, 9 Nov 2021 11:33:58 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v5]
In-Reply-To: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
Message-ID: <zW-MoGjiIfGvnZQGYCm23Wclfh4R6JDL67F7b3clM0I=.449657ba-2690-42f4-90ae-bf02d44d67de@github.com>

> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
> 
> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
> 
> patch:
> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
> 
> 
> origin:
> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

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

  Use dynamic allocated array instead of static variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5670/files
  - new: https://git.openjdk.java.net/jdk/pull/5670/files/8961636f..d20be12b

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

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

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


From duke at openjdk.java.net  Tue Nov  9 12:06:59 2021
From: duke at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Tue, 9 Nov 2021 12:06:59 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v6]
In-Reply-To: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
Message-ID: <G5_C6hUW55vjpw1gdgsyPEK2bqs1FJL7q9VMdZGFjmQ=.8bbf385d-7e45-4847-b21f-526fc201dceb@github.com>

> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
> 
> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
> 
> patch:
> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
> 
> 
> origin:
> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

?? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Use dynamic allocated array instead of static variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5670/files
  - new: https://git.openjdk.java.net/jdk/pull/5670/files/d20be12b..b38e3ab1

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

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 12:12:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 12:12:56 GMT
Subject: RFR: 8276850: Remove outdated comment in
 HeapRegionManager::par_iterate
Message-ID: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>

Hi all,

  please review this (trivial?) removal of a hopelessly outdated comment about a method parameter that has not been there for years now...

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - Remove comment

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

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


From duke at openjdk.java.net  Tue Nov  9 12:20:47 2021
From: duke at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Tue, 9 Nov 2021 12:20:47 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v6]
In-Reply-To: <G5_C6hUW55vjpw1gdgsyPEK2bqs1FJL7q9VMdZGFjmQ=.8bbf385d-7e45-4847-b21f-526fc201dceb@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
 <G5_C6hUW55vjpw1gdgsyPEK2bqs1FJL7q9VMdZGFjmQ=.8bbf385d-7e45-4847-b21f-526fc201dceb@github.com>
Message-ID: <RUtzXQUmFmY86Ms-8EJaVhrNejnYk1arems20bxRDrw=.65b7e209-7939-40b5-8c91-3ef8b1597f51@github.com>

On Tue, 9 Nov 2021 12:06:59 GMT, ?? <duke at openjdk.java.net> wrote:

>> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
>> 
>> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
>> 
>> patch:
>> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
>> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
>> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
>> 
>> 
>> origin:
>> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
>> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
>> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms
>
> ?? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

hi, can I have more review of this pr?

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

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


From ayang at openjdk.java.net  Tue Nov  9 12:47:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 9 Nov 2021 12:47:35 GMT
Subject: RFR: 8276850: Remove outdated comment in
 HeapRegionManager::par_iterate
In-Reply-To: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
References: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
Message-ID: <eEuDG_a5hinj-6ycX4owVx9qzojPi9lVmlqhZw2O6sI=.da9e0a6e-3087-4a85-abfa-7ecd8851d21b@github.com>

On Tue, 9 Nov 2021 12:05:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this (trivial?) removal of a hopelessly outdated comment about a method parameter that has not been there for years now...
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Good and trivial.

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

Marked as reviewed by ayang (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Nov  9 12:52:35 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 9 Nov 2021 12:52:35 GMT
Subject: RFR: 8276850: Remove outdated comment in
 HeapRegionManager::par_iterate
In-Reply-To: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
References: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
Message-ID: <C9GgxZBGnB7D8xARl4ogt_2FVlEc1iDBy00SVuzgf9U=.33febd86-54da-420e-bac7-c6a7dd3f7cd7@github.com>

On Tue, 9 Nov 2021 12:05:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this (trivial?) removal of a hopelessly outdated comment about a method parameter that has not been there for years now...
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by sjohanss (Reviewer).

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

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


From shade at openjdk.java.net  Tue Nov  9 12:16:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 12:16:52 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with ZGC
Message-ID: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>

ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.

While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.

Additional testing:
 - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
 - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
 - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
 - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
 - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
 - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)

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

Commit messages:
 - Fix

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 13:11:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 13:11:43 GMT
Subject: RFR: 8276850: Remove outdated comment in
 HeapRegionManager::par_iterate
In-Reply-To: <eEuDG_a5hinj-6ycX4owVx9qzojPi9lVmlqhZw2O6sI=.da9e0a6e-3087-4a85-abfa-7ecd8851d21b@github.com>
References: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
 <eEuDG_a5hinj-6ycX4owVx9qzojPi9lVmlqhZw2O6sI=.da9e0a6e-3087-4a85-abfa-7ecd8851d21b@github.com>
Message-ID: <3NAAwIwDlonzynMIAJALo4TPabfODIN5dornnKRMaCQ=.5fe92f98-d6fc-4dba-99fd-a5b7d037aa16@github.com>

On Tue, 9 Nov 2021 12:44:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this (trivial?) removal of a hopelessly outdated comment about a method parameter that has not been there for years now...
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Good and trivial.

Thanks @albertnetymk @kstefanj for your reviews

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

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


From tschatzl at openjdk.java.net  Tue Nov  9 13:11:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 9 Nov 2021 13:11:44 GMT
Subject: Integrated: 8276850: Remove outdated comment in
 HeapRegionManager::par_iterate
In-Reply-To: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
References: <K8jcwG92iNbd4jDhVPBYoE25lq795kwQq3-89adq0QU=.1085bbc2-9b02-49be-82f5-1f4565a99cd3@github.com>
Message-ID: <TSz9EOjhRyT2jylzpkFWA1TBNsiZNl1P2NAnGU9tAJI=.ddc0e276-ccd7-45a9-baf8-559080c4f6bd@github.com>

On Tue, 9 Nov 2021 12:05:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this (trivial?) removal of a hopelessly outdated comment about a method parameter that has not been there for years now...
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 5c7f77c8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5c7f77c82404976a6ca1d54b40f1969eac10d63b
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8276850: Remove outdated comment in HeapRegionManager::par_iterate

Reviewed-by: ayang, sjohanss

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

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


From pliden at openjdk.java.net  Tue Nov  9 14:02:40 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 9 Nov 2021 14:02:40 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC
In-Reply-To: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
Message-ID: <GiI1AJLv7G13E2mONgBuA-9B_hz9CltCWLzyfyeAJgI=.29a5f665-96f2-4c00-8c1a-2333dcfa627b@github.com>

On Tue, 9 Nov 2021 12:09:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
> 
> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)

Looks good.

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

Marked as reviewed by pliden (Reviewer).

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


From stefank at openjdk.java.net  Tue Nov  9 14:20:39 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 9 Nov 2021 14:20:39 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC
In-Reply-To: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
Message-ID: <b1eT5s5qQ_wlSLjjvCtNdi0YuEhC5EUqn3-aorxjiBs=.2b27a4c0-c9ae-45aa-a8a1-fad806425999@github.com>

On Tue, 9 Nov 2021 12:09:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
> 
> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)

Looks like a sensible fix.

test/hotspot/jtreg/gc/TestSystemGC.java line 27:

> 25: 
> 26: /*
> 27:  * @test id=serial

In recent changes we used upper-case for the id labels. I think it would be good to be consistent and do the same here.

test/hotspot/jtreg/gc/TestSystemGC.java line 63:

> 61:  * @test id=z
> 62:  * @requires vm.gc.Z
> 63:  * @comment ZGC would not start when LargePages cannot be allocated, therefore

Maybe replace "ZGC would not" to "ZGC will not"?

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

Changes requested by stefank (Reviewer).

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


From shade at openjdk.java.net  Tue Nov  9 14:29:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 14:29:09 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v2]
In-Reply-To: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
Message-ID: <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>

> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
> 
> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6310/files
  - new: https://git.openjdk.java.net/jdk/pull/6310/files/1edc74c1..15170896

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

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

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


From shade at openjdk.java.net  Tue Nov  9 14:29:14 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 14:29:14 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v2]
In-Reply-To: <b1eT5s5qQ_wlSLjjvCtNdi0YuEhC5EUqn3-aorxjiBs=.2b27a4c0-c9ae-45aa-a8a1-fad806425999@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
 <b1eT5s5qQ_wlSLjjvCtNdi0YuEhC5EUqn3-aorxjiBs=.2b27a4c0-c9ae-45aa-a8a1-fad806425999@github.com>
Message-ID: <b6zID8BlzOLkbpfNe1RTwsiKlk1qj9VO6CqoZUgI7n4=.afc9bf67-aa0d-48ce-9f63-4a920c67f501@github.com>

On Tue, 9 Nov 2021 14:15:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/hotspot/jtreg/gc/TestSystemGC.java line 63:
> 
>> 61:  * @test id=z
>> 62:  * @requires vm.gc.Z
>> 63:  * @comment ZGC would not start when LargePages cannot be allocated, therefore
> 
> Maybe replace "ZGC would not" to "ZGC will not"?

Fixed.

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

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


From stefank at openjdk.java.net  Tue Nov  9 16:00:38 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 9 Nov 2021 16:00:38 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v2]
In-Reply-To: <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
 <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>
Message-ID: <zyOdOHEGP9heQ8A2ZDaTMKHtZJIJyAf52PCpUoeZB40=.b09a7b12-c35a-42ac-8118-24e98faba9be@github.com>

On Tue, 9 Nov 2021 14:29:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
>> 
>> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by stefank (Reviewer).

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

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


From zgu at openjdk.java.net  Tue Nov  9 16:09:56 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 16:09:56 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails intermittently
 with Shenandoah
Message-ID: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>

JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.

This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.

Test:

- [x] hotspot_gc_shenandoah
- [x] Stress test on gc/stress/CriticalNativeStress.java

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

Commit messages:
 - Consistent assert
 - Strength assert
 - v0

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

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


From shade at openjdk.java.net  Tue Nov  9 16:32:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 16:32:36 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>

On Tue, 9 Nov 2021 15:08:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

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

> 117: 
> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");

I don't understand this change.

This method is called from:


   // Unregister must be done before the state change
  {
    MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
                     Mutex::_no_safepoint_check_flag);
    Universe::heap()->unregister_nmethod(this);
  }


...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.

src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 283:

> 281:     data->update();
> 282:   } else {
> 283:     // For a new nmethod, we can safely append it to the list, cause

Suggestion:

    // For a new nmethod, we can safely append it to the list, because

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

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


From zgu at openjdk.java.net  Tue Nov  9 17:33:04 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 17:33:04 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

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

 - Revert assertion for unregister_nmethod
 - Fix comment as Aleksey suggested

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6316/files
  - new: https://git.openjdk.java.net/jdk/pull/6316/files/aaebcb81..0248f1e4

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

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

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


From zgu at openjdk.java.net  Tue Nov  9 17:33:08 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 17:33:08 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
Message-ID: <haHFS3HMAx7NN1Yzk1PziYn_Zdd9HD7XQPbQkAaCnEg=.982cebf4-e325-4fa4-8a96-686677ea9173@github.com>

On Tue, 9 Nov 2021 16:25:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert assertion for unregister_nmethod
>>  - Fix comment as Aleksey suggested
>
> src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp line 283:
> 
>> 281:     data->update();
>> 282:   } else {
>> 283:     // For a new nmethod, we can safely append it to the list, cause
> 
> Suggestion:
> 
>     // For a new nmethod, we can safely append it to the list, because

Fixed

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

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


From zgu at openjdk.java.net  Tue Nov  9 17:46:38 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 9 Nov 2021 17:46:38 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
Message-ID: <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>

On Tue, 9 Nov 2021 16:29:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert assertion for unregister_nmethod
>>  - Fix comment as Aleksey suggested
>
> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 119:
> 
>> 117: 
>> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
>> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");
> 
> I don't understand this change.
> 
> This method is called from:
> 
> 
>    // Unregister must be done before the state change
>   {
>     MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
>                      Mutex::_no_safepoint_check_flag);
>     Universe::heap()->unregister_nmethod(this);
>   }
> 
> 
> ...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.

Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().

Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 

It is not true for flush_nmethod(), where `CodeCache_lock` must be held.

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

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


From shade at openjdk.java.net  Tue Nov  9 17:53:34 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 9 Nov 2021 17:53:34 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
 <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
Message-ID: <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>

On Tue, 9 Nov 2021 17:43:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 119:
>> 
>>> 117: 
>>> 118: void ShenandoahCodeRoots::unregister_nmethod(nmethod* nm) {
>>> 119:   assert(CodeCache_lock->owned_by_self(), "Must have CodeCache_lock held");
>> 
>> I don't understand this change.
>> 
>> This method is called from:
>> 
>> 
>>    // Unregister must be done before the state change
>>   {
>>     MutexLocker ml(SafepointSynchronize::is_at_safepoint() ? NULL : CodeCache_lock,
>>                      Mutex::_no_safepoint_check_flag);
>>     Universe::heap()->unregister_nmethod(this);
>>   }
>> 
>> 
>> ...which would mean we _do not_ hold the `CodeCache_lock` at safepoint? Previous assert captured that fact. New one does not. Shouldn't this assert fail intermittently? Same goes for `register_nmethod`, `flush_nmethod`, probably.
>
> Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().
> 
> Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 
> 
> It is not true for flush_nmethod(), where `CodeCache_lock` must be held.

What about `register_nmethod`? I see it is called from `nmethod::nmethod` that itself does `assert_locked_or_safepoint(CodeCache_lock)`. Is that path guaranteed to always hold the `CodeCache_lock`?

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

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


From mli at openjdk.java.net  Wed Nov 10 01:16:42 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:16:42 GMT
Subject: RFR: 8276842 G1: Only calculate size in bytes from words when
 needed
In-Reply-To: <2SFg28NZSWHFw1eZlSw8V6rjW8_DQLOU6XPRusgWv14=.d84fb9c4-6bee-44d9-925c-80d1dcf073a9@github.com>
References: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
 <2SFg28NZSWHFw1eZlSw8V6rjW8_DQLOU6XPRusgWv14=.d84fb9c4-6bee-44d9-925c-80d1dcf073a9@github.com>
Message-ID: <4idiTt3eK3Rmx2gJ3eeCkdjU2kC8Utl66ycpezRDwgQ=.047d9137-ad2c-4707-97a6-ae897fef710c@github.com>

On Tue, 9 Nov 2021 08:50:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This is a minor improvement in RemoveSelfForwardPtrObjClosure.
>> Currently, RemoveSelfForwardPtrObjClosure::do_object calculates from size in words to size in bytes every time, it's not necessary to do so, only needs to calculate the size when needed.
>
> Lgtm.

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Wed Nov 10 01:16:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:16:44 GMT
Subject: RFR: 8276833: G1: Make G1EvacFailureRegions::par_iterate const
In-Reply-To: <6gpHnYiyTQuH66GuzltcugeHNgObP9p61ARXHj-Vhp8=.0b066849-580a-47fa-b15c-6cf37c7aed8e@github.com>
References: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
 <6gpHnYiyTQuH66GuzltcugeHNgObP9p61ARXHj-Vhp8=.0b066849-580a-47fa-b15c-6cf37c7aed8e@github.com>
Message-ID: <2aIzRa5scE7teY0WVWXsiiUr46xEjsJeaQGVctzbgWU=.c0349bb7-67a2-48ee-ba18-f6cc5b1e727f@github.com>

On Tue, 9 Nov 2021 08:52:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This is a trivial code enhancement to make G1EvacFailureRegions::par_iterate const.
>
> Lgtm.

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Wed Nov 10 01:16:42 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:16:42 GMT
Subject: Integrated: 8276842 G1: Only calculate size in bytes from words when
 needed
In-Reply-To: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
References: <ZTllMtedEHSAzVLZrekyNChLdZ9oLXfW6-H7_uhA1eQ=.40878f35-eb64-4aae-b32e-0b641ef7beeb@github.com>
Message-ID: <MhpYVqtbC8Pru2Jp1HWYHSC6pVYKKudjjVdDRlVx_08=.83f67f9c-7dc7-4550-89bf-e50238a0516e@github.com>

On Tue, 9 Nov 2021 07:49:15 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement in RemoveSelfForwardPtrObjClosure.
> Currently, RemoveSelfForwardPtrObjClosure::do_object calculates from size in words to size in bytes every time, it's not necessary to do so, only needs to calculate the size when needed.

This pull request has now been integrated.

Changeset: c1e41fe3
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c1e41fe38bbbae12e1f73d2cd63c7afffc19475b
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8276842: G1: Only calculate size in bytes from words when needed

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Wed Nov 10 01:16:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:16:44 GMT
Subject: Integrated: 8276833: G1: Make G1EvacFailureRegions::par_iterate const
In-Reply-To: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
References: <RFQQZJ4AHP5Rb7FGLlS0Fv-a19g3erOwdyw801sKIx0=.d4ee3016-46cb-415c-9eb7-21725f4da687@github.com>
Message-ID: <vV4Pm8SMSLA50kF1aqNXrSpvrv3sC-yyNrEwSu-vFqA=.793f2c79-9a48-4d9e-9a20-65feecb04bbb@github.com>

On Tue, 9 Nov 2021 03:02:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial code enhancement to make G1EvacFailureRegions::par_iterate const.

This pull request has now been integrated.

Changeset: c8b0ee6b
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8b0ee6b8a0c1bca8f8357e786f24c8cb6dd7310
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8276833: G1: Make G1EvacFailureRegions::par_iterate const

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Wed Nov 10 01:30:07 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:30:07 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v4]
In-Reply-To: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
Message-ID: <kSCuYsm20aJoKa8j0nJGq2-B6dwhJSUehITrZf_EvrE=.cfea20db-d921-4258-ad1b-43b8b682ac75@github.com>

> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
> We should refine it in some way.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Refine comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6303/files
  - new: https://git.openjdk.java.net/jdk/pull/6303/files/21188299..4d876798

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

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

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


From mli at openjdk.java.net  Wed Nov 10 01:30:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:30:08 GMT
Subject: RFR: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate [v2]
In-Reply-To: <W0_SciS1MAz8PqrX06OWzp_ur2ryjxSqssY6gXujSf0=.fdf11af3-a6de-496f-a7a5-5cf81e617420@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
 <aoWZH1cTvZVp6b9veXoVeKH0MwSI_W-IL4f3hs-3DPg=.0be874d3-14b1-4ed0-8f0a-a104455f4c68@github.com>
 <6Z1gCr0v15ktqo5dFUGa5IhS1AhvwAagoNuV6JZZkbI=.589faa89-9b7e-43b2-85f3-167e6e19b6dc@github.com>
 <W0_SciS1MAz8PqrX06OWzp_ur2ryjxSqssY6gXujSf0=.fdf11af3-a6de-496f-a7a5-5cf81e617420@github.com>
Message-ID: <5u3ZPU5wtERAILz3XJC0OCAE42IaFMi0HfyFaEqSirk=.00c19f2f-534b-41d3-8678-16d523b68159@github.com>

On Tue, 9 Nov 2021 09:31:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> I was thinking handle_iteration() will be not that surprising for users as iterate(), but seems it's not.
>> Sure, let me just rename it as process_and_drop.
>
>> I was thinking handle_iteration() will be not that surprising for users as iterate(), but seems it's not. Sure, let me just rename it as process_and_drop.
> 
> The main issue I have with the current change is that this is a changeset with 160 changed lines for the purpose of renaming two methods which are each called once. That seems completely off.

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Wed Nov 10 01:30:10 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 01:30:10 GMT
Subject: Integrated: 8276721: G1: Refine G1EvacFailureObjectsSet::iterate
In-Reply-To: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
References: <aEZecMdtniDq_MgaFD1svZsks5163CJLaUFaLo2QdnU=.2c67ccac-0cba-48a1-95e6-7e37e3b90bb6@github.com>
Message-ID: <8KqEHRwcBQRyaWfFV4qrjRYLib3xp-ARb04akiDGSCk=.dd50b4a4-2ede-48a9-93da-892e1e870917@github.com>

On Tue, 9 Nov 2021 03:49:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, G1EvacFailureObjectsSet::iterate(ObjectClosure* closure) is not a const method, but it looks like a const method. It will be a surprise for reader, i.e. you would not expect that an iteration method is destructive, clearing out the set it just iterated over.
> We should refine it in some way.

This pull request has now been integrated.

Changeset: e91e9d85
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e91e9d853272ea8f5ce490f2f0c971fd40795d74
Stats:     13 lines in 5 files changed: 1 ins; 0 del; 12 mod

8276721: G1: Refine G1EvacFailureObjectsSet::iterate

Reviewed-by: tschatzl, ayang

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

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


From duke at openjdk.java.net  Wed Nov 10 01:51:00 2021
From: duke at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Wed, 10 Nov 2021 01:51:00 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v7]
In-Reply-To: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
Message-ID: <ZOqKgidsYdOI0UsY1JTdTFA5oikHLQ3ia9yfEbPA4qQ=.1a02f9f1-3879-4710-815b-4d7725dd415a@github.com>

> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
> 
> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
> 
> patch:
> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
> 
> 
> origin:
> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

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

  Add header file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5670/files
  - new: https://git.openjdk.java.net/jdk/pull/5670/files/b38e3ab1..382139af

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

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

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


From zgu at openjdk.java.net  Wed Nov 10 02:13:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 02:13:37 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
 <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
 <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>
Message-ID: <L88acYPMjES7iP1Qja8NmqpC92qZELfmLHVI5c3ULHk=.80fd986c-3bb4-42a7-9db4-f136dd5060d5@github.com>

On Tue, 9 Nov 2021 17:50:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Good catch! I revert the assertion in ShenandoahCodeRoots::unregister_nmethod().
>> 
>> Above code is racy, because there can be a drive-by safepoint when the test is performed. However, it is not problem, because Shenandoah (so as ZGC) only tags the nmethod is unregistered. 
>> 
>> It is not true for flush_nmethod(), where `CodeCache_lock` must be held.
>
> What about `register_nmethod`? I see it is called from `nmethod::nmethod` that itself does `assert_locked_or_safepoint(CodeCache_lock)`. Is that path guaranteed to always hold the `CodeCache_lock`?

I changed assert in `nmethod::nmethod()` to `assert_lock_strong(CodeCache_lock)` and ran tier1, no failure.

`nmethods` is installed by `CompilerThread` and `CompilerThread` is `JavaThread`, so I don't think it is possible to have `register_nmethod()` call at safepoints, because they have to participate in safepoints.

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

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


From mli at openjdk.java.net  Wed Nov 10 05:53:07 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 05:53:07 GMT
Subject: RFR: 8276835: G1: make G1EvacFailureObjectsSet::record inline
Message-ID: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>

This is a minor improvement to make G1EvacFailureObjectsSet::record inline, which was not.

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

Commit messages:
 - Fix include guards
 - Initial commit

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

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


From mli at openjdk.java.net  Wed Nov 10 07:09:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 10 Nov 2021 07:09:41 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
Message-ID: <RO1oeNfev44EuXU0k2YGfm0P4AIVhQtEHU7MrSDbiQE=.c4a4c3bf-3959-4ed9-9504-0c0368a9dd5f@github.com>

On Mon, 8 Nov 2021 03:12:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Is some one available to have a look at this change? Thanks

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

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


From shade at openjdk.java.net  Wed Nov 10 07:58:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 07:58:38 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
Message-ID: <9p0dnTkpMvFGxsre3rUtXTWocsPXr_n355G_oVXiY0s=.d68e3f95-f022-4af2-9689-d9ee948dca5e@github.com>

On Tue, 9 Nov 2021 17:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert assertion for unregister_nmethod
>  - Fix comment as Aleksey suggested

I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table (https://github.com/openjdk/jdk/pull/6316/commits/0248f1e4cd6a8311f0532c637a31bd71c9041451), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?

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

Changes requested by shade (Reviewer).

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


From shade at openjdk.java.net  Wed Nov 10 07:58:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 07:58:38 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <L88acYPMjES7iP1Qja8NmqpC92qZELfmLHVI5c3ULHk=.80fd986c-3bb4-42a7-9db4-f136dd5060d5@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <zawL5250u1iOcwoAnaQA0YV0pqUujXvdOrK3YADZE1g=.60a14c10-2ebc-41a0-88a6-0beeefb8f113@github.com>
 <rxY_CAkZPYUjjdGzCpJIprWFqI85dtsXWiEP_65VjKg=.e90d0708-329d-47ee-836f-c034027da7fa@github.com>
 <M-HAuDKZiKkOusWmUUmnDx4UUdvUKFk7ByzYlvNSjdg=.c03f4074-dd20-49c4-a84e-11139b055b79@github.com>
 <L88acYPMjES7iP1Qja8NmqpC92qZELfmLHVI5c3ULHk=.80fd986c-3bb4-42a7-9db4-f136dd5060d5@github.com>
Message-ID: <l6SM550RuUAfOQMDvfngXOztaCHIsfPdzmUeqDzwAN4=.4c1cb2a9-94d9-4327-aa3e-2d17ee344f9a@github.com>

On Wed, 10 Nov 2021 02:11:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> What about `register_nmethod`? I see it is called from `nmethod::nmethod` that itself does `assert_locked_or_safepoint(CodeCache_lock)`. Is that path guaranteed to always hold the `CodeCache_lock`?
>
> I changed assert in `nmethod::nmethod()` to `assert_lock_strong(CodeCache_lock)` and ran tier1, no failure.
> 
> `nmethods` is installed by `CompilerThread` and `CompilerThread` is `JavaThread`, so I don't think it is possible to have `register_nmethod()` call at safepoints, because they have to participate in safepoints.

OK.

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

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


From tschatzl at openjdk.java.net  Wed Nov 10 08:44:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 08:44:59 GMT
Subject: RFR: 8272170: Missing memory barrier when checking active state for
 regions
Message-ID: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>

Hi all,

  can I have reviews for this fix to memory visibility race where we miss to make sure that the `HeapRegion` pointer in `HeapRegionManager::_regions` is visible before the "active"-check for that `HeapRegion` can return true?

I.e. the problem is this (according to my understanding):

void HeapRegionManager::expand(uint start, uint num_regions, WorkerThreads* pretouch_workers) {
  commit_regions(start, num_regions, pretouch_workers);
  for (uint i = start; i < start + num_regions; i++) {
    HeapRegion* hr = _regions.get_by_index(i);
    if (hr == NULL) {
      hr = new_heap_region(i);
      OrderAccess::storestore();
      _regions.set_by_index(i, hr);
      _allocated_heapregions_length = MAX2(_allocated_heapregions_length, i + 1);
    }
    G1CollectedHeap::heap()->hr_printer()->commit(hr);
  }
  activate_regions(start, num_regions);
}

E.g. we first commit the memory, then create a `HeapRegion` instance which we properly guard with a `StoreStore` before assigning it to the `_regions` array. After that at the end we activate the regions (via `activate_regions`), meaning that the contents of the new `HeapRegion*` in the region table are valid.
These bits in the `_active_regions` bitmap are put with memory barriers (via `par_set_range`).

In `HeapRegionManager::par_iterate`, if we iterate over the region map, we first check whether the region is available in the `_active_regions` bitmap, and then get and pass on the corresponding `HeapRegion*` to the given closure.

However there is no memory ordering between reading the available-bit in the `_active_regions` bitmap, so that bit could become visible to the thread iterating over the regions before the contents of the `_region` map itself, in effect passing a `nullptr` to the closure which isn't allowed. (Some details about the debugging session in the CR).


void HeapRegionManager::par_iterate(HeapRegionClosure* blk, HeapRegionClaimer* hrclaimer, const uint start_index) const {
  // Every worker will actually look at all regions, skipping over regions that
  // are currently not committed.
  // This also (potentially) iterates over regions newly allocated during GC. This
  // is no problem except for some extra work.
  const uint n_regions = hrclaimer->n_regions();
  for (uint count = 0; count < n_regions; count++) {
    const uint index = (start_index + count) % n_regions;
    assert(index < n_regions, "sanity");
    // Skip over unavailable regions
    if (!is_available(index)) {
      continue;
    }
    HeapRegion* r = _regions.get_by_index(index);
[...]
    bool res = blk->do_heap_region(r);
    if (res) {
      return;
    }
  }
}


The suggested fix is to ensure proper memory ordering in `is_available`, i.e. an acquire when accessing the bitmaps to make sure that other stores before the bit store we check are visible.

I did check a bit around the usage of this method and `is_unavailable`, but I do not think there is a similar issue.

Testing: test crashed with a frequency of around 1/500, now passing 5k runs

Thanks,
  Thomas

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

Commit messages:
 - Add memory barrier

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

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


From ayang at openjdk.java.net  Wed Nov 10 09:35:55 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 10 Nov 2021 09:35:55 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase
Message-ID: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>

Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.

Test: hotspot_gc

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

Commit messages:
 - preclean

Changes: https://git.openjdk.java.net/jdk/pull/6327/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6327&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276887
  Stats: 189 lines in 6 files changed: 38 ins; 128 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6327.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6327/head:pull/6327

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


From ayang at openjdk.java.net  Wed Nov 10 09:59:54 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 10 Nov 2021 09:59:54 GMT
Subject: RFR: 8276932: G1: Annotate methods with override explicitly in
 g1CollectedHeap.hpp
Message-ID: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>

This PR consists of two commits: the first commit is generated using `clang-tidy --fix src/hotspot/share/gc/g1/g1CollectedHeap.hpp -checks=modernize-use-override -p build/linux-x64-debug`, and the second commit fixes some indentation issues.

Test: build

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

Commit messages:
 - indent
 - override

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

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


From sjohanss at openjdk.java.net  Wed Nov 10 10:26:39 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Nov 2021 10:26:39 GMT
Subject: RFR: 8272170: Missing memory barrier when checking active state
 for regions
In-Reply-To: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
References: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
Message-ID: <wgKqyHqTI8QQueAmh59tBh15y5lsanSpNpigWowytmU=.75d48309-e4de-4a1d-91a3-456573df3dde@github.com>

On Wed, 10 Nov 2021 08:37:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this fix to memory visibility race where we miss to make sure that the `HeapRegion` pointer in `HeapRegionManager::_regions` is visible before the "active"-check for that `HeapRegion` can return true?
> 
> I.e. the problem is this (according to my understanding):
> 
> void HeapRegionManager::expand(uint start, uint num_regions, WorkerThreads* pretouch_workers) {
>   commit_regions(start, num_regions, pretouch_workers);
>   for (uint i = start; i < start + num_regions; i++) {
>     HeapRegion* hr = _regions.get_by_index(i);
>     if (hr == NULL) {
>       hr = new_heap_region(i);
>       OrderAccess::storestore();
>       _regions.set_by_index(i, hr);
>       _allocated_heapregions_length = MAX2(_allocated_heapregions_length, i + 1);
>     }
>     G1CollectedHeap::heap()->hr_printer()->commit(hr);
>   }
>   activate_regions(start, num_regions);
> }
> 
> E.g. we first commit the memory, then create a `HeapRegion` instance which we properly guard with a `StoreStore` before assigning it to the `_regions` array. After that at the end we activate the regions (via `activate_regions`), meaning that the contents of the new `HeapRegion*` in the region table are valid.
> These bits in the `_active_regions` bitmap are put with memory barriers (via `par_set_range`).
> 
> In `HeapRegionManager::par_iterate`, if we iterate over the region map, we first check whether the region is available in the `_active_regions` bitmap, and then get and pass on the corresponding `HeapRegion*` to the given closure.
> 
> However there is no memory ordering between reading the available-bit in the `_active_regions` bitmap, so that bit could become visible to the thread iterating over the regions before the contents of the `_region` map itself, in effect passing a `nullptr` to the closure which isn't allowed. (Some details about the debugging session in the CR).
> 
> 
> void HeapRegionManager::par_iterate(HeapRegionClosure* blk, HeapRegionClaimer* hrclaimer, const uint start_index) const {
>   // Every worker will actually look at all regions, skipping over regions that
>   // are currently not committed.
>   // This also (potentially) iterates over regions newly allocated during GC. This
>   // is no problem except for some extra work.
>   const uint n_regions = hrclaimer->n_regions();
>   for (uint count = 0; count < n_regions; count++) {
>     const uint index = (start_index + count) % n_regions;
>     assert(index < n_regions, "sanity");
>     // Skip over unavailable regions
>     if (!is_available(index)) {
>       continue;
>     }
>     HeapRegion* r = _regions.get_by_index(index);
> [...]
>     bool res = blk->do_heap_region(r);
>     if (res) {
>       return;
>     }
>   }
> }
> 
> 
> The suggested fix is to ensure proper memory ordering in `is_available`, i.e. an acquire when accessing the bitmaps to make sure that other stores before the bit store we check are visible.
> 
> I did check a bit around the usage of this method and `is_unavailable`, but I do not think there is a similar issue.
> 
> Testing: test crashed with a frequency of around 1/500, now passing 5k runs
> 
> Thanks,
>   Thomas

Looks good, nice debugging!

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

Marked as reviewed by sjohanss (Reviewer).

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


From pliden at openjdk.java.net  Wed Nov 10 10:42:38 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 10 Nov 2021 10:42:38 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v2]
In-Reply-To: <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
 <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>
Message-ID: <0PTfIjFSbLpSU_hUZcSJ52sYuhBMXN9_TTs3QuSxkOs=.4914ecc9-7e61-4b28-b610-2f34c3b3ab0f@github.com>

On Tue, 9 Nov 2021 14:29:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
>> 
>> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by pliden (Reviewer).

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

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


From sjohanss at openjdk.java.net  Wed Nov 10 10:57:58 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Nov 2021 10:57:58 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
Message-ID: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>

Please review this change that removes some code that is no longer needed.

**Summary**
In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.

This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.

**Testing**

- [x] Mach5 1-3
- [x] Local stress-testing

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

Commit messages:
 - 8276229: Stop allowing implicit updates in G1BlockOffsetTable

Changes: https://git.openjdk.java.net/jdk/pull/6332/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6332&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276229
  Stats: 95 lines in 4 files changed: 8 ins; 81 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6332.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6332/head:pull/6332

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


From shade at openjdk.java.net  Wed Nov 10 11:45:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 11:45:12 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v3]
In-Reply-To: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
Message-ID: <LtX7nhwQ90JnH-sgB23uAxLFUqhC0ymUGVrBQ2ym-Lc=.436ed62c-6ad0-4d6a-98dd-4c35f83c1ef3@github.com>

> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
> 
> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)

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

 - Merge branch 'master' into JDK-8276796-zgc-systemgc
 - Review comments
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6310/files
  - new: https://git.openjdk.java.net/jdk/pull/6310/files/15170896..21728b94

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

  Stats: 2906 lines in 76 files changed: 1432 ins; 1293 del; 181 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6310.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6310/head:pull/6310

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


From shade at openjdk.java.net  Wed Nov 10 11:45:16 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 11:45:16 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v2]
In-Reply-To: <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
 <FRax85e_dM5Gs6Opw81bj74_Z52tBwsGaNVIphM6Unw=.db2b9971-850c-4a6f-b88d-a4ed425f025c@github.com>
Message-ID: <EPqQWoq__w_J5sS4mNQ-ya0FMic1B5z-C9S_qJd0w6U=.344aaabf-82f9-46b8-83f1-faaba619c23f@github.com>

On Tue, 9 Nov 2021 14:29:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
>> 
>> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks for reviews. I'll do another merge to pick up Windows x86_64 GHA fixes to make sure this still works properly on Windows, and then push.

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

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


From tschatzl at openjdk.java.net  Wed Nov 10 12:02:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 12:02:39 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
Message-ID: <drneYv0FeEgd70JpHlcIkAFOsq3Zi11ixoMatRp5E0Q=.6c935f3a-a2b0-4cd5-8cb6-82b323896b61@github.com>

On Wed, 10 Nov 2021 10:48:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change that removes some code that is no longer needed.
> 
> **Summary**
> In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.
> 
> This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.
> 
> **Testing**
> 
> - [x] Mach5 1-3
> - [x] Local stress-testing

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 147:

> 145:     assert(_bot->index_for(n) == _bot->index_for(addr),
> 146:            "BOT not precise. Index for n: " SIZE_FORMAT " must be equal to the index for addr: " SIZE_FORMAT,
> 147:            _bot->index_for(n), _bot->index_for(addr));

I think this method is unnecessary, and always returns `q`. In `block_start()`, the only caller afaics, we already made sure that `addr` is < `top()`, i.e. we always ever ask for addresses where the BOT is complete.
For a complete BOT, 

  HeapWord* q = block_at_or_preceding(addr);
  HeapWord* n = q + block_size(q);

`q` is necessarily the closest start of the block, and `n` always > `addr`.
It would be different if `block_start` allowed queries after `top`, then we would need to skip at most one block as mentioned in the comment, but then I'd just write:
``` if (addr >= top()) { return _top; }```

Unless I'm missing something crucial here?

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

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


From tschatzl at openjdk.java.net  Wed Nov 10 12:05:40 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 12:05:40 GMT
Subject: RFR: 8276932: G1: Annotate methods with override explicitly in
 g1CollectedHeap.hpp
In-Reply-To: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
References: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
Message-ID: <7gsLaF6ervXLet-iEDQgODQLTQscP5zIskwWonAc9KI=.bdebffd9-bd72-408f-995e-f25e2d397599@github.com>

On Wed, 10 Nov 2021 09:51:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits: the first commit is generated using `clang-tidy --fix src/hotspot/share/gc/g1/g1CollectedHeap.hpp -checks=modernize-use-override -p build/linux-x64-debug`, and the second commit fixes some indentation issues.
> 
> Test: build

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Nov 10 12:20:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 12:20:38 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
Message-ID: <qLZ9b5MRpHR67h5ywZJpUiJ0bm-iF7oGoL71S6vE-IY=.deac2f5e-28c3-40d0-80db-d74ac44505b6@github.com>

On Mon, 8 Nov 2021 03:12:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1BufferListFreeMemoryTask.hpp line 36:

> 34: 
> 35: // Task handling deallocation of free card set memory.
> 36: class G1BufferListFreeMemoryTask : public G1ServiceTask {

Comment needs to be adapted.

src/hotspot/share/gc/g1/g1BufferListFreeMemoryTask.hpp line 57:

> 55: 
> 56:   // Current total card set memory usage.
> 57:   G1BufferListMemoryStats _total_used;

Comment mentions "card set"

src/hotspot/share/gc/g1/g1BufferListFreePool.cpp line 114:

> 112:   _first = cur;
> 113: 
> 114:   log_trace(gc, task)("Card Set Free Memory: Returned to VM %zu buffers size %zu", keep_num, keep_size);

"Card Set"

src/hotspot/share/gc/g1/g1BufferListFreePool.hpp line 58:

> 56: 
> 57: // A set of free lists holding memory buffers for use by G1CardSetAllocators.
> 58: template<MEMFLAGS flag>

G1CardSetAllocators

src/hotspot/share/gc/g1/g1BufferListFreePool.hpp line 59:

> 57: // A set of free lists holding memory buffers for use by G1CardSetAllocators.
> 58: template<MEMFLAGS flag>
> 59: class G1BufferListFreePool {

I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long).
I think there is already a CR to reconsider naming of all these classes, maybe add `G1SegmentedArrayBufferList` to the ones that need renaming; in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant.
Sorry for not speaking up earlier about this, but it only came to my mind right now.

It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames. Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.

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

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


From tschatzl at openjdk.java.net  Wed Nov 10 12:29:40 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 12:29:40 GMT
Subject: RFR: 8276835: G1: make G1EvacFailureObjectsSet::record inline
In-Reply-To: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
References: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
Message-ID: <VFynjhY7SGVRkXNvZdtK9or27fLsrGbkY9Hs2VZuwnA=.f1a418d1-9c5c-4305-80d6-cc3d2f76a12c@github.com>

On Wed, 10 Nov 2021 05:46:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement to make G1EvacFailureObjectsSet::record inline, which was not.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Nov 10 12:35:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 12:35:37 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase
In-Reply-To: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
Message-ID: <pBH528WPdKolb-A3becdNi0lEbTjes1aXmpKmtZQjKc=.1e3b6f6f-9029-4745-9423-e34087bc2188@github.com>

On Wed, 10 Nov 2021 09:28:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From rkennke at openjdk.java.net  Wed Nov 10 12:52:08 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 10 Nov 2021 12:52:08 GMT
Subject: RFR: 8275527: Refactor forward pointer access [v5]
In-Reply-To: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
Message-ID: <Go6Jy3r74trkRi0_l3mXStP7uky_iN4C6Q3SF5fmkvE=.d754aa25-b4a8-4da0-a9b3-978616814577@github.com>

> Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.
> 
> This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.
> 
> Testing:
>  - [x] tier
>  - [x] tier2
>  - [x] hotspot_gc

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

 - Merge branch 'master' into optimize-fwdptr
 - Don't use forwarded terminology in markWord
 - Move forward impl into markWord and add assert
 - Fix Parallel GC mistake
 - Revert unnecessary changes
 - Update some copyright headers
 - Add missing includes
 - Merge branch 'master' into optimize-fwdptr
 - Add missing includes
 - Rename mwd -> fwd
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a0b84453...d63962a3

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

Changes: https://git.openjdk.java.net/jdk/pull/5955/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=04
  Stats: 46 lines in 9 files changed: 4 ins; 26 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5955.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955

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


From rkennke at openjdk.java.net  Wed Nov 10 12:52:13 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 10 Nov 2021 12:52:13 GMT
Subject: RFR: 8275527: Refactor forward pointer access [v4]
In-Reply-To: <L12GPa4-qxtJlMxtEOEpiVc4v1TJ_-DwFqC5DWOarI4=.35af6235-3555-41e6-b0c6-67e011a83829@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
 <tu8-LJVLLI-0yU9Fsvdnqkx9sTkfarZu3XNIElJ0kak=.6c3578d7-0a9a-447e-a167-27c412ac200f@github.com>
 <L12GPa4-qxtJlMxtEOEpiVc4v1TJ_-DwFqC5DWOarI4=.35af6235-3555-41e6-b0c6-67e011a83829@github.com>
Message-ID: <SGF7uMA7SPhrRgfwADj4Zzge8NjfF5Gc2V4gzYt8JFo=.fd35c039-67b3-4539-824e-281671e2ffef@github.com>

On Mon, 1 Nov 2021 09:25:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move forward impl into markWord and add assert
>
> src/hotspot/share/oops/markWord.hpp line 253:
> 
>> 251:     return cast_to_oop(decode_pointer());
>> 252:   }
>> 253: };
> 
> This brings the forwarded/forwardee terminology into the markWord. The markWord was previously decoupled from those to concepts. I would personally let those function names stay in oopDesc and not leak down into the markWord. If you do want to keep it here, could you update the comments at the top that describes the bits?
> 
> //    [ptr             | 11]  marked             used to mark an object

Yeah, I am not quite sure about this. We have a couple of places where we need to use the markWord direcly, and they read m.is_marked() (when it really means is_forwarded, even though it's the same in the implementation), and then goes on to cast_to_oop(m.decode_pointer()) which reads more ugly than simply m.forwardee() which also comes with an assert and the cast.

I reverted the markWord change and related call-sites now. Maybe this warrants more thinking/discussion.

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

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


From zgu at openjdk.java.net  Wed Nov 10 13:11:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 13:11:37 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
Message-ID: <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>

On Tue, 9 Nov 2021 17:33:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> Zhengyu Gu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert assertion for unregister_nmethod
>  - Fix comment as Aleksey suggested

> I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?

It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81) although previous version passed GHA

I will take a further look in separate CR see if we can cleanup a bit.

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

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


From sjohanss at openjdk.java.net  Wed Nov 10 13:25:41 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Nov 2021 13:25:41 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <drneYv0FeEgd70JpHlcIkAFOsq3Zi11ixoMatRp5E0Q=.6c935f3a-a2b0-4cd5-8cb6-82b323896b61@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
 <drneYv0FeEgd70JpHlcIkAFOsq3Zi11ixoMatRp5E0Q=.6c935f3a-a2b0-4cd5-8cb6-82b323896b61@github.com>
Message-ID: <WjnmRqYftn73T4-42ZsCw6JTJSqfX6cK8vd-lJyHyEo=.793050d7-5249-4287-9f69-d1378d7f7fed@github.com>

On Wed, 10 Nov 2021 11:58:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change that removes some code that is no longer needed.
>> 
>> **Summary**
>> In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.
>> 
>> This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.
>> 
>> **Testing**
>> 
>> - [x] Mach5 1-3
>> - [x] Local stress-testing
>
> src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 147:
> 
>> 145:     assert(_bot->index_for(n) == _bot->index_for(addr),
>> 146:            "BOT not precise. Index for n: " SIZE_FORMAT " must be equal to the index for addr: " SIZE_FORMAT,
>> 147:            _bot->index_for(n), _bot->index_for(addr));
> 
> I think this method is unnecessary, and always returns `q`. In `block_start()`, the only caller afaics, we already made sure that `addr` is < `top()`, i.e. we always ever ask for addresses where the BOT is complete.
> For a complete BOT, 
> 
>   HeapWord* q = block_at_or_preceding(addr);
>   HeapWord* n = q + block_size(q);
> 
> `q` is necessarily the closest start of the block, and `n` always > `addr`.
> It would be different if `block_start` allowed queries after `top`, then we would need to skip at most one block as mentioned in the comment, but then I'd just write:
> ``` if (addr >= top()) { return _top; }```
> 
> Unless I'm missing something crucial here?

You're missing the case where `addr` is not covered by the first object ("block") in the card. So when asking for `block_at_or_preciding(addr)` we get an object that is stretching into the card same card as `addr` map to, but it is not certain that it is the object containing `addr`.

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

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


From sjohanss at openjdk.java.net  Wed Nov 10 13:25:42 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Nov 2021 13:25:42 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <WjnmRqYftn73T4-42ZsCw6JTJSqfX6cK8vd-lJyHyEo=.793050d7-5249-4287-9f69-d1378d7f7fed@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
 <drneYv0FeEgd70JpHlcIkAFOsq3Zi11ixoMatRp5E0Q=.6c935f3a-a2b0-4cd5-8cb6-82b323896b61@github.com>
 <WjnmRqYftn73T4-42ZsCw6JTJSqfX6cK8vd-lJyHyEo=.793050d7-5249-4287-9f69-d1378d7f7fed@github.com>
Message-ID: <lq8QeULuV1n1keEwWtEpojm0Fdg5ttBCun1Z6UlqxuA=.fee5fae6-ebc7-47df-a19e-3cdb342f638d@github.com>

On Wed, 10 Nov 2021 13:20:28 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 147:
>> 
>>> 145:     assert(_bot->index_for(n) == _bot->index_for(addr),
>>> 146:            "BOT not precise. Index for n: " SIZE_FORMAT " must be equal to the index for addr: " SIZE_FORMAT,
>>> 147:            _bot->index_for(n), _bot->index_for(addr));
>> 
>> I think this method is unnecessary, and always returns `q`. In `block_start()`, the only caller afaics, we already made sure that `addr` is < `top()`, i.e. we always ever ask for addresses where the BOT is complete.
>> For a complete BOT, 
>> 
>>   HeapWord* q = block_at_or_preceding(addr);
>>   HeapWord* n = q + block_size(q);
>> 
>> `q` is necessarily the closest start of the block, and `n` always > `addr`.
>> It would be different if `block_start` allowed queries after `top`, then we would need to skip at most one block as mentioned in the comment, but then I'd just write:
>> ``` if (addr >= top()) { return _top; }```
>> 
>> Unless I'm missing something crucial here?
>
> You're missing the case where `addr` is not covered by the first object ("block") in the card. So when asking for `block_at_or_preciding(addr)` we get an object that is stretching into the card same card as `addr` map to, but it is not certain that it is the object containing `addr`.

My initial thought was also that this should not be needed, but the code proved me wrong. It might be possible to refactor the code even further to avoid this case.

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

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


From ayang at openjdk.java.net  Wed Nov 10 13:40:09 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 10 Nov 2021 13:40:09 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v2]
In-Reply-To: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
Message-ID: <xNTKen0Q_yUjXSsQpDrtgNU8bFJBE0AS9chWVG0eBqI=.2d8e6d63-29cc-4598-b105-6631f6ea5538@github.com>

> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
> 
> Test: hotspot_gc

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

  worker_id

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6327/files
  - new: https://git.openjdk.java.net/jdk/pull/6327/files/a0cd3dc0..0841db5c

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

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

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


From tschatzl at openjdk.java.net  Wed Nov 10 13:48:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 13:48:33 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
Message-ID: <IClHlaYIdHNm_9a3S8vYV5Fan5JKblv0q2iQk2KOdeA=.0f65360f-27de-45de-9d66-e9dbcf9e23c7@github.com>

On Wed, 10 Nov 2021 10:48:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change that removes some code that is no longer needed.
> 
> **Summary**
> In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.
> 
> This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.
> 
> **Testing**
> 
> - [x] Mach5 1-3
> - [x] Local stress-testing

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Nov 10 13:48:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 10 Nov 2021 13:48:33 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <lq8QeULuV1n1keEwWtEpojm0Fdg5ttBCun1Z6UlqxuA=.fee5fae6-ebc7-47df-a19e-3cdb342f638d@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
 <drneYv0FeEgd70JpHlcIkAFOsq3Zi11ixoMatRp5E0Q=.6c935f3a-a2b0-4cd5-8cb6-82b323896b61@github.com>
 <WjnmRqYftn73T4-42ZsCw6JTJSqfX6cK8vd-lJyHyEo=.793050d7-5249-4287-9f69-d1378d7f7fed@github.com>
 <lq8QeULuV1n1keEwWtEpojm0Fdg5ttBCun1Z6UlqxuA=.fee5fae6-ebc7-47df-a19e-3cdb342f638d@github.com>
Message-ID: <ZQ0waaUfsWK_0pZKQkzvCFdc-YS31Rj0TzI4MjqgVCo=.a201fcb5-da93-4da1-abd8-7c4283ad0da1@github.com>

On Wed, 10 Nov 2021 13:22:25 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> You're missing the case where `addr` is not covered by the first object ("block") in the card. So when asking for `block_at_or_preciding(addr)` we get an object that is stretching into the card same card as `addr` map to, but it is not certain that it is the object containing `addr`.
>
> My initial thought was also that this should not be needed, but the code proved me wrong. It might be possible to refactor the code even further to avoid this case.

Okay, understood. I have been too fixated on the case with remembered sets to disregard other cases, looking at the code I even found interesting ones :)

           card1       card2
   -----+----------+----------+---------
       A|AAABBBCCCD|DDD       |
   -----+----------+----------+---------
       ^    ^  ^
       q    n  addr
```   
Something like this: we get asked by `addr` somewhere in card card1, `block_preceeding_addr(addr)` is `q` and `n` is the end of the block.

Agree, then the code (and the comment) is correct.

Maybe it is really worth to optimize the card scanning case.

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

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


From sjohanss at openjdk.java.net  Wed Nov 10 13:48:33 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 10 Nov 2021 13:48:33 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <ZQ0waaUfsWK_0pZKQkzvCFdc-YS31Rj0TzI4MjqgVCo=.a201fcb5-da93-4da1-abd8-7c4283ad0da1@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
 <drneYv0FeEgd70JpHlcIkAFOsq3Zi11ixoMatRp5E0Q=.6c935f3a-a2b0-4cd5-8cb6-82b323896b61@github.com>
 <WjnmRqYftn73T4-42ZsCw6JTJSqfX6cK8vd-lJyHyEo=.793050d7-5249-4287-9f69-d1378d7f7fed@github.com>
 <lq8QeULuV1n1keEwWtEpojm0Fdg5ttBCun1Z6UlqxuA=.fee5fae6-ebc7-47df-a19e-3cdb342f638d@github.com>
 <ZQ0waaUfsWK_0pZKQkzvCFdc-YS31Rj0TzI4MjqgVCo=.a201fcb5-da93-4da1-abd8-7c4283ad0da1@github.com>
Message-ID: <9PbykuNy9lXYpnI-hy7kiohjgzbqQPNmQJs8RJmg4Ng=.73f1803d-c0c4-4507-9de3-5860f80b7dd2@github.com>

On Wed, 10 Nov 2021 13:41:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> My initial thought was also that this should not be needed, but the code proved me wrong. It might be possible to refactor the code even further to avoid this case.
>
> Okay, understood. I have been too fixated on the case with remembered sets to disregard other cases, looking at the code I even found interesting ones :)
> 
>            card1       card2
>    -----+----------+----------+---------
>        A|AAABBBCCCD|DDD       |
>    -----+----------+----------+---------
>        ^    ^  ^
>        q    n  addr
> ```   
> Something like this: we get asked by `addr` somewhere in card card1, `block_preceeding_addr(addr)` is `q` and `n` is the end of the block.
> 
> Agree, then the code (and the comment) is correct.
> 
> Maybe it is really worth to optimize the card scanning case.

Yes, if we can avoid doing the call to `block_start()` when we know we have a valid object start that could be a nice optimization.

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

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


From ayang at openjdk.java.net  Wed Nov 10 15:53:31 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 10 Nov 2021 15:53:31 GMT
Subject: RFR: 8276835: G1: make G1EvacFailureObjectsSet::record inline
In-Reply-To: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
References: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
Message-ID: <WE-Qg2wlPz6kCWLnQVxEGVd2HyIsHH_NBixfC_anJS0=.2853358a-4a3b-43ec-9929-362a8540abe3@github.com>

On Wed, 10 Nov 2021 05:46:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement to make G1EvacFailureObjectsSet::record inline, which was not.

Marked as reviewed by ayang (Reviewer).

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

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


From shade at openjdk.java.net  Wed Nov 10 17:00:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 17:00:36 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
 <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>
Message-ID: <N6_Gr8UrKzkJ2qEgGpZENvKiqa0FY0a9gW_MMnGR5EQ=.c70d4bde-23c0-4a1f-93a9-421957e82171@github.com>

On Wed, 10 Nov 2021 13:08:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?
> 
> It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81)
> 
> I will take a further look in separate CR see if we can cleanup a bit.

Why further CR, though? I think current code is guaranteed to fail that new assert during STW unloading? If so, we need to keep `assert_locked_or_safepoint` intact.

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

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


From zgu at openjdk.java.net  Wed Nov 10 17:14:06 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 17:14:06 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v3]
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <UJk--2pUUeXFFjB_CrbrwMwRnI3bAFi9uJ6Lj3-0_CU=.ad036882-4d8f-4dd2-9d06-d3f357fd6c80@github.com>

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

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

  Fixed incomplete inversion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6316/files
  - new: https://git.openjdk.java.net/jdk/pull/6316/files/0248f1e4..8e07b342

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

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

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


From zgu at openjdk.java.net  Wed Nov 10 17:14:07 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 17:14:07 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v2]
In-Reply-To: <N6_Gr8UrKzkJ2qEgGpZENvKiqa0FY0a9gW_MMnGR5EQ=.c70d4bde-23c0-4a1f-93a9-421957e82171@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <rfq-ZmGS6rHolJ8YnCWCrMnt-JIT5yxDABtiZFM0XK4=.2cef60fe-6176-4751-a013-70df51359bc8@github.com>
 <6sMmRbfDTxgONEl1djzwudJi3V9Pnk58k3Vhbzvi5pc=.9a284d53-7ba5-4f61-a89b-5f644cc006aa@github.com>
 <N6_Gr8UrKzkJ2qEgGpZENvKiqa0FY0a9gW_MMnGR5EQ=.c70d4bde-23c0-4a1f-93a9-421957e82171@github.com>
Message-ID: <PD3iZQR0qtO0qWcmnlDDEkDS2Nq6Pyhta6Zy28X41i0=.d721ccdb-2032-43bc-92f8-866c188e73f6@github.com>

On Wed, 10 Nov 2021 16:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > I still do not understand about `ShenandoahCodeRoots::unregister_nmethod` here. You seem to have restored the assert in the nmethod-table ([0248f1e](https://github.com/openjdk/jdk/commit/0248f1e4cd6a8311f0532c637a31bd71c9041451)), but surely the assert `ShenandoahCodeRoots::unregister_nmethod` can also be called at safepoint without `CodeCache_lock` held?
> > 
> > 
> > It seems possible during [STW unloading](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/parallelCleaning.cpp#L81)
> > I will take a further look in separate CR see if we can cleanup a bit.
> 
> Why further CR, though? I think current code is guaranteed to fail that new assert during STW unloading? If so, we need to keep `assert_locked_or_safepoint` intact.

Oops, misread you comments. Previous reversion of the assertion was incomplete. Updated.

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

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


From zgu at openjdk.java.net  Wed Nov 10 17:19:55 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 10 Nov 2021 17:19:55 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v4]
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <ty4aZ5Sv0mln8CdyzTLbUAwLE8YqHXHpkA77rNwvK_M=.7ae8c23f-4587-4204-a579-fa884279bc5d@github.com>

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

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

  Reverted wrong method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6316/files
  - new: https://git.openjdk.java.net/jdk/pull/6316/files/8e07b342..0a2ef517

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

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

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


From shade at openjdk.java.net  Wed Nov 10 17:19:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 10 Nov 2021 17:19:56 GMT
Subject: RFR: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah [v3]
In-Reply-To: <UJk--2pUUeXFFjB_CrbrwMwRnI3bAFi9uJ6Lj3-0_CU=.ad036882-4d8f-4dd2-9d06-d3f357fd6c80@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
 <UJk--2pUUeXFFjB_CrbrwMwRnI3bAFi9uJ6Lj3-0_CU=.ad036882-4d8f-4dd2-9d06-d3f357fd6c80@github.com>
Message-ID: <TLxzl9pEkjRnkPhrL-9sclBL5UjfcBey2-E3x2jCgJA=.812ecb72-5b31-469d-8328-cc5871930f43@github.com>

On Wed, 10 Nov 2021 17:14:06 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
>> 
>> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] Stress test on gc/stress/CriticalNativeStress.java
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed incomplete inversion

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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


From ayang at openjdk.java.net  Wed Nov 10 21:09:10 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 10 Nov 2021 21:09:10 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
Message-ID: <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>

> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:

 - review
 - Revert "worker_id"
   
   This reverts commit 0841db5c5c2b39372058b6ba0d8027aae3716669.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6327/files
  - new: https://git.openjdk.java.net/jdk/pull/6327/files/0841db5c..f73a6db5

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

  Stats: 33 lines in 3 files changed: 16 ins; 5 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6327.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6327/head:pull/6327

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


From ayang at openjdk.java.net  Wed Nov 10 21:11:34 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 10 Nov 2021 21:11:34 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v2]
In-Reply-To: <xNTKen0Q_yUjXSsQpDrtgNU8bFJBE0AS9chWVG0eBqI=.2d8e6d63-29cc-4598-b105-6631f6ea5538@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <xNTKen0Q_yUjXSsQpDrtgNU8bFJBE0AS9chWVG0eBqI=.2d8e6d63-29cc-4598-b105-6631f6ea5538@github.com>
Message-ID: <9T-H-jhL1NspQL1zEKQ9wnSKxRTvyF-Ln55I7LFw-jc=.0a951bf7-1c59-4877-aa1c-de6f9cc924b0@github.com>

On Wed, 10 Nov 2021 13:40:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   worker_id

In the initial patch, the case `ConcGCThreads=1 && ParallelGCThreads>1` is not properly handle. The latest commit fixes that by calling `get_discovered_list` multiple times when the discovery is single-threaded.

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

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


From zgu at openjdk.java.net  Thu Nov 11 00:18:42 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 11 Nov 2021 00:18:42 GMT
Subject: Integrated: 8276801: gc/stress/CriticalNativeStress.java fails
 intermittently with Shenandoah
In-Reply-To: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
References: <lDFmF7RlmRPvI6RdWHBLcyIe_prgkVD4rKlX8FO4AyY=.4da36614-faac-4de5-9345-a4d9dee2e5d3@github.com>
Message-ID: <ypUNyO8XV3WLEVb4nuEzVHGpK1bl_Yja1sMPAieA0Hg=.5b4a3678-00a5-4b79-9a28-372bab1747cf@github.com>

On Tue, 9 Nov 2021 15:08:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8276205 fixed a bug that prevents concurrent code cache iteration, without holding CodeCache_lock. That causes register_nmethod() calls can go through during concurrent code cache iteration.
> 
> This is no a problem for new nmethod, cause it is *not* in cache cache snapshot for concurrent code cache iteration, but *nmethod patching* is. We can not allow *nmethod patching* during concurrent code cache iteration, should block it until iteration is completed.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] Stress test on gc/stress/CriticalNativeStress.java

This pull request has now been integrated.

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

8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah

Reviewed-by: shade

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

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


From mli at openjdk.java.net  Thu Nov 11 05:56:42 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 11 Nov 2021 05:56:42 GMT
Subject: RFR: 8276835: G1: make G1EvacFailureObjectsSet::record inline
In-Reply-To: <VFynjhY7SGVRkXNvZdtK9or27fLsrGbkY9Hs2VZuwnA=.f1a418d1-9c5c-4305-80d6-cc3d2f76a12c@github.com>
References: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
 <VFynjhY7SGVRkXNvZdtK9or27fLsrGbkY9Hs2VZuwnA=.f1a418d1-9c5c-4305-80d6-cc3d2f76a12c@github.com>
Message-ID: <slYwm1WNeXmAmo0HoQGdiQ4mQsZbtQ_WbHdJjL3U5qs=.9a98c444-921c-41b4-bbf0-d5f2026021bd@github.com>

On Wed, 10 Nov 2021 12:27:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This is a minor improvement to make G1EvacFailureObjectsSet::record inline, which was not.
>
> Lgtm.

Thansk @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Thu Nov 11 05:56:43 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 11 Nov 2021 05:56:43 GMT
Subject: Integrated: 8276835: G1: make G1EvacFailureObjectsSet::record inline
In-Reply-To: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
References: <Y8ncdq2P-XTjVVjHgn45LNjchBmr46Uc0RQ8O7tsApU=.608999a3-c82f-4566-af1e-047c993ca475@github.com>
Message-ID: <6hmUtJtwoa5UaiKZYNJWht1cDukxymf6kwaoui10alI=.6d1ccf6c-1576-41e3-926c-d862a5fe0ad8@github.com>

On Wed, 10 Nov 2021 05:46:03 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement to make G1EvacFailureObjectsSet::record inline, which was not.

This pull request has now been integrated.

Changeset: 08e0fd67
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08e0fd6757ef15b71df0e86afd01211a6e48bd09
Stats:     50 lines in 4 files changed: 41 ins; 8 del; 1 mod

8276835: G1: make G1EvacFailureObjectsSet::record inline

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Thu Nov 11 06:24:36 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 11 Nov 2021 06:24:36 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <qLZ9b5MRpHR67h5ywZJpUiJ0bm-iF7oGoL71S6vE-IY=.deac2f5e-28c3-40d0-80db-d74ac44505b6@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
 <qLZ9b5MRpHR67h5ywZJpUiJ0bm-iF7oGoL71S6vE-IY=.deac2f5e-28c3-40d0-80db-d74ac44505b6@github.com>
Message-ID: <lc6I54KGniBHMcIO7YetdiUYSaQDS-yw6Y4xB-r5bAo=.946b49df-0353-4e4c-a43f-e7602b2b5eb0@github.com>

On Wed, 10 Nov 2021 12:15:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> src/hotspot/share/gc/g1/g1BufferListFreePool.hpp line 59:
> 
>> 57: // A set of free lists holding memory buffers for use by G1CardSetAllocators.
>> 58: template<MEMFLAGS flag>
>> 59: class G1BufferListFreePool {
> 
> I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long).
> I think there is already a CR to reconsider naming of all these classes, maybe add `G1SegmentedArrayBufferList` to the ones that need renaming; in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant.
> Sorry for not speaking up earlier about this, but it only came to my mind right now.
> 
> It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames. Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.

Thanks Thomas.

> I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long). 

Sure.

> I think there is already a CR to reconsider naming of all these classes, 

Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?

> maybe add `G1SegmentedArrayBufferList` to the ones that need renaming; 

If you mean 8276299 above, sure I will add this to the renaming list of 8276299.

> in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant. 

Not quite get your point, would you mind to clarify further?

> Sorry for not speaking up earlier about this, but it only came to my mind right now.

It's OK, it's never late to make necessary changes. :)

> It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames. 

Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?

> Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.

If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool.
Sure, I will start a discussion for 8276299 before actually send the pr.

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

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


From shade at openjdk.java.net  Thu Nov 11 07:11:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Nov 2021 07:11:41 GMT
Subject: RFR: 8276796: gc/TestSystemGC.java large pages subtest fails with
 ZGC [v3]
In-Reply-To: <LtX7nhwQ90JnH-sgB23uAxLFUqhC0ymUGVrBQ2ym-Lc=.436ed62c-6ad0-4d6a-98dd-4c35f83c1ef3@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
 <LtX7nhwQ90JnH-sgB23uAxLFUqhC0ymUGVrBQ2ym-Lc=.436ed62c-6ad0-4d6a-98dd-4c35f83c1ef3@github.com>
Message-ID: <rUwzfFT7bHVDjsbi-Q_Xc3xK1fcHuYPcvlnFeYghn2M=.191cf497-d84c-475e-a08b-aae4f763e67c@github.com>

On Wed, 10 Nov 2021 11:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
>> 
>> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8276796-zgc-systemgc
>  - Review comments
>  - Fix

GHA tests are green.

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

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


From shade at openjdk.java.net  Thu Nov 11 07:11:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 11 Nov 2021 07:11:42 GMT
Subject: Integrated: 8276796: gc/TestSystemGC.java large pages subtest fails
 with ZGC
In-Reply-To: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
References: <ptvLwyu5mLlPAf1srFf7wf5Bliv9vJHJ7Cw176o9wto=.67a1f18c-2585-429e-9448-ad382e617b90@github.com>
Message-ID: <fj3kY2drPqbarptdqbbaedwDDhC0GrHCkzDng7p4xvc=.7400fc9b-2e5c-4b9b-b05c-b675667388fa@github.com>

On Tue, 9 Nov 2021 12:09:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> ZGC would not start when it cannot allocate the heap with `-XX:+UseLargePages`. This makes the `UseLargePages` subtest fail on systems with (default) `nr_hugepages = 0`. It was exposed after [JDK-8269077](https://bugs.openjdk.java.net/browse/JDK-8269077) moved that test config from G1-specific to generic one.
> 
> While fixing this bug, I decided to massage a test a bit: make it consistently choosing the configuration based on GC availability, doing `UseLargePages` tests only for GCs that fall back to non-large pages if not available, added test IDs. This basically goes the other way JDK-8269077 went: put in the GC-specific configs.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java` (runs all 5 configs)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseSerialGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseParallelGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseG1GC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseShenandoahGC` (runs 1 config)
>  - [x] Linux x86_64 fastdebug, `gc/TestSystemGC.java`, `TEST_VM_OPTS=-XX:+UseZGC` (runs 1 config)

This pull request has now been integrated.

Changeset: 91bb0d65
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/91bb0d658bce010e74b248b56f0fa5b8a79e8802
Stats:     15 lines in 1 file changed: 7 ins; 0 del; 8 mod

8276796: gc/TestSystemGC.java large pages subtest fails with ZGC

Reviewed-by: pliden, stefank

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

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


From tschatzl at openjdk.java.net  Thu Nov 11 09:11:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 11 Nov 2021 09:11:33 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <lc6I54KGniBHMcIO7YetdiUYSaQDS-yw6Y4xB-r5bAo=.946b49df-0353-4e4c-a43f-e7602b2b5eb0@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
 <qLZ9b5MRpHR67h5ywZJpUiJ0bm-iF7oGoL71S6vE-IY=.deac2f5e-28c3-40d0-80db-d74ac44505b6@github.com>
 <lc6I54KGniBHMcIO7YetdiUYSaQDS-yw6Y4xB-r5bAo=.946b49df-0353-4e4c-a43f-e7602b2b5eb0@github.com>
Message-ID: <V_-4d5XrAh-I1CXEs_ZU-7x_HC9-TEOeNQEstKiz3QM=.defe7e45-0daf-4b7c-a922-324bcd189a83@github.com>

On Thu, 11 Nov 2021 06:21:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Thanks Thomas.
> 
> > I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long).
> 
> Sure.
> 
> > I think there is already a CR to reconsider naming of all these classes,
> 
> Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?

Yes.

> 
> > maybe add `G1SegmentedArrayBufferList` to the ones that need renaming;
> 
> If you mean 8276299 above, sure I will add this to the renaming list of 8276299.
> 
> > in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant.
> 
> Not quite get your point, would you mind to clarify further?

A segmented array is an array consisting of segments (as opposed to a single huge array of something); a list of buffers, where a "buffer" is nothing but an array (of some element type) is almost the same. One is a set of chunks of elements (to explicitly use other words), the other too.

> > It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames.
> 
> Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?

Not to discuss the idea of renaming, 8276299 is pretty clear about that, but discuss the actual mappings from old name to new name. Maybe this will wake up more people to the discussion than hiding it in a PR :) 

> 
> > Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.
> 
> If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool. Sure, I will start a discussion for 8276299 before actually send the pr.

That's true, but we are renaming something that also contains a "Buffer" in it and seemingly related.

So instead of renaming this `G1BufferListFreePool` again to something else in 8276299, maybe we could save the time and immediately change it to the final name now, then in 8276299 do the same for the other classes.

Then 8276299 will hopefully go through more smoothly too if we already decided on the new names beforehand as well.

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

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


From mli at openjdk.java.net  Thu Nov 11 09:22:35 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 11 Nov 2021 09:22:35 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <V_-4d5XrAh-I1CXEs_ZU-7x_HC9-TEOeNQEstKiz3QM=.defe7e45-0daf-4b7c-a922-324bcd189a83@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
 <qLZ9b5MRpHR67h5ywZJpUiJ0bm-iF7oGoL71S6vE-IY=.deac2f5e-28c3-40d0-80db-d74ac44505b6@github.com>
 <lc6I54KGniBHMcIO7YetdiUYSaQDS-yw6Y4xB-r5bAo=.946b49df-0353-4e4c-a43f-e7602b2b5eb0@github.com>
 <V_-4d5XrAh-I1CXEs_ZU-7x_HC9-TEOeNQEstKiz3QM=.defe7e45-0daf-4b7c-a922-324bcd189a83@github.com>
Message-ID: <jeLFlNxYO7mfNtVfU_sN7ryNRn0lCfPYlpAQFrYf6ps=.dd29181b-b8f0-4814-aea0-a4c51c1bda38@github.com>

On Thu, 11 Nov 2021 09:08:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Thanks Thomas.
>> 
>>> I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long). 
>> 
>> Sure.
>> 
>>> I think there is already a CR to reconsider naming of all these classes, 
>> 
>> Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?
>> 
>>> maybe add `G1SegmentedArrayBufferList` to the ones that need renaming; 
>> 
>> If you mean 8276299 above, sure I will add this to the renaming list of 8276299.
>> 
>>> in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant. 
>> 
>> Not quite get your point, would you mind to clarify further?
>> 
>>> Sorry for not speaking up earlier about this, but it only came to my mind right now.
>> 
>> It's OK, it's never late to make necessary changes. :)
>> 
>>> It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames. 
>> 
>> Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?
>> 
>>> Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.
>> 
>> If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool.
>> Sure, I will start a discussion for 8276299 before actually send the pr.
>
>> Thanks Thomas.
>> 
>> > I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long).
>> 
>> Sure.
>> 
>> > I think there is already a CR to reconsider naming of all these classes,
>> 
>> Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?
> 
> Yes.
> 
>> 
>> > maybe add `G1SegmentedArrayBufferList` to the ones that need renaming;
>> 
>> If you mean 8276299 above, sure I will add this to the renaming list of 8276299.
>> 
>> > in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant.
>> 
>> Not quite get your point, would you mind to clarify further?
> 
> A segmented array is an array consisting of segments (as opposed to a single huge array of something); a list of buffers, where a "buffer" is nothing but an array (of some element type) is almost the same. One is a set of chunks of elements (to explicitly use other words), the other too.
> 
>> > It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames.
>> 
>> Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?
> 
> Not to discuss the idea of renaming, 8276299 is pretty clear about that, but discuss the actual mappings from old name to new name. Maybe this will wake up more people to the discussion than hiding it in a PR :) 
> 
>> 
>> > Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.
>> 
>> If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool. Sure, I will start a discussion for 8276299 before actually send the pr.
> 
> That's true, but we are renaming something that also contains a "Buffer" in it and seemingly related.
> 
> So instead of renaming this `G1BufferListFreePool` again to something else in 8276299, maybe we could save the time and immediately change it to the final name now, then in 8276299 do the same for the other classes.
> 
> Then 8276299 will hopefully go through more smoothly too if we already decided on the new names beforehand as well.

Thanks for clarification, I see your point, will initiate an discussion later. :)

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

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


From sjohanss at openjdk.java.net  Thu Nov 11 13:10:47 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 11 Nov 2021 13:10:47 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
Message-ID: <ebYH0L2obpJduTn6rQ42Ota5Jdqyk4riVdYyGNPQHFM=.efab44dd-badf-4b6d-b38e-d47c8fe52c98@github.com>

On Wed, 10 Nov 2021 21:09:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - Revert "worker_id"
>    
>    This reverts commit 0841db5c5c2b39372058b6ba0d8027aae3716669.

Nice improvement. I have one suggestion, but feel free to ignore it if you don't agree.

The new logging is on par with the old one, but I think it would be nice to make it more consistent with other reference processing logging. We currently have other logging that look like this for example:

[228,965s][debug][gc,phases,ref  ] GC(38)   SoftReference:
[228,965s][debug][gc,phases,ref  ] GC(38)     Discovered: 0
[228,965s][debug][gc,phases,ref  ] GC(38)     Cleared: 0
[228,965s][debug][gc,phases,ref  ] GC(38)   WeakReference:
[228,965s][debug][gc,phases,ref  ] GC(38)     Discovered: 0
[228,965s][debug][gc,phases,ref  ] GC(38)     Cleared: 0
[228,965s][debug][gc,phases,ref  ] GC(38)   FinalReference:
[228,965s][debug][gc,phases,ref  ] GC(38)     Discovered: 0
[228,965s][debug][gc,phases,ref  ] GC(38)     Cleared: 0
[228,965s][debug][gc,phases,ref  ] GC(38)   PhantomReference:
[228,965s][debug][gc,phases,ref  ] GC(38)     Discovered: 0
[228,965s][debug][gc,phases,ref  ] GC(38)     Cleared: 0


Maybe saying "Precleaned instead of "Cleared". Took a quick look at the ref-printing code and if you feel that this is a good idea but should be as a separate thing I'm good with that as well.

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

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


From sjohanss at openjdk.java.net  Thu Nov 11 14:22:43 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 11 Nov 2021 14:22:43 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
Message-ID: <kFd_ZzguABYwt-kzoTp5ISVnF3IkI-SGjVa5hW4y44U=.9d6e2b33-1cbc-44be-99ec-10efa8d111f3@github.com>

On Wed, 10 Nov 2021 21:09:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - Revert "worker_id"
>    
>    This reverts commit 0841db5c5c2b39372058b6ba0d8027aae3716669.

Approved, suggested improvements to logging will be addressed separately.

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

Marked as reviewed by sjohanss (Reviewer).

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


From pliden at openjdk.java.net  Thu Nov 11 16:06:49 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 11 Nov 2021 16:06:49 GMT
Subject: RFR: 8275329: ZGC:
 vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with
 assert(_phases->length() <= 1000) failed: Too many recored phases?
Message-ID: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>

In ZGC, the phases the "Pause Mark End" and "Concurrent Mark Continue" can be executed multiple times in the same GC cycle. This can happen for two reasons:

1) After "Concurrent Mark Continue" has terminated, but before "Pause Mark End" has started, a `SoftReference` or a `WeakReference` is resurrected by a call to `Reference.get()` from a Java thread.

2) A Java thread "hides" work from the GC worker threads doing marking, by detaching unmarked objects from the graph and push it to a thread local mark stack, that the GC needs to flush out. An example of this is when a Java thread continuously removes the first element in a single linked list that hasn't been marked yet.

The above events are typically rare, but it is possible to write a program that causes the above GC phases to be executed a large number of times. The test that failed (`soft004.java`) runs into case 2 above, where it has ~50,000,000 SoftReferences in the reference processing pending list (a single linked list) and continuously removes the first element until the list if empty. This causes more than 1000 "Pause Mark End" attempt to happen. For that reason, we don't want `TimePartitions` to assert if there are more than 1000 phases. This patch disables the assert in question if ZGC is used. An alternative would be to remove the assert completely, but @stefank preferred to just disable it for ZGC.

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

Commit messages:
 - 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases?

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

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


From stefank at openjdk.java.net  Thu Nov 11 16:17:38 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Nov 2021 16:17:38 GMT
Subject: RFR: 8275329: ZGC:
 vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with
 assert(_phases->length() <= 1000) failed: Too many recored phases?
In-Reply-To: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
References: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
Message-ID: <qQ23fZFSTiVFowMqAnVfl5ksrSdc0exX8gvvTQUxgZc=.73a5f0ed-283a-4bef-84cd-cb15f5c5dfbf@github.com>

On Thu, 11 Nov 2021 15:40:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> In ZGC, the phases the "Pause Mark End" and "Concurrent Mark Continue" can be executed multiple times in the same GC cycle. This can happen for two reasons:
> 
> 1) After "Concurrent Mark Continue" has terminated, but before "Pause Mark End" has started, a `SoftReference` or a `WeakReference` is resurrected by a call to `Reference.get()` from a Java thread.
> 
> 2) A Java thread "hides" work from the GC worker threads doing marking, by detaching unmarked objects from the graph and push it to a thread local mark stack, that the GC needs to flush out. An example of this is when a Java thread continuously removes the first element in a single linked list that hasn't been marked yet.
> 
> The above events are typically rare, but it is possible to write a program that causes the above GC phases to be executed a large number of times. The test that failed (`soft004.java`) runs into case 2 above, where it has ~50,000,000 SoftReferences in the reference processing pending list (a single linked list) and continuously removes the first element until the list if empty. This causes more than 1000 "Pause Mark End" attempt to happen. For that reason, we don't want `TimePartitions` to assert if there are more than 1000 phases. This patch disables the assert in question if ZGC is used. An alternative would be to remove the assert completely, but @stefank preferred to just disable it for ZGC.

Marked as reviewed by stefank (Reviewer).

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

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


From eosterlund at openjdk.java.net  Thu Nov 11 16:23:34 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 11 Nov 2021 16:23:34 GMT
Subject: RFR: 8275329: ZGC:
 vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with
 assert(_phases->length() <= 1000) failed: Too many recored phases?
In-Reply-To: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
References: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
Message-ID: <jgiYcv9RSb5hBQQyD-AKKadbrC83b_lmIUeua3qWhdo=.bad01f4a-79ea-47ea-b743-790305cd6178@github.com>

On Thu, 11 Nov 2021 15:40:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> In ZGC, the phases the "Pause Mark End" and "Concurrent Mark Continue" can be executed multiple times in the same GC cycle. This can happen for two reasons:
> 
> 1) After "Concurrent Mark Continue" has terminated, but before "Pause Mark End" has started, a `SoftReference` or a `WeakReference` is resurrected by a call to `Reference.get()` from a Java thread.
> 
> 2) A Java thread "hides" work from the GC worker threads doing marking, by detaching unmarked objects from the graph and push it to a thread local mark stack, that the GC needs to flush out. An example of this is when a Java thread continuously removes the first element in a single linked list that hasn't been marked yet.
> 
> The above events are typically rare, but it is possible to write a program that causes the above GC phases to be executed a large number of times. The test that failed (`soft004.java`) runs into case 2 above, where it has ~50,000,000 SoftReferences in the reference processing pending list (a single linked list) and continuously removes the first element until the list if empty. This causes more than 1000 "Pause Mark End" attempt to happen. For that reason, we don't want `TimePartitions` to assert if there are more than 1000 phases. This patch disables the assert in question if ZGC is used. An alternative would be to remove the assert completely, but @stefank preferred to just disable it for ZGC.

Marked as reviewed by eosterlund (Reviewer).

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

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


From mli at openjdk.java.net  Fri Nov 12 02:09:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 12 Nov 2021 02:09:44 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure
Message-ID: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>

This is a minor optimization.
We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.

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

Commit messages:
 - Remove dead code
 - use COMMA
 - Initial commit

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

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


From pliden at openjdk.java.net  Fri Nov 12 08:21:38 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 12 Nov 2021 08:21:38 GMT
Subject: RFR: 8275329: ZGC:
 vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with
 assert(_phases->length() <= 1000) failed: Too many recored phases?
In-Reply-To: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
References: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
Message-ID: <7TTB4cVJ6yDYJekLDCyBQgpe23gFPMzEkjE_EZd6QLc=.b7c7f08c-13b2-4015-92e2-d902dabc46c3@github.com>

On Thu, 11 Nov 2021 15:40:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> In ZGC, the phases the "Pause Mark End" and "Concurrent Mark Continue" can be executed multiple times in the same GC cycle. This can happen for two reasons:
> 
> 1) After "Concurrent Mark Continue" has terminated, but before "Pause Mark End" has started, a `SoftReference` or a `WeakReference` is resurrected by a call to `Reference.get()` from a Java thread.
> 
> 2) A Java thread "hides" work from the GC worker threads doing marking, by detaching unmarked objects from the graph and push it to a thread local mark stack, that the GC needs to flush out. An example of this is when a Java thread continuously removes the first element in a single linked list that hasn't been marked yet.
> 
> The above events are typically rare, but it is possible to write a program that causes the above GC phases to be executed a large number of times. The test that failed (`soft004.java`) runs into case 2 above, where it has ~50,000,000 SoftReferences in the reference processing pending list (a single linked list) and continuously removes the first element until the list if empty. This causes more than 1000 "Pause Mark End" attempt to happen. For that reason, we don't want `TimePartitions` to assert if there are more than 1000 phases. This patch disables the assert in question if ZGC is used. An alternative would be to remove the assert completely, but @stefank preferred to just disable it for ZGC.

Thanks for reviewing!

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

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


From pliden at openjdk.java.net  Fri Nov 12 08:21:38 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 12 Nov 2021 08:21:38 GMT
Subject: Integrated: 8275329: ZGC:
 vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with
 assert(_phases->length() <= 1000) failed: Too many recored phases?
In-Reply-To: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
References: <v57qB5xQ_zNVM0mjOH_rYVx9VTqa8TKyl8Jk9eGqg3g=.d7609e1b-40a6-44c0-9168-3174a8a8b41e@github.com>
Message-ID: <7muc385B_nTRmCNNgHsUKo6KGkUZbIKwjM5WB3BV7Ak=.21a00b5d-bc92-4c1f-aeaa-2f3be7161b32@github.com>

On Thu, 11 Nov 2021 15:40:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> In ZGC, the phases the "Pause Mark End" and "Concurrent Mark Continue" can be executed multiple times in the same GC cycle. This can happen for two reasons:
> 
> 1) After "Concurrent Mark Continue" has terminated, but before "Pause Mark End" has started, a `SoftReference` or a `WeakReference` is resurrected by a call to `Reference.get()` from a Java thread.
> 
> 2) A Java thread "hides" work from the GC worker threads doing marking, by detaching unmarked objects from the graph and push it to a thread local mark stack, that the GC needs to flush out. An example of this is when a Java thread continuously removes the first element in a single linked list that hasn't been marked yet.
> 
> The above events are typically rare, but it is possible to write a program that causes the above GC phases to be executed a large number of times. The test that failed (`soft004.java`) runs into case 2 above, where it has ~50,000,000 SoftReferences in the reference processing pending list (a single linked list) and continuously removes the first element until the list if empty. This causes more than 1000 "Pause Mark End" attempt to happen. For that reason, we don't want `TimePartitions` to assert if there are more than 1000 phases. This patch disables the assert in question if ZGC is used. An alternative would be to remove the assert completely, but @stefank preferred to just disable it for ZGC.

This pull request has now been integrated.

Changeset: 6b833db3
Author:    Per Liden <pliden at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6b833db3f9cace8fbb09bb803ba31208e37a4622
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases?

Reviewed-by: stefank, eosterlund

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

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


From lihuaming3 at huawei.com  Fri Nov 12 08:23:00 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Fri, 12 Nov 2021 08:23:00 +0000
Subject: Discussion about unifying the wording buffer/node/element in G1,
 especially classes using G1SegmentedArray and related classes
Message-ID: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>

Hi all,

May I have your attention to discuss about unifying the wording buffer/node/element in G1, especially classes using G1SegmentedArray and related classes.

Background: Currently, the words "buffer", "node" and "element" are used together in G1SegmentedArrayXxx, G1CardSetXxx and related classes in an inconsistent way, which is very unfavorable for understanding. We should not confuse buffer and node together, and not confuse node and element together. The new wording should be based on something like the following rule: A segmented array consists of several buffers one of which consists of several element (or node? we should choose one of element or node).

I propose to use "segmented array -> buffer -> elem/element", the reasons are: first, "node" is used as memory node, numa node, which is used in lots of other places, e.g. heapRegion, heapRegionSet, G1Allocator,..., while "buffer + node" together is used as buffer in BufferNode/G1BufferNodeList (these classes will not be changes), so "node" should not be used as "element"; In G1CardSet and G1CardSetContainer, most of comments/variables use "elem" rather than "node" for single element.

Here is a list of proposed rename mappings, related JBS issues are attached below, would you mind to share your points about this renaming mapping? Thanks.

G1CardSetHashTableConfig::allocate_node

node -> elem

G1CardSetHashTableConfig::free_node

node -> elem


G1CardSetAllocOptions::BufferAlignment

G1CardSetAllocOptions::ElemAlignment


G1CardSetAllocator::next_ptr(G1CardSetContainer& node)

node -> elem

G1CardSetAllocator::NodeStack

node -> elem

G1CardSetAllocator::_free_nodes_list

node -> elem

G1CardSetAllocator::_pending_nodes_list

node -> elem

G1CardSetAllocator::_num_pending_nodes

node -> elem

G1CardSetAllocator::_num_free_nodes

node -> elem

G1CardSetAllocator comments

node -> elem


G1CardSetMemoryStats

G1SegmentedArrayMemoryStats


G1CardSetFreePool

G1SegmentedArrayFreePool


G1CardSetMemoryManager::allocate_node

node -> elem

G1CardSetMemoryManager::free_node

node -> elem


G1CardSetFreeMemoryTask

G1SegmentedArrayFreeMemoryTask


G1SegmentedArrayBufferList

G1SegmentedArrayFreeList

G1SegmentedArrayBufferList::next_ptr(G1SegmentedArrayBuffer<flag>& node)

node -> buffer

G1SegmentedArrayBufferList::NodeStack

node -> buffer



G1SegmentedArray::_num_available_nodes

node -> elem

G1SegmentedArray::_num_allocated_nodes

node -> elem

G1SegmentedArray::num_available_nodes()

node -> elem

G1SegmentedArray::num_allocated_nodes()

node -> elem

G1SegmentedArray::iterate_nodes

node -> buffer


G1EvacFailureObjectsIterationHelper::do_buffer(G1SegmentedArrayBuffer<mtGC>* node, uint length)

node -> elem


Thanks
-Hamlin

[1] https://bugs.openjdk.java.net/browse/JDK-8276299
[2] https://bugs.openjdk.java.net/browse/JDK-8276670




From ayang at openjdk.java.net  Fri Nov 12 11:00:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 12 Nov 2021 11:00:35 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure
In-Reply-To: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
Message-ID: <Ph7L7_Fc9aZHIaz0x5YBZIlMkap9O40mgWr7l8iBl5o=.557b292a-44b4-4a4c-b7d7-563cc17b46c6@github.com>

On Fri, 12 Nov 2021 02:00:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor optimization.
> We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.

I think `_num_failed_regions` can be dropped completely; it's used for verification only. `~RemoveSelfForwardPtrsTask` can go as well as a cascading effect.

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

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


From ayang at openjdk.java.net  Fri Nov 12 12:31:44 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 12 Nov 2021 12:31:44 GMT
Subject: RFR: 8277045: G1: Remove unnecessary set_concurrency call in
 G1ConcurrentMark::weak_refs_work
Message-ID: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>

Simple change of removing an unnecessary method call.

Test: hotspot_gc

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

Commit messages:
 - remove_set_concurrency

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

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


From kbarrett at openjdk.java.net  Sat Nov 13 05:29:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 13 Nov 2021 05:29:40 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
Message-ID: <U8v47aTshLUK9h3lzyD_xwec1paRC7tzWs2jAsrMTzs=.e47c44ae-5c6c-4fbe-9dd5-f1947a16dcb9@github.com>

On Wed, 10 Nov 2021 21:09:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - Revert "worker_id"
>    
>    This reverts commit 0841db5c5c2b39372058b6ba0d8027aae3716669.

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 912:

> 910:   ReferenceProcessor*   _cm_rp;
> 911: 
> 912:   void do_mark_step(G1CMTask* task) {

I found the name of this confusingly close to `do_marking_step` by the task.  I can see how this could be called a "step" with preclean being another (new) step, but I think the confusion with the other function outweighs that and needs a different name here.  Maybe just `do_marking` or `do_all_marking` or something like that.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 1073:

> 1071:   Ticks preclean_start = Ticks::now();
> 1072: 
> 1073:   ReferenceType ref_type_arr[4] = { REF_SOFT, REF_WEAK, REF_FINAL, REF_PHANTOM };

Instead of specifying the array size, just let it be computed from the initializer length.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 1074:

> 1072: 
> 1073:   ReferenceType ref_type_arr[4] = { REF_SOFT, REF_WEAK, REF_FINAL, REF_PHANTOM };
> 1074:   size_t ref_count_arr[4] = {};

Instead of literal 4 here and below, use ARRAY_SIZE(ref_type_arr), or maybe give that value a name and replace all the literal 4s with that name.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 1076:

> 1074:   size_t ref_count_arr[4] = {};
> 1075: 
> 1076:   if (discovery_is_mt()) {

The old form of these loops called `yield->should_return()` for each queue.  That's been lost in this rewrite, and I'm not sure that's correct.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 1096:

> 1094:   }
> 1095: 
> 1096:   uint worker_id = WorkerThread::current()->id();

This logging is potentially far more verbose than previously, since there will now be a line for each concurrent marking thread, rather than one line for the previously single-threaded precleaning.  We have mechanisms for collecting and reporting timing and work units for parallel activities that should be used here.

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

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


From ayang at openjdk.java.net  Sat Nov 13 09:42:07 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sat, 13 Nov 2021 09:42:07 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v4]
In-Reply-To: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
Message-ID: <fSk_i3k24d0dzahHXm6KJO1xodUtOBwRpLF9HCvmmE8=.5e487ae1-dfa5-411f-96fd-21bb28de94c2@github.com>

> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
> 
> Test: hotspot_gc

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6327/files
  - new: https://git.openjdk.java.net/jdk/pull/6327/files/f73a6db5..4c3e7514

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

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

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


From ayang at openjdk.java.net  Sat Nov 13 09:42:17 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sat, 13 Nov 2021 09:42:17 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <U8v47aTshLUK9h3lzyD_xwec1paRC7tzWs2jAsrMTzs=.e47c44ae-5c6c-4fbe-9dd5-f1947a16dcb9@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
 <U8v47aTshLUK9h3lzyD_xwec1paRC7tzWs2jAsrMTzs=.e47c44ae-5c6c-4fbe-9dd5-f1947a16dcb9@github.com>
Message-ID: <XqeOxIj7KcBZfOfb0VT4jY4ryVw36jSRyRfaG3SOvSY=.1afab460-7908-48a3-be57-6e07a726e79a@github.com>

On Sat, 13 Nov 2021 04:49:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review
>>  - Revert "worker_id"
>>    
>>    This reverts commit 0841db5c5c2b39372058b6ba0d8027aae3716669.
>
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 912:
> 
>> 910:   ReferenceProcessor*   _cm_rp;
>> 911: 
>> 912:   void do_mark_step(G1CMTask* task) {
> 
> I found the name of this confusingly close to `do_marking_step` by the task.  I can see how this could be called a "step" with preclean being another (new) step, but I think the confusion with the other function outweighs that and needs a different name here.  Maybe just `do_marking` or `do_all_marking` or something like that.

Renamed to `do_marking`.

> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1073:
> 
>> 1071:   Ticks preclean_start = Ticks::now();
>> 1072: 
>> 1073:   ReferenceType ref_type_arr[4] = { REF_SOFT, REF_WEAK, REF_FINAL, REF_PHANTOM };
> 
> Instead of specifying the array size, just let it be computed from the initializer length.

Fixed.

> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1074:
> 
>> 1072: 
>> 1073:   ReferenceType ref_type_arr[4] = { REF_SOFT, REF_WEAK, REF_FINAL, REF_PHANTOM };
>> 1074:   size_t ref_count_arr[4] = {};
> 
> Instead of literal 4 here and below, use ARRAY_SIZE(ref_type_arr), or maybe give that value a name and replace all the literal 4s with that name.

Fixed.

> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1076:
> 
>> 1074:   size_t ref_count_arr[4] = {};
>> 1075: 
>> 1076:   if (discovery_is_mt()) {
> 
> The old form of these loops called `yield->should_return()` for each queue.  That's been lost in this rewrite, and I'm not sure that's correct.

It's still correct because `preclean_discovered_reflist` checkes for if-aborted while iterating the list. I could have written sth like the following if you think prompt abort is important.


  bool is_aborted = preclean_discovered_reflist(...);
  if (is_aborted) {
    return;
  }

> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1096:
> 
>> 1094:   }
>> 1095: 
>> 1096:   uint worker_id = WorkerThread::current()->id();
> 
> This logging is potentially far more verbose than previously, since there will now be a line for each concurrent marking thread, rather than one line for the previously single-threaded precleaning.  We have mechanisms for collecting and reporting timing and work units for parallel activities that should be used here.

The new logs are on `trace` level, just FYI. How about I address all logging related issues (from Thomas and Stefan as well) in a follow-up PR?

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

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


From kbarrett at openjdk.java.net  Sun Nov 14 22:39:38 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 14 Nov 2021 22:39:38 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v4]
In-Reply-To: <fSk_i3k24d0dzahHXm6KJO1xodUtOBwRpLF9HCvmmE8=.5e487ae1-dfa5-411f-96fd-21bb28de94c2@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <fSk_i3k24d0dzahHXm6KJO1xodUtOBwRpLF9HCvmmE8=.5e487ae1-dfa5-411f-96fd-21bb28de94c2@github.com>
Message-ID: <a80-zxG04BamsbcZD-vEEdVSB5t72nI8eiB5IJn9F78=.deef76b0-fbc2-42e8-8a64-c78c0a696928@github.com>

On Sat, 13 Nov 2021 09:42:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/referenceProcessor.cpp line 1075:

> 1073:   constexpr int ref_kinds = 4;
> 1074:   ReferenceType ref_type_arr[] = { REF_SOFT, REF_WEAK, REF_FINAL, REF_PHANTOM };
> 1075:   static_assert(ARRAY_SIZE(ref_type_arr) == ref_kinds, "invariant");

I don't think there's a need for the literal 4 initializer for ref_kinds and the static assert to verify it's correct.  Why not just use this after the declaration of `ref_type_arr`?
`constexpr int ref_kinds = ARRAY_SIZE(ref_type_arr);`

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

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


From kbarrett at openjdk.java.net  Sun Nov 14 22:39:38 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 14 Nov 2021 22:39:38 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <XqeOxIj7KcBZfOfb0VT4jY4ryVw36jSRyRfaG3SOvSY=.1afab460-7908-48a3-be57-6e07a726e79a@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
 <U8v47aTshLUK9h3lzyD_xwec1paRC7tzWs2jAsrMTzs=.e47c44ae-5c6c-4fbe-9dd5-f1947a16dcb9@github.com>
 <XqeOxIj7KcBZfOfb0VT4jY4ryVw36jSRyRfaG3SOvSY=.1afab460-7908-48a3-be57-6e07a726e79a@github.com>
Message-ID: <QZKJjCFCMYi-L6Et_aStn2EzZlYilhsBAcbF_0qyNnc=.a2097ec0-835a-48de-aa6e-1ab0c94add28@github.com>

On Sat, 13 Nov 2021 09:36:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1076:
>> 
>>> 1074:   size_t ref_count_arr[4] = {};
>>> 1075: 
>>> 1076:   if (discovery_is_mt()) {
>> 
>> The old form of these loops called `yield->should_return()` for each queue.  That's been lost in this rewrite, and I'm not sure that's correct.
>
> It's still correct because `preclean_discovered_reflist` checkes for if-aborted while iterating the list. I could have written sth like the following if you think prompt abort is important.
> 
> 
>   bool is_aborted = preclean_discovered_reflist(...);
>   if (is_aborted) {
>     return;
>   }

It's hard to know for sure, but the description of YieldClosure makes me think that's not really the intended usage.  OTOH, this seems to be the only use of YieldClosure; maybe there were others in CMS?  I would prefer the `yield->should_return()` checks be retained.  Also, `preclean_discovered_reflist` might no longer need to return bool.

>> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1096:
>> 
>>> 1094:   }
>>> 1095: 
>>> 1096:   uint worker_id = WorkerThread::current()->id();
>> 
>> This logging is potentially far more verbose than previously, since there will now be a line for each concurrent marking thread, rather than one line for the previously single-threaded precleaning.  We have mechanisms for collecting and reporting timing and work units for parallel activities that should be used here.
>
> The new logs are on `trace` level, just FYI. How about I address all logging related issues (from Thomas and Stefan as well) in a follow-up PR?

I know this is trace logging, but that doesn't make the verbosity or content good.  Consider a machine with a large amount of concurrency; one might be interested in any of the totals/min/max/avg, and having to extract that manually is going to be annoying.  I'm okay with it being a followup though.

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

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


From ayang at openjdk.java.net  Sun Nov 14 22:54:39 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sun, 14 Nov 2021 22:54:39 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v8]
In-Reply-To: <wZEGwq_b1crh1_QJhxM0xdZ-hJkvOI5RoBRQVyrU6T8=.42a1b251-dd9c-4d9c-a082-b1345a9915a1@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
 <wZEGwq_b1crh1_QJhxM0xdZ-hJkvOI5RoBRQVyrU6T8=.42a1b251-dd9c-4d9c-a082-b1345a9915a1@github.com>
Message-ID: <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>

On Mon, 8 Nov 2021 15:11:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region?
>> 
>> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`.
>> 
>> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`).
>> 
>> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected.
>> 
>> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?).
>> 
>> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
>> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
>> 
>> There is also a CSR to look at.
>> 
>> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
>> 
>> Thanks,
>> Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>  - ayang review1
>  - Limit ergonomics to 32m regions
>  - sjohanss review
>  - Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor
>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>  - 32 bit compatibility - limit region size to 32M there as before. Fix test.
>  - Virtual heap regions in remembered sets

Just some minor comments/suggestions.

src/hotspot/share/gc/g1/g1CardSet.cpp line 67:

> 65:                          default_log2_card_region_per_region())                     /* log2_card_region_per_region */
> 66: {
> 67:   assert((_log2_card_region_per_heap_region + _log2_card_region_size) == (uint)HeapRegion::LogCardsPerRegion,

I suggest `_log2_card_region_size -> _log2_cards_per_card_region`; then the assertion becomes more consistent, IMO.
`assert((_log2_card_region_per_heap_region + _log2_cards_per_card_region) == (uint)HeapRegion::LogCardsPerRegion)`, which, in math form, is
`(card_region / heap_region) x (cards / card_region) == cards / (heap_)region`

src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 105:

> 103:                              region_idx >> _log_card_regions_per_region,
> 104:                              (region_idx & _card_regions_per_region_mask) << _log_card_region_size);
> 105:     _card_set->iterate_cards_or_ranges_in_container(card_set, cl);

`region_idx` is actually `card_region_idx`, right? If so, `card_region_idx >> _log_card_regions_per_region` ==> `region_idx` (the second arg of `G1ContainerCardsOrRanges` constructor) makes sense to me.

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

Marked as reviewed by ayang (Reviewer).

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


From ayang at openjdk.java.net  Sun Nov 14 23:08:09 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sun, 14 Nov 2021 23:08:09 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v5]
In-Reply-To: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
Message-ID: <PpaQLVXnLXfP-UNzea4jVpkj8hN7Bbx1PFsudYuz5YE=.cd42b7aa-7094-4b58-a8ea-5ddf68b2f434@github.com>

> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
> 
> Test: hotspot_gc

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6327/files
  - new: https://git.openjdk.java.net/jdk/pull/6327/files/4c3e7514..a1571a2e

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

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

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


From ayang at openjdk.java.net  Sun Nov 14 23:08:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sun, 14 Nov 2021 23:08:13 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v4]
In-Reply-To: <a80-zxG04BamsbcZD-vEEdVSB5t72nI8eiB5IJn9F78=.deef76b0-fbc2-42e8-8a64-c78c0a696928@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <fSk_i3k24d0dzahHXm6KJO1xodUtOBwRpLF9HCvmmE8=.5e487ae1-dfa5-411f-96fd-21bb28de94c2@github.com>
 <a80-zxG04BamsbcZD-vEEdVSB5t72nI8eiB5IJn9F78=.deef76b0-fbc2-42e8-8a64-c78c0a696928@github.com>
Message-ID: <fRnQ6NlgrSFBvJ7UasKdRRsrXLO5nUypaM75c1-BWhU=.2e5206c7-d550-4410-bedc-476cf319b18f@github.com>

On Sun, 14 Nov 2021 06:28:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/shared/referenceProcessor.cpp line 1075:
> 
>> 1073:   constexpr int ref_kinds = 4;
>> 1074:   ReferenceType ref_type_arr[] = { REF_SOFT, REF_WEAK, REF_FINAL, REF_PHANTOM };
>> 1075:   static_assert(ARRAY_SIZE(ref_type_arr) == ref_kinds, "invariant");
> 
> I don't think there's a need for the literal 4 initializer for ref_kinds and the static assert to verify it's correct.  Why not just use this after the declaration of `ref_type_arr`?
> `constexpr int ref_kinds = ARRAY_SIZE(ref_type_arr);`

Changed as suggested.

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

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


From ayang at openjdk.java.net  Sun Nov 14 23:08:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sun, 14 Nov 2021 23:08:14 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v3]
In-Reply-To: <QZKJjCFCMYi-L6Et_aStn2EzZlYilhsBAcbF_0qyNnc=.a2097ec0-835a-48de-aa6e-1ab0c94add28@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <ZfSFNngTDVnzQtqhnQQyS8EBuEVO6AisdxLcszxmwzw=.e631935d-2fd4-4577-85c1-4132ed4c9e00@github.com>
 <U8v47aTshLUK9h3lzyD_xwec1paRC7tzWs2jAsrMTzs=.e47c44ae-5c6c-4fbe-9dd5-f1947a16dcb9@github.com>
 <XqeOxIj7KcBZfOfb0VT4jY4ryVw36jSRyRfaG3SOvSY=.1afab460-7908-48a3-be57-6e07a726e79a@github.com>
 <QZKJjCFCMYi-L6Et_aStn2EzZlYilhsBAcbF_0qyNnc=.a2097ec0-835a-48de-aa6e-1ab0c94add28@github.com>
Message-ID: <fM5bXJDFTen1oZ-4I6-x6rh-e_tT2hSFB5Dzt4bh1Rg=.c41d92ed-3332-4bd7-8953-500a79233a33@github.com>

On Sun, 14 Nov 2021 22:32:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It's still correct because `preclean_discovered_reflist` checkes for if-aborted while iterating the list. I could have written sth like the following if you think prompt abort is important.
>> 
>> 
>>   bool is_aborted = preclean_discovered_reflist(...);
>>   if (is_aborted) {
>>     return;
>>   }
>
> It's hard to know for sure, but the description of YieldClosure makes me think that's not really the intended usage.  OTOH, this seems to be the only use of YieldClosure; maybe there were others in CMS?  I would prefer the `yield->should_return()` checks be retained.  Also, `preclean_discovered_reflist` might no longer need to return bool.

Restored `yield->should_return()`.

> one might be interested in any of the totals/min/max/avg

Thomas suggested this as well. I will address this in a followup PR.

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

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


From kbarrett at openjdk.java.net  Sun Nov 14 23:48:38 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 14 Nov 2021 23:48:38 GMT
Subject: RFR: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase [v5]
In-Reply-To: <PpaQLVXnLXfP-UNzea4jVpkj8hN7Bbx1PFsudYuz5YE=.cd42b7aa-7094-4b58-a8ea-5ddf68b2f434@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
 <PpaQLVXnLXfP-UNzea4jVpkj8hN7Bbx1PFsudYuz5YE=.cd42b7aa-7094-4b58-a8ea-5ddf68b2f434@github.com>
Message-ID: <pXDvBdRkjLN0880v5oc7oV5YRRli9jqnwlr0DlRInV4=.eb6c5207-a3b5-4593-a54b-644d25a7d2bf@github.com>

On Sun, 14 Nov 2021 23:08:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Mon Nov 15 01:33:57 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 15 Nov 2021 01:33:57 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure [v2]
In-Reply-To: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
Message-ID: <5FNRqFFut_KEk8ASI-HbudUcwru3jUmn2-C2C6dttic=.f7d796df-fbf1-4fc6-a02d-57b4265dfb77@github.com>

> This is a minor optimization.
> We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Remove completely

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6362/files
  - new: https://git.openjdk.java.net/jdk/pull/6362/files/0637b050..7f0f14a7

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

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

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


From mli at openjdk.java.net  Mon Nov 15 01:33:57 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 15 Nov 2021 01:33:57 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure
In-Reply-To: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
Message-ID: <mHF1A9i_ARfful5gKw_Nt4D5huYfRsKyH4UNNWy6VT0=.710ef07b-bea1-4dc9-8ca5-f66c806b253e@github.com>

On Fri, 12 Nov 2021 02:00:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor optimization.
> We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.

Thanks Albert, I agree.

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 08:02:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 08:02:43 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure [v2]
In-Reply-To: <5FNRqFFut_KEk8ASI-HbudUcwru3jUmn2-C2C6dttic=.f7d796df-fbf1-4fc6-a02d-57b4265dfb77@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
 <5FNRqFFut_KEk8ASI-HbudUcwru3jUmn2-C2C6dttic=.f7d796df-fbf1-4fc6-a02d-57b4265dfb77@github.com>
Message-ID: <9tIKbVg3Siq99rEaluwQcV-9heH4j8NxpiDyhfJMHp4=.85821d13-b935-4561-9159-fb72cb6ca825@github.com>

On Mon, 15 Nov 2021 01:33:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a minor optimization.
>> We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove completely

Also good.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Nov 15 08:40:38 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 15 Nov 2021 08:40:38 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure [v2]
In-Reply-To: <5FNRqFFut_KEk8ASI-HbudUcwru3jUmn2-C2C6dttic=.f7d796df-fbf1-4fc6-a02d-57b4265dfb77@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
 <5FNRqFFut_KEk8ASI-HbudUcwru3jUmn2-C2C6dttic=.f7d796df-fbf1-4fc6-a02d-57b4265dfb77@github.com>
Message-ID: <3wREmR38sBwT6PlsqYkuQqBoHNT3x32XEj-DBAL1-74=.d9f2b4c4-8ab5-40e9-881c-c706e59b8261@github.com>

On Mon, 15 Nov 2021 01:33:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a minor optimization.
>> We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove completely

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 08:45:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 08:45:50 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v8]
In-Reply-To: <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
 <wZEGwq_b1crh1_QJhxM0xdZ-hJkvOI5RoBRQVyrU6T8=.42a1b251-dd9c-4d9c-a082-b1345a9915a1@github.com>
 <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>
Message-ID: <0IOGu_gW271em9osgVuzYIBxkpPu_DUCPW94qVbefvw=.f96639e9-94d7-47bf-a962-2b1739323ea9@github.com>

On Sun, 14 Nov 2021 22:40:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>>  - ayang review1
>>  - Limit ergonomics to 32m regions
>>  - sjohanss review
>>  - Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor
>>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>>  - 32 bit compatibility - limit region size to 32M there as before. Fix test.
>>  - Virtual heap regions in remembered sets
>
> src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 105:
> 
>> 103:                              region_idx >> _log_card_regions_per_region,
>> 104:                              (region_idx & _card_regions_per_region_mask) << _log_card_region_size);
>> 105:     _card_set->iterate_cards_or_ranges_in_container(card_set, cl);
> 
> `region_idx` is actually `card_region_idx`, right? If so, `card_region_idx >> _log_card_regions_per_region` ==> `region_idx` (the second arg of `G1ContainerCardsOrRanges` constructor) makes sense to me.

Yes, that is the unchanged "region" that the hash table for the containers sees, which is the `card_region_idx` at this level.

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 09:19:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 09:19:04 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v9]
In-Reply-To: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
Message-ID: <bWggUQ_H2kzZ22i8WKDxx5ldN7WMX6px6v4PBP5hM50=.1870f167-b3fc-471a-8276-e561010f43ca@github.com>

> Hi all,
> 
> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region?
> 
> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`.
> 
> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`).
> 
> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected.
> 
> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?).
> 
> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
> 
> There is also a CSR to look at.
> 
> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
> 
> Thanks,
> Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  ayang review2

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6059/files
  - new: https://git.openjdk.java.net/jdk/pull/6059/files/b644a849..3b124f19

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

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 09:19:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 09:19:10 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v8]
In-Reply-To: <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
 <wZEGwq_b1crh1_QJhxM0xdZ-hJkvOI5RoBRQVyrU6T8=.42a1b251-dd9c-4d9c-a082-b1345a9915a1@github.com>
 <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>
Message-ID: <X2rtEqpHSLFwInymtsgXRbcsZzAC37OWtNHcUf91evg=.51b2d233-1976-419e-91c2-9f0f35c47a50@github.com>

On Sun, 14 Nov 2021 22:47:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>>  - ayang review1
>>  - Limit ergonomics to 32m regions
>>  - sjohanss review
>>  - Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor
>>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>>  - 32 bit compatibility - limit region size to 32M there as before. Fix test.
>>  - Virtual heap regions in remembered sets
>
> src/hotspot/share/gc/g1/g1CardSet.cpp line 67:
> 
>> 65:                          default_log2_card_region_per_region())                     /* log2_card_region_per_region */
>> 66: {
>> 67:   assert((_log2_card_region_per_heap_region + _log2_card_region_size) == (uint)HeapRegion::LogCardsPerRegion,
> 
> I suggest `_log2_card_region_size -> _log2_cards_per_card_region`; then the assertion becomes more consistent, IMO.
> `assert((_log2_card_region_per_heap_region + _log2_cards_per_card_region) == (uint)HeapRegion::LogCardsPerRegion)`, which, in math form, is
> `(card_region / heap_region) x (cards / card_region) == cards / (heap_)region`

Implemented. I'll push in around 7-8 hours unless somebody objects.

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 09:32:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 09:32:07 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v10]
In-Reply-To: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
Message-ID: <rY4lhF4OKvwdXjueX4m9aP-lh9QIBi9SiKcknATvSuY=.4f4104c9-e4e1-4597-9ee3-575c22e654ec@github.com>

> Hi all,
> 
> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region?
> 
> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`.
> 
> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`).
> 
> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected.
> 
> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?).
> 
> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
> 
> There is also a CSR to look at.
> 
> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
> 
> Thanks,
> Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  ayang review3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6059/files
  - new: https://git.openjdk.java.net/jdk/pull/6059/files/3b124f19..e0cfedd4

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

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

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


From mli at openjdk.java.net  Mon Nov 15 10:11:42 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 15 Nov 2021 10:11:42 GMT
Subject: RFR: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure [v2]
In-Reply-To: <9tIKbVg3Siq99rEaluwQcV-9heH4j8NxpiDyhfJMHp4=.85821d13-b935-4561-9159-fb72cb6ca825@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
 <5FNRqFFut_KEk8ASI-HbudUcwru3jUmn2-C2C6dttic=.f7d796df-fbf1-4fc6-a02d-57b4265dfb77@github.com>
 <9tIKbVg3Siq99rEaluwQcV-9heH4j8NxpiDyhfJMHp4=.85821d13-b935-4561-9159-fb72cb6ca825@github.com>
Message-ID: <Hu4J96lpw5tsHvOnZKglD1ybF3dg2yhn-k5rbOJKg4c=.29193aad-f26b-41eb-8746-726cfdd512ea@github.com>

On Mon, 15 Nov 2021 07:59:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove completely
>
> Also good.

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Mon Nov 15 10:11:43 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 15 Nov 2021 10:11:43 GMT
Subject: Integrated: 8276921: G1: Remove redundant failed evacuation regions
 calculation in RemoveSelfForwardPtrHRClosure
In-Reply-To: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
References: <nzrwO4OCLLSEVL99zF93KhjrJMHqnKlhYxmDI8PX-n0=.af68c81c-7117-43b9-841e-99fee808bdc3@github.com>
Message-ID: <ZC4plO_uhrWKLKAZMKlV01PuuSSSiVVovawPi64zCuM=.10a4ffc0-d047-4c23-8329-0ea67c3fa9bd@github.com>

On Fri, 12 Nov 2021 02:00:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor optimization.
> We already have the number of failed evacuation region numbers, there is no need to calculate it on fly, at least in product code, so make it debug only, and add assert to verify the result.

This pull request has now been integrated.

Changeset: b231f5ba
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b231f5baa94c7104324cd206c1081b35fd27164c
Stats:     15 lines in 2 files changed: 0 ins; 12 del; 3 mod

8276921: G1: Remove redundant failed evacuation regions calculation in RemoveSelfForwardPtrHRClosure

Reviewed-by: ayang, tschatzl

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 11:20:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 11:20:39 GMT
Subject: RFR: 8277045: G1: Remove unnecessary set_concurrency call in
 G1ConcurrentMark::weak_refs_work
In-Reply-To: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
References: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
Message-ID: <0CMV9W9BlS6vCI7ElQm30etK_JEdwAmkLRA2tPzGkdQ=.16ac42fa-fbd9-41c9-862e-28a2f87b2a34@github.com>

On Fri, 12 Nov 2021 12:23:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary method call.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Nov 15 12:32:40 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 15 Nov 2021 12:32:40 GMT
Subject: RFR: 8276932: G1: Annotate methods with override explicitly in
 g1CollectedHeap.hpp
In-Reply-To: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
References: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
Message-ID: <1jReNQlkjhKJUSx4HW0hPLRUMD7Gkq1ucwgcgVHF7jE=.9466a306-1535-4040-b05e-cbe3c2e77ae5@github.com>

On Wed, 10 Nov 2021 09:51:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits: the first commit is generated using `clang-tidy --fix src/hotspot/share/gc/g1/g1CollectedHeap.hpp -checks=modernize-use-override -p build/linux-x64-debug`, and the second commit fixes some indentation issues.
> 
> Test: build

Marked as reviewed by sjohanss (Reviewer).

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

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


From mli at openjdk.java.net  Mon Nov 15 12:39:55 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 15 Nov 2021 12:39:55 GMT
Subject: RFR: 8277119: Add asserts in GenericTaskQueueSet methods
Message-ID: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>

Some methods in GenericTaskQueueSet lack of assert, which is not friendly to debug/troubleshooting.
This is to add necessary asserts.

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

Commit messages:
 - Initial commit

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

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


From ayang at openjdk.java.net  Mon Nov 15 12:51:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 15 Nov 2021 12:51:42 GMT
Subject: RFR: 8276932: G1: Annotate methods with override explicitly in
 g1CollectedHeap.hpp
In-Reply-To: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
References: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
Message-ID: <aivf57WuU5uEXnmNClWJSZWJGs3Rig80Dbxtfh3zzhE=.9872d064-2085-4daa-a93e-3e138a60b486@github.com>

On Wed, 10 Nov 2021 09:51:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits: the first commit is generated using `clang-tidy --fix src/hotspot/share/gc/g1/g1CollectedHeap.hpp -checks=modernize-use-override -p build/linux-x64-debug`, and the second commit fixes some indentation issues.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Nov 15 12:51:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 15 Nov 2021 12:51:42 GMT
Subject: Integrated: 8276932: G1: Annotate methods with override explicitly in
 g1CollectedHeap.hpp
In-Reply-To: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
References: <-S1jB_pK72g48ionmO-FS1X2KM8QByyBj6wmUgRabV8=.09d41f94-3b56-47c1-855d-d32d81612bc0@github.com>
Message-ID: <fioBc68HzuIrJo-KRZKFkzLTM19MqmeYPMNUgqHPZ_g=.e1ce2e54-e225-4966-8f00-b3d1a1b25479@github.com>

On Wed, 10 Nov 2021 09:51:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits: the first commit is generated using `clang-tidy --fix src/hotspot/share/gc/g1/g1CollectedHeap.hpp -checks=modernize-use-override -p build/linux-x64-debug`, and the second commit fixes some indentation issues.
> 
> Test: build

This pull request has now been integrated.

Changeset: 02f79008
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02f79008828b3dcce3bd6492efaa43e99376c0c5
Stats:     52 lines in 1 file changed: 0 ins; 0 del; 52 mod

8276932: G1: Annotate methods with override explicitly in g1CollectedHeap.hpp

Reviewed-by: tschatzl, sjohanss

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

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


From ayang at openjdk.java.net  Mon Nov 15 14:26:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 15 Nov 2021 14:26:35 GMT
Subject: RFR: 8272170: Missing memory barrier when checking active state
 for regions
In-Reply-To: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
References: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
Message-ID: <8jAAv40j1w5797Fch_A0fhg1UXgHawHDdyoClFwEHcA=.471c1ed1-6f91-43cb-81b5-7aa7f60fe293@github.com>

On Wed, 10 Nov 2021 08:37:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this fix to memory visibility race where we miss to make sure that the `HeapRegion` pointer in `HeapRegionManager::_regions` is visible before the "active"-check for that `HeapRegion` can return true?
> 
> I.e. the problem is this (according to my understanding):
> 
> void HeapRegionManager::expand(uint start, uint num_regions, WorkerThreads* pretouch_workers) {
>   commit_regions(start, num_regions, pretouch_workers);
>   for (uint i = start; i < start + num_regions; i++) {
>     HeapRegion* hr = _regions.get_by_index(i);
>     if (hr == NULL) {
>       hr = new_heap_region(i);
>       OrderAccess::storestore();
>       _regions.set_by_index(i, hr);
>       _allocated_heapregions_length = MAX2(_allocated_heapregions_length, i + 1);
>     }
>     G1CollectedHeap::heap()->hr_printer()->commit(hr);
>   }
>   activate_regions(start, num_regions);
> }
> 
> E.g. we first commit the memory, then create a `HeapRegion` instance which we properly guard with a `StoreStore` before assigning it to the `_regions` array. After that at the end we activate the regions (via `activate_regions`), meaning that the contents of the new `HeapRegion*` in the region table are valid.
> These bits in the `_active_regions` bitmap are put with memory barriers (via `par_set_range`).
> 
> In `HeapRegionManager::par_iterate`, if we iterate over the region map, we first check whether the region is available in the `_active_regions` bitmap, and then get and pass on the corresponding `HeapRegion*` to the given closure.
> 
> However there is no memory ordering between reading the available-bit in the `_active_regions` bitmap, so that bit could become visible to the thread iterating over the regions before the contents of the `_region` map itself, in effect passing a `nullptr` to the closure which isn't allowed. (Some details about the debugging session in the CR).
> 
> 
> void HeapRegionManager::par_iterate(HeapRegionClosure* blk, HeapRegionClaimer* hrclaimer, const uint start_index) const {
>   // Every worker will actually look at all regions, skipping over regions that
>   // are currently not committed.
>   // This also (potentially) iterates over regions newly allocated during GC. This
>   // is no problem except for some extra work.
>   const uint n_regions = hrclaimer->n_regions();
>   for (uint count = 0; count < n_regions; count++) {
>     const uint index = (start_index + count) % n_regions;
>     assert(index < n_regions, "sanity");
>     // Skip over unavailable regions
>     if (!is_available(index)) {
>       continue;
>     }
>     HeapRegion* r = _regions.get_by_index(index);
> [...]
>     bool res = blk->do_heap_region(r);
>     if (res) {
>       return;
>     }
>   }
> }
> 
> 
> The suggested fix is to ensure proper memory ordering in `is_available`, i.e. the loads must be ordered correctly.
> 
> I did check a bit around the usage of this method and `is_unavailable`, but I do not think there is a similar issue.
> 
> Testing: test crashed with a frequency of around 1/500, now passing 5k runs
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 14:37:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 14:37:39 GMT
Subject: RFR: 8272170: Missing memory barrier when checking active state
 for regions
In-Reply-To: <8jAAv40j1w5797Fch_A0fhg1UXgHawHDdyoClFwEHcA=.471c1ed1-6f91-43cb-81b5-7aa7f60fe293@github.com>
References: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
 <8jAAv40j1w5797Fch_A0fhg1UXgHawHDdyoClFwEHcA=.471c1ed1-6f91-43cb-81b5-7aa7f60fe293@github.com>
Message-ID: <X6sEdqcpImlVqREe2Y_hSuVSiy9Q7q8MAsNepMWBCMo=.d75952c5-b484-4d98-947b-c8d86b6c4533@github.com>

On Mon, 15 Nov 2021 14:23:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this fix to memory visibility race where we miss to make sure that the `HeapRegion` pointer in `HeapRegionManager::_regions` is visible before the "active"-check for that `HeapRegion` can return true?
>> 
>> I.e. the problem is this (according to my understanding):
>> 
>> void HeapRegionManager::expand(uint start, uint num_regions, WorkerThreads* pretouch_workers) {
>>   commit_regions(start, num_regions, pretouch_workers);
>>   for (uint i = start; i < start + num_regions; i++) {
>>     HeapRegion* hr = _regions.get_by_index(i);
>>     if (hr == NULL) {
>>       hr = new_heap_region(i);
>>       OrderAccess::storestore();
>>       _regions.set_by_index(i, hr);
>>       _allocated_heapregions_length = MAX2(_allocated_heapregions_length, i + 1);
>>     }
>>     G1CollectedHeap::heap()->hr_printer()->commit(hr);
>>   }
>>   activate_regions(start, num_regions);
>> }
>> 
>> E.g. we first commit the memory, then create a `HeapRegion` instance which we properly guard with a `StoreStore` before assigning it to the `_regions` array. After that at the end we activate the regions (via `activate_regions`), meaning that the contents of the new `HeapRegion*` in the region table are valid.
>> These bits in the `_active_regions` bitmap are put with memory barriers (via `par_set_range`).
>> 
>> In `HeapRegionManager::par_iterate`, if we iterate over the region map, we first check whether the region is available in the `_active_regions` bitmap, and then get and pass on the corresponding `HeapRegion*` to the given closure.
>> 
>> However there is no memory ordering between reading the available-bit in the `_active_regions` bitmap, so that bit could become visible to the thread iterating over the regions before the contents of the `_region` map itself, in effect passing a `nullptr` to the closure which isn't allowed. (Some details about the debugging session in the CR).
>> 
>> 
>> void HeapRegionManager::par_iterate(HeapRegionClosure* blk, HeapRegionClaimer* hrclaimer, const uint start_index) const {
>>   // Every worker will actually look at all regions, skipping over regions that
>>   // are currently not committed.
>>   // This also (potentially) iterates over regions newly allocated during GC. This
>>   // is no problem except for some extra work.
>>   const uint n_regions = hrclaimer->n_regions();
>>   for (uint count = 0; count < n_regions; count++) {
>>     const uint index = (start_index + count) % n_regions;
>>     assert(index < n_regions, "sanity");
>>     // Skip over unavailable regions
>>     if (!is_available(index)) {
>>       continue;
>>     }
>>     HeapRegion* r = _regions.get_by_index(index);
>> [...]
>>     bool res = blk->do_heap_region(r);
>>     if (res) {
>>       return;
>>     }
>>   }
>> }
>> 
>> 
>> The suggested fix is to ensure proper memory ordering in `is_available`, i.e. the loads must be ordered correctly.
>> 
>> I did check a bit around the usage of this method and `is_unavailable`, but I do not think there is a similar issue.
>> 
>> Testing: test crashed with a frequency of around 1/500, now passing 5k runs
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 14:37:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 14:37:39 GMT
Subject: Integrated: 8272170: Missing memory barrier when checking active state
 for regions
In-Reply-To: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
References: <dyOa5iJ3RvCFOjmSWjyujESTHqO-Dcu-iIFiiXJGizA=.5e1c3409-cc8f-4b9c-97bd-af31c6756838@github.com>
Message-ID: <v3zpUbDWIZE3rxyjR8buNisCXSKwMrUx_gNq2_vvGds=.781a2132-b0d1-4d3c-a563-df13b3e5f343@github.com>

On Wed, 10 Nov 2021 08:37:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this fix to memory visibility race where we miss to make sure that the `HeapRegion` pointer in `HeapRegionManager::_regions` is visible before the "active"-check for that `HeapRegion` can return true?
> 
> I.e. the problem is this (according to my understanding):
> 
> void HeapRegionManager::expand(uint start, uint num_regions, WorkerThreads* pretouch_workers) {
>   commit_regions(start, num_regions, pretouch_workers);
>   for (uint i = start; i < start + num_regions; i++) {
>     HeapRegion* hr = _regions.get_by_index(i);
>     if (hr == NULL) {
>       hr = new_heap_region(i);
>       OrderAccess::storestore();
>       _regions.set_by_index(i, hr);
>       _allocated_heapregions_length = MAX2(_allocated_heapregions_length, i + 1);
>     }
>     G1CollectedHeap::heap()->hr_printer()->commit(hr);
>   }
>   activate_regions(start, num_regions);
> }
> 
> E.g. we first commit the memory, then create a `HeapRegion` instance which we properly guard with a `StoreStore` before assigning it to the `_regions` array. After that at the end we activate the regions (via `activate_regions`), meaning that the contents of the new `HeapRegion*` in the region table are valid.
> These bits in the `_active_regions` bitmap are put with memory barriers (via `par_set_range`).
> 
> In `HeapRegionManager::par_iterate`, if we iterate over the region map, we first check whether the region is available in the `_active_regions` bitmap, and then get and pass on the corresponding `HeapRegion*` to the given closure.
> 
> However there is no memory ordering between reading the available-bit in the `_active_regions` bitmap, so that bit could become visible to the thread iterating over the regions before the contents of the `_region` map itself, in effect passing a `nullptr` to the closure which isn't allowed. (Some details about the debugging session in the CR).
> 
> 
> void HeapRegionManager::par_iterate(HeapRegionClosure* blk, HeapRegionClaimer* hrclaimer, const uint start_index) const {
>   // Every worker will actually look at all regions, skipping over regions that
>   // are currently not committed.
>   // This also (potentially) iterates over regions newly allocated during GC. This
>   // is no problem except for some extra work.
>   const uint n_regions = hrclaimer->n_regions();
>   for (uint count = 0; count < n_regions; count++) {
>     const uint index = (start_index + count) % n_regions;
>     assert(index < n_regions, "sanity");
>     // Skip over unavailable regions
>     if (!is_available(index)) {
>       continue;
>     }
>     HeapRegion* r = _regions.get_by_index(index);
> [...]
>     bool res = blk->do_heap_region(r);
>     if (res) {
>       return;
>     }
>   }
> }
> 
> 
> The suggested fix is to ensure proper memory ordering in `is_available`, i.e. the loads must be ordered correctly.
> 
> I did check a bit around the usage of this method and `is_unavailable`, but I do not think there is a similar issue.
> 
> Testing: test crashed with a frequency of around 1/500, now passing 5k runs
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 35a831d5
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/35a831d5a755de8f3c71653bd0a37190adddb8ae
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8272170: Missing memory barrier when checking active state for regions

Reviewed-by: sjohanss, ayang

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

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


From ayang at openjdk.java.net  Mon Nov 15 15:43:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 15 Nov 2021 15:43:35 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
Message-ID: <fJKNy1Y597Dj_dKXaWz_X_W-EC4q8qGD34TMjSpHEKQ=.5a291a4f-b061-4621-b2fa-cc45ffd1c1bc@github.com>

On Wed, 10 Nov 2021 10:48:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change that removes some code that is no longer needed.
> 
> **Summary**
> In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.
> 
> This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.
> 
> **Testing**
> 
> - [x] Mach5 1-3
> - [x] Local stress-testing

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 18:12:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 18:12:44 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
Message-ID: <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>

On Thu, 14 Oct 2021 13:25:27 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Vishal Chand has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable
>>  - Changes as per the first set of comments
>
> Are there any problems with waiting a bit for this change on PR#5909?
> [Vishal] No issues. I think it would be a cleaner and better approach. 
> 
> Maybe you are also interested to try out the combination of PR#5909 and this one, allowing card table entry sizes from 128 to 1024 and any combination of region size iirc.
> [Vishal] Yes, I'll try on my end different combinations of card sizes and region sizes. I'll report my observations.
> 
> In PR#5909 there is also the question of how large regions G1 should allow with that - the patch currently allows up to 512M regions, but theoretically there is no limit - do you have any opinion on that?
> [Vishal] Currently, I have no strong opinion regarding the max. region size. I'll run specjbb2015 with different region sizes > 32m with different card sizes. I'll report if I find anything interesting.  
> 
> Thanks,
> Vishal

@vish-chan : the change for PR#5909 has finally been integrated. Sorry for the delay, things like a related bug delayed its integration more than expected.

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 18:12:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 18:12:48 GMT
Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region
 [v8]
In-Reply-To: <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
 <wZEGwq_b1crh1_QJhxM0xdZ-hJkvOI5RoBRQVyrU6T8=.42a1b251-dd9c-4d9c-a082-b1345a9915a1@github.com>
 <RPo7fyQA4JMYscUFM0u_0DzdqTkPARoJjcxaddd-TbI=.f4ded00b-dc73-444d-819c-869ec039792b@github.com>
Message-ID: <uQMqu0bzaJ5U2UbaNCNq9_GOGB7q-KTvQYgZOFQwBrU=.32f8614b-c182-4aad-b0ce-5a9fa6718fc9@github.com>

On Sun, 14 Nov 2021 22:51:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>>  - ayang review1
>>  - Limit ergonomics to 32m regions
>>  - sjohanss review
>>  - Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor
>>  - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2
>>  - 32 bit compatibility - limit region size to 32M there as before. Fix test.
>>  - Virtual heap regions in remembered sets
>
> Just some minor comments/suggestions.

Thanks @albertnetymk @kstefanj for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 18:12:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 18:12:49 GMT
Subject: Integrated: 8275056: Virtualize G1CardSet containers over heap region
In-Reply-To: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
References: <T5tBFVHiGzyNse4otMfIdMYeGeQ92_sfhxV7dW-DZFQ=.ff02a752-01cf-4fe0-b4f4-cdd3770435c7@github.com>
Message-ID: <vduEUszejcd8Gs9SvHT7ChzIhRDF2gIUHb5aNK7pAsA=.9b7556c0-4da8-40a1-b12c-d9f8f36d95ff@github.com>

On Thu, 21 Oct 2021 07:49:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region?
> 
> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`.
> 
> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`).
> 
> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected.
> 
> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?).
> 
> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically.
> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before).
> 
> There is also a CSR to look at.
> 
> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes.
> 
> Thanks,
> Thomas

This pull request has now been integrated.

Changeset: 1830b8da
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1830b8da9028af430ee4791f310b5fc9cb1ff37d
Stats:     242 lines in 12 files changed: 148 ins; 68 del; 26 mod

8275056: Virtualize G1CardSet containers over heap region

Reviewed-by: sjohanss, ayang

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

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


From tschatzl at openjdk.java.net  Mon Nov 15 18:14:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 15 Nov 2021 18:14:43 GMT
Subject: RFR: 8277119: Add asserts in GenericTaskQueueSet methods
In-Reply-To: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
References: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
Message-ID: <ri1a9aLxabrHwzXfEwa4YgrwrIs-t5mV7QJ8z4GmaEg=.238b6ac5-f642-4785-a47f-7e56a0c8ca3e@github.com>

On Mon, 15 Nov 2021 12:31:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Some methods in GenericTaskQueueSet lack of assert, which is not friendly to debug/troubleshooting.
> This is to add necessary asserts.

These look good to me.

May I ask if there is anything in particular you're looking into in this area? I have also been doing some investigation there and particularly wrt to the stealing and task termination found a few significant things to improve.

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

Marked as reviewed by tschatzl (Reviewer).

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


From duke at openjdk.java.net  Mon Nov 15 20:29:59 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Mon, 15 Nov 2021 20:29:59 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v4]
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <5X652ZrAu42hftah-Q5vno-kPojLAi8a14uoLDJEdAA=.9daf3b2a-90eb-40ff-b704-9a7105aa8833@github.com>

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

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

 - Merge branch 'openjdk:master' into card-size-configurable
 - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable
 - Changes as per the first set of comments
 - Changes as per the first set of comments
 - 8272773: Investigate making card table size configurable

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

Changes: https://git.openjdk.java.net/jdk/pull/5838/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=03
  Stats: 139 lines in 15 files changed: 115 ins; 2 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5838.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838

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


From mli at openjdk.java.net  Tue Nov 16 01:17:33 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 16 Nov 2021 01:17:33 GMT
Subject: RFR: 8277119: Add asserts in GenericTaskQueueSet methods
In-Reply-To: <ri1a9aLxabrHwzXfEwa4YgrwrIs-t5mV7QJ8z4GmaEg=.238b6ac5-f642-4785-a47f-7e56a0c8ca3e@github.com>
References: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
 <ri1a9aLxabrHwzXfEwa4YgrwrIs-t5mV7QJ8z4GmaEg=.238b6ac5-f642-4785-a47f-7e56a0c8ca3e@github.com>
Message-ID: <lj3w2n-ONY7rWwTnl_IbD_UwJtJj_wC6HSkP9jFJ8gY=.2f959546-29fe-4c87-841c-4c551abf92e3@github.com>

On Mon, 15 Nov 2021 18:11:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> May I ask if there is anything in particular you're looking into in this area? I have also been doing some investigation there and particularly wrt to the stealing and task termination found a few significant things to improve.

Thanks for sharing and asking. 
Not exactly, I'm working the prototype of https://bugs.openjdk.java.net/browse/JDK-8256265 which is to improve the parallelism of evac failure process. I'm using taskqueue to implement the balance among threads, it took me a while to fix a crash issue which finally prove to be the wrong usage of taskqueue, and I think it would cost me less time if the asserts already existed there.
Please kindly let me know if you think I can help on the things related to "stealing and task termination". :)

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

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


From mli at openjdk.java.net  Tue Nov 16 05:42:40 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 16 Nov 2021 05:42:40 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v3]
In-Reply-To: <jeLFlNxYO7mfNtVfU_sN7ryNRn0lCfPYlpAQFrYf6ps=.dd29181b-b8f0-4814-aea0-a4c51c1bda38@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <ji04p4_3DatadhdMrPEB9ntJPmhc0cali3ybewW6NYs=.a897fea9-87ce-42f3-b660-ef2cc872ac04@github.com>
 <qLZ9b5MRpHR67h5ywZJpUiJ0bm-iF7oGoL71S6vE-IY=.deac2f5e-28c3-40d0-80db-d74ac44505b6@github.com>
 <lc6I54KGniBHMcIO7YetdiUYSaQDS-yw6Y4xB-r5bAo=.946b49df-0353-4e4c-a43f-e7602b2b5eb0@github.com>
 <V_-4d5XrAh-I1CXEs_ZU-7x_HC9-TEOeNQEstKiz3QM=.defe7e45-0daf-4b7c-a922-324bcd189a83@github.com>
 <jeLFlNxYO7mfNtVfU_sN7ryNRn0lCfPYlpAQFrYf6ps=.dd29181b-b8f0-4814-aea0-a4c51c1bda38@github.com>
Message-ID: <VkYJnbYjPVL29NDs-IzliY20OkkE9wL8QPEZJv_P5uw=.8249710e-b160-4620-9739-3188d88dc468@github.com>

On Thu, 11 Nov 2021 09:19:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>>> Thanks Thomas.
>>> 
>>> > I would prefer `G1SegmentedArrayFreePool` here, seeing the segmented array as the important thing (I understand that `G1SegmentedArrayBufferListFreePool` is too long).
>>> 
>>> Sure.
>>> 
>>> > I think there is already a CR to reconsider naming of all these classes,
>>> 
>>> Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?
>> 
>> Yes.
>> 
>>> 
>>> > maybe add `G1SegmentedArrayBufferList` to the ones that need renaming;
>>> 
>>> If you mean 8276299 above, sure I will add this to the renaming list of 8276299.
>>> 
>>> > in particular I think right now that the "BufferList" of `G1SegmentedArrayBufferList` is kind of redundant.
>>> 
>>> Not quite get your point, would you mind to clarify further?
>> 
>> A segmented array is an array consisting of segments (as opposed to a single huge array of something); a list of buffers, where a "buffer" is nothing but an array (of some element type) is almost the same. One is a set of chunks of elements (to explicitly use other words), the other too.
>> 
>>> > It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames.
>>> 
>>> Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?
>> 
>> Not to discuss the idea of renaming, 8276299 is pretty clear about that, but discuss the actual mappings from old name to new name. Maybe this will wake up more people to the discussion than hiding it in a PR :) 
>> 
>>> 
>>> > Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.
>>> 
>>> If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool. Sure, I will start a discussion for 8276299 before actually send the pr.
>> 
>> That's true, but we are renaming something that also contains a "Buffer" in it and seemingly related.
>> 
>> So instead of renaming this `G1BufferListFreePool` again to something else in 8276299, maybe we could save the time and immediately change it to the final name now, then in 8276299 do the same for the other classes.
>> 
>> Then 8276299 will hopefully go through more smoothly too if we already decided on the new names beforehand as well.
>
> Thanks for clarification, I see your point, will initiate an discussion later. :)

Discussion thread is here: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-November/037626.html

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

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


From duke at openjdk.java.net  Tue Nov 16 07:43:43 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Tue, 16 Nov 2021 07:43:43 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
 <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
Message-ID: <4WUlDXS0Oaqy0597CHDui_aSY0QyLEPa17YXOYBZpXM=.c9fdce6a-ad8f-45d6-bc33-4b9a6e97ea20@github.com>

On Mon, 15 Nov 2021 18:09:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Are there any problems with waiting a bit for this change on PR#5909?
>> [Vishal] No issues. I think it would be a cleaner and better approach. 
>> 
>> Maybe you are also interested to try out the combination of PR#5909 and this one, allowing card table entry sizes from 128 to 1024 and any combination of region size iirc.
>> [Vishal] Yes, I'll try on my end different combinations of card sizes and region sizes. I'll report my observations.
>> 
>> In PR#5909 there is also the question of how large regions G1 should allow with that - the patch currently allows up to 512M regions, but theoretically there is no limit - do you have any opinion on that?
>> [Vishal] Currently, I have no strong opinion regarding the max. region size. I'll run specjbb2015 with different region sizes > 32m with different card sizes. I'll report if I find anything interesting.  
>> 
>> Thanks,
>> Vishal
>
> @vish-chan : the change for PR#5909 has finally been integrated. Sorry for the delay, things like a related bug delayed its integration more than expected.

@tschatzl I tested PR#5909 and this change: The combination of 1024b card/512M region is giving 2-3% improvement over 1024b card/32M region in SPECjbb2015 on my setup. I haven't analyzed this is detail though. 

Shall I update the pull request with new patch by:
1. Removing min_card_size code as it is not relevant now.
2. Update minimum card size supported from 512 to 128/256? Need your input on the min card size value and default card size value.

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

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


From kbarrett at openjdk.java.net  Tue Nov 16 08:05:39 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 16 Nov 2021 08:05:39 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v4]
In-Reply-To: <BPPP3oS8d0NMdIxiQewyApX4kEb6N5aq3AGGTK5uY1o=.9f72a2b5-4b66-4650-9d3d-78ab5d1a4e74@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <MnFe4lM9ZWN08id93BlJwy5P--As0QVoGN7oodgCkxQ=.4d5dc6ce-67d0-4a62-a184-c45a4d94774a@github.com>
 <oDd3yWvx2o1V8rVgZ7gEYHbQX0Lpukg_qm_1KBbwycQ=.ee9d4f99-bff3-4069-82aa-37a009b43828@github.com>
 <BPPP3oS8d0NMdIxiQewyApX4kEb6N5aq3AGGTK5uY1o=.9f72a2b5-4b66-4650-9d3d-78ab5d1a4e74@github.com>
Message-ID: <fqh9PqSdt6C4xbglNQ5KCqV5-i-l82zJg_2e3tIcnu4=.fed4eab1-21de-4ba8-93be-23e99f4a2661@github.com>

On Tue, 12 Oct 2021 10:29:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Actually I've kept the names of all the pre-existing constants (which are now variables) same as before. Otherwise we have to change all the references also.
>
> Let's see what the second reviewer thinks. Otherwise this can be done separately as it might hide the interesting part of this change.

Not a review (yet), just a response to these questions.

Public data members are very rare in HotSpot code.  There are a few POD/standard layout classes (examples include G1BufferNodeList and OopStorage::BasicParState::IterationData), but otherwise accessor functions are preferred.  The style-guide says
"Use public accessor functions for member variables accessed outside the class."

The style-guide says this:
"Class data member names have a leading underscore, and use lowercase with words separated by a single underscore (_foo_bar)."
It makes no distinction for public or not, or for static or not.  That is intentional, based on some discussion about that question when I was updating the style-guide a while ago.

Of course, there are probably counter-examples to both of these lurking in the code base.

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

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


From tschatzl at openjdk.java.net  Tue Nov 16 08:28:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 16 Nov 2021 08:28:42 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
 <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
Message-ID: <K7jsCs1jH5KCgaNJEPFAia2Ic6ythCCSwlTNxk00iqM=.514ae6e5-b81e-4734-89da-1d552a15a58c@github.com>

On Mon, 15 Nov 2021 18:09:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Are there any problems with waiting a bit for this change on PR#5909?
>> [Vishal] No issues. I think it would be a cleaner and better approach. 
>> 
>> Maybe you are also interested to try out the combination of PR#5909 and this one, allowing card table entry sizes from 128 to 1024 and any combination of region size iirc.
>> [Vishal] Yes, I'll try on my end different combinations of card sizes and region sizes. I'll report my observations.
>> 
>> In PR#5909 there is also the question of how large regions G1 should allow with that - the patch currently allows up to 512M regions, but theoretically there is no limit - do you have any opinion on that?
>> [Vishal] Currently, I have no strong opinion regarding the max. region size. I'll run specjbb2015 with different region sizes > 32m with different card sizes. I'll report if I find anything interesting.  
>> 
>> Thanks,
>> Vishal
>
> @vish-chan : the change for PR#5909 has finally been integrated. Sorry for the delay, things like a related bug delayed its integration more than expected.

> @tschatzl I tested PR#5909 and this change: The combination of 1024b card/512M region is giving 2-3% improvement over 1024b card/32M region in SPECjbb2015 on my setup. I haven't analyzed this is detail though.

Good that the changed did not optimize away the improvements.

> 
> Shall I update the pull request with new patch by:
> 
>     1. Removing min_card_size code as it is not relevant now.

Please do. It is unnecessary now as there are no limitations of the combination of card size/region size for G1 any more.

> 
>     2. Update minimum card size supported from 512 to 128/256? Need your input on the min card size value and default card size value.

I'd say make the minimum default. I looked a bit through literature, and the suggestion is that the minimum size used seems 128 bytes. That might be useful for smallish heaps.

Thanks,
  Thomas

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

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


From sjohanss at openjdk.java.net  Tue Nov 16 08:30:42 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 16 Nov 2021 08:30:42 GMT
Subject: RFR: 8276229: Stop allowing implicit updates in G1BlockOffsetTable
In-Reply-To: <IClHlaYIdHNm_9a3S8vYV5Fan5JKblv0q2iQk2KOdeA=.0f65360f-27de-45de-9d66-e9dbcf9e23c7@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
 <IClHlaYIdHNm_9a3S8vYV5Fan5JKblv0q2iQk2KOdeA=.0f65360f-27de-45de-9d66-e9dbcf9e23c7@github.com>
Message-ID: <6Rb_1TFZiyXA05kREIyBaS_KUgON8RG9uTwZP_vPpXY=.1a04018a-defe-4c60-b78c-d70e56626327@github.com>

On Wed, 10 Nov 2021 13:42:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change that removes some code that is no longer needed.
>> 
>> **Summary**
>> In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.
>> 
>> This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.
>> 
>> **Testing**
>> 
>> - [x] Mach5 1-3
>> - [x] Local stress-testing
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks @tschatzl and @albertnetymk for the reviews.

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

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


From sjohanss at openjdk.java.net  Tue Nov 16 08:30:43 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 16 Nov 2021 08:30:43 GMT
Subject: Integrated: 8276229: Stop allowing implicit updates in
 G1BlockOffsetTable
In-Reply-To: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
References: <4uO8rh-ZvU2bKaXW9qgee7VdG6vRO_kNm4wIH91Kma4=.830b300e-6c53-40a3-ab65-955524352add@github.com>
Message-ID: <crt9JhSxKeetmG9tGn3BQJN7LhN_r-EMVMCPAqYYgLI=.880851ba-a14f-4438-9d5e-a2772cc43208@github.com>

On Wed, 10 Nov 2021 10:48:24 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change that removes some code that is no longer needed.
> 
> **Summary**
> In [JDK-8272083](https://bugs.openjdk.java.net/browse/JDK-8276229) G1 was changed to create a precise and complete BOT during evacuation (in the GC pause). This removes the need to update the BOT when looking up block starts. This previously happened in concurrent refinement and while scanning the heap in the pause, but with the precise BOT we should no longer require any such updates.
> 
> This change removes the slow path function that did the updates `forward_to_block_containing_addr_slow(...)`. It also renames some functions to no longer include a `_const` post-fix because there are only "const" versions of the functions remaining.
> 
> **Testing**
> 
> - [x] Mach5 1-3
> - [x] Local stress-testing

This pull request has now been integrated.

Changeset: 1d79cfd3
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1d79cfd3a16a71ec1bf93a0748e806b21a717b52
Stats:     95 lines in 4 files changed: 8 ins; 81 del; 6 mod

8276229: Stop allowing implicit updates in G1BlockOffsetTable

Reviewed-by: tschatzl, ayang

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

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


From tschatzl at openjdk.java.net  Tue Nov 16 08:33:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 16 Nov 2021 08:33:42 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <yPRSgw-hKaeEaTBFLgAQML-cJYON3rWmGOxL60E_xrc=.a25a97f3-a2f3-48e3-ac1f-6855236e69da@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <yPRSgw-hKaeEaTBFLgAQML-cJYON3rWmGOxL60E_xrc=.a25a97f3-a2f3-48e3-ac1f-6855236e69da@github.com>
Message-ID: <lUr6XbtbwSm7UQ8zTxg8hy0zn94dnuyNSIGfraPrv0Q=.ef7f4517-f022-4cce-9b3b-41bea8414912@github.com>

On Wed, 13 Oct 2021 10:50:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Vishal Chand has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable
>>  - Changes as per the first set of comments
>
> src/hotspot/share/gc/parallel/objectStartArray.hpp line 60:
> 
>> 58: 
>> 59:   // This maximum is derived from that we need an extra bit for possible
>> 60:   // offsets in the byte for backskip values (this is a hard limit)
> 
> Suggestion:
> 
>   // Maximum size an offset table entry can cover. This maximum is derived from that we need an extra bit for possible
>   // offsets in the byte for backskip values, leaving 2^7 possible offsets. Mininum object alignment is 8 bytes (2^3), so we can at most represent 2^10 offsets within a BOT value.
> 
> 
> (We *could* make this maximum dependent on `ObjectAlignmentInBytes`, but I do not know if increasing ObjectAlignmentInBytes gives any advantage. So at most defer this investigation to some other time as I'm already keeping busy some machines)

Maybe it is interesting to make this size depend on current `ObjectAlignmentInBytes` after all. I've seen some recent testing where it proved useful. However that may be done as a separate change.
It also seems that reducing the size of the BOT/card table (increasing this maximum) has diminishing returns e.g. wrt to Card Table Clear times.

Maybe it is interesting for you to try out even larger card sizes though (e.g. an `ObjectAlignmentInBytes` value of `16` should allow a card size of 2048 and so on).

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

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


From mli at openjdk.java.net  Tue Nov 16 09:23:39 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 16 Nov 2021 09:23:39 GMT
Subject: RFR: 8277119: Add asserts in GenericTaskQueueSet methods
In-Reply-To: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
References: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
Message-ID: <2Np3JC0H_ySXWNwp7UsmtlaCbHVVB-GLDiz42N0DgRk=.b3ab6151-4e9a-48f9-91f5-f109bd248c12@github.com>

On Mon, 15 Nov 2021 12:31:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Some methods in GenericTaskQueueSet lack of assert, which is not friendly to debug/troubleshooting.
> This is to add necessary asserts.

I think this one is trivial, am I good to push?

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

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


From thomas.schatzl at oracle.com  Tue Nov 16 09:38:28 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 16 Nov 2021 10:38:28 +0100
Subject: Discussion about unifying the wording buffer/node/element in G1, 
 especially classes using G1SegmentedArray and related classes
In-Reply-To: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
Message-ID: <9fa41487-d015-4acc-e2e3-2693cd171a13@oracle.com>

Hi,

On 12.11.21 09:23, lihuaming (A) wrote:
> Hi all,
> 
> May I have your attention to discuss about unifying the wording buffer/node/element in G1, especially classes using G1SegmentedArray and related classes.
> 
> Background: Currently, the words "buffer", "node" and "element" are used together in G1SegmentedArrayXxx, G1CardSetXxx and related classes in an inconsistent way, which is very unfavorable for understanding. We should not confuse buffer and node together, and not confuse node and element together. The new wording should be based on something like the following rule: A segmented array consists of several buffers one of which consists of several element (or node? we should choose one of element or node).
> 
> I propose to use "segmented array -> buffer -> elem/element", the reasons are: first, "node" is used as memory node, numa node, which is used in lots of other places, e.g. heapRegion, heapRegionSet, G1Allocator,..., while "buffer + node" together is used as buffer in BufferNode/G1BufferNodeList (these classes will not be changes), so "node" should not be used as "element"; In G1CardSet and G1CardSetContainer, most of comments/variables use "elem" rather than "node" for single element.

Thanks for writing this up. As the one primarily responsible for this 
mess, thank you for looking into this.

I'm good with "Segmented Array" -> "Buffer" -> "Element".

Please wait one or two days for additional comments.

Thanks,
   Thomas


From tschatzl at openjdk.java.net  Tue Nov 16 09:41:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 16 Nov 2021 09:41:39 GMT
Subject: RFR: 8277119: Add asserts in GenericTaskQueueSet methods
In-Reply-To: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
References: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
Message-ID: <qHwx8aZBiu_U3WOf-o85yQHnbbVxR1PUq465GdSxYOY=.7767e35c-e34b-4907-a5d9-3f772c35fcaa@github.com>

On Mon, 15 Nov 2021 12:31:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Some methods in GenericTaskQueueSet lack of assert, which is not friendly to debug/troubleshooting.
> This is to add necessary asserts.

Yes I'm fine for this to be pushed with one reviewer. Go ahead to integrate.

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

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


From duke at openjdk.java.net  Tue Nov 16 11:40:36 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Tue, 16 Nov 2021 11:40:36 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <lUr6XbtbwSm7UQ8zTxg8hy0zn94dnuyNSIGfraPrv0Q=.ef7f4517-f022-4cce-9b3b-41bea8414912@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <yPRSgw-hKaeEaTBFLgAQML-cJYON3rWmGOxL60E_xrc=.a25a97f3-a2f3-48e3-ac1f-6855236e69da@github.com>
 <lUr6XbtbwSm7UQ8zTxg8hy0zn94dnuyNSIGfraPrv0Q=.ef7f4517-f022-4cce-9b3b-41bea8414912@github.com>
Message-ID: <vvcbTN4VBJdMy_zKv0WQS6eObKRUerWgoq5C1DmNSo4=.76c81bb8-8416-4d6d-8a4b-0a74c709b198@github.com>

On Tue, 16 Nov 2021 08:30:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/objectStartArray.hpp line 60:
>> 
>>> 58: 
>>> 59:   // This maximum is derived from that we need an extra bit for possible
>>> 60:   // offsets in the byte for backskip values (this is a hard limit)
>> 
>> Suggestion:
>> 
>>   // Maximum size an offset table entry can cover. This maximum is derived from that we need an extra bit for possible
>>   // offsets in the byte for backskip values, leaving 2^7 possible offsets. Mininum object alignment is 8 bytes (2^3), so we can at most represent 2^10 offsets within a BOT value.
>> 
>> 
>> (We *could* make this maximum dependent on `ObjectAlignmentInBytes`, but I do not know if increasing ObjectAlignmentInBytes gives any advantage. So at most defer this investigation to some other time as I'm already keeping busy some machines)
>
> Maybe it is interesting to make this size depend on current `ObjectAlignmentInBytes` after all. I've seen some recent testing where it proved useful. However that may be done as a separate change.
> It also seems that reducing the size of the BOT/card table (increasing this maximum) has diminishing returns e.g. wrt to Card Table Clear times.
> 
> Maybe it is interesting for you to try out even larger card sizes though (e.g. an `ObjectAlignmentInBytes` value of `16` should allow a card size of 2048 and so on).

Sure. I'll explore this and share the results.

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

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


From mli at openjdk.java.net  Tue Nov 16 11:40:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 16 Nov 2021 11:40:38 GMT
Subject: RFR: 8277119: Add asserts in GenericTaskQueueSet methods
In-Reply-To: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
References: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
Message-ID: <gi1QveJhfIgyplBN71EeBWeJ15W5T5hYqSqx7dQXuo0=.14691dd4-a58d-495d-8b81-671319570698@github.com>

On Mon, 15 Nov 2021 12:31:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Some methods in GenericTaskQueueSet lack of assert, which is not friendly to debug/troubleshooting.
> This is to add necessary asserts.

Thanks Thomas for your confirmation and review.

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

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


From mli at openjdk.java.net  Tue Nov 16 11:40:39 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 16 Nov 2021 11:40:39 GMT
Subject: Integrated: 8277119: Add asserts in GenericTaskQueueSet methods
In-Reply-To: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
References: <GxSAG4ehZVoGnbg8Cfwk3uMlFHZXAJxNDgOH0DQPMu8=.11c70703-4cb5-4505-ac16-cc3f19cc9982@github.com>
Message-ID: <58UgAFhaTVBr9AgbnxBX18CKlj7NBfm50K4IQXPmQz8=.96fa8d9e-9fce-4ef6-9567-7280fd440c4b@github.com>

On Mon, 15 Nov 2021 12:31:48 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Some methods in GenericTaskQueueSet lack of assert, which is not friendly to debug/troubleshooting.
> This is to add necessary asserts.

This pull request has now been integrated.

Changeset: 7906eb05
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7906eb050d4675092536048e8e21334767e397e6
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8277119: Add asserts in GenericTaskQueueSet methods

Reviewed-by: tschatzl

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

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


From ayang at openjdk.java.net  Tue Nov 16 15:47:55 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 16 Nov 2021 15:47:55 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor args
Message-ID: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>

Simple change of dropping one arg in the constructor.

Test: hotspot_gc

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

Commit messages:
 - ref-ctor

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

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


From ayang at openjdk.java.net  Tue Nov 16 15:59:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 16 Nov 2021 15:59:49 GMT
Subject: RFR: 8277221: G1: Remove methods without implementations in
 G1CollectedHeap
Message-ID: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>

Trivial change of removing dead code.

Test: build

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

Commit messages:
 - trivial

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

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


From tschatzl at openjdk.java.net  Tue Nov 16 16:04:40 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 16 Nov 2021 16:04:40 GMT
Subject: RFR: 8277221: G1: Remove methods without implementations in
 G1CollectedHeap
In-Reply-To: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>
References: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>
Message-ID: <NPLhQgq_Zi8EaDb04cHu981l95OKDkSMQ9cqSlj92xQ=.b381d504-f402-4ddf-befe-259a3b9630a3@github.com>

On Tue, 16 Nov 2021 15:55:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Nov 16 16:28:35 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 16 Nov 2021 16:28:35 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor
 args
In-Reply-To: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
Message-ID: <JVRQov9OJGfe_XUzYxKF_VRBrp-ikS_10ja9vhgVxyE=.3b2cbc61-5d92-4a13-b263-bb7e7b0b870b@github.com>

On Tue, 16 Nov 2021 15:39:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of dropping one arg in the constructor.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Wed Nov 17 10:03:40 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 17 Nov 2021 10:03:40 GMT
Subject: RFR: 8277221: G1: Remove methods without implementations in
 G1CollectedHeap
In-Reply-To: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>
References: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>
Message-ID: <KO01Uqnq6aEuICfz80cgtrAyvuY50ZPJ-9B7Gj6IoeA=.d8779b7e-8b96-4dd6-ad5e-ffff6123c7ed@github.com>

On Tue, 16 Nov 2021 15:55:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Nov 17 10:03:41 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 17 Nov 2021 10:03:41 GMT
Subject: Integrated: 8277221: G1: Remove methods without implementations in
 G1CollectedHeap
In-Reply-To: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>
References: <KdpVEqHm9nH_YSKrnXA7hI3MDtxsTxqVisoPHBjGnnk=.75d5d649-586f-4b50-9cf0-e88cf7413020@github.com>
Message-ID: <FmduOP1AqWdKhDe5vKQJKLJfn6kECAin12n2ENhWK5Q=.928116a9-b791-46c9-84b9-734aa7485b7e@github.com>

On Tue, 16 Nov 2021 15:55:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: e9934e12
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e9934e1243929514e147ecdd3cefa74168ed0500
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8277221: G1: Remove methods without implementations in G1CollectedHeap

Reviewed-by: tschatzl

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

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


From duke at openjdk.java.net  Wed Nov 17 12:25:00 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Wed, 17 Nov 2021 12:25:00 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v5]
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <rpITYNVcNJkLTb5AC12K9Z9V8Krf8Yp6SgL-5u8MObc=.dc3779b4-bd0b-4b89-becb-ad033e227ebb@github.com>

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

Vishal Chand has updated the pull request incrementally with three additional commits since the last revision:

 - Remove G1 region size and card size dependency
 - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable
 - Merge branch 'master' of https://github.com/vish-chan/jdk into card-size-configurable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5838/files
  - new: https://git.openjdk.java.net/jdk/pull/5838/files/9d02c66b..1f0612a1

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

  Stats: 38 lines in 8 files changed: 1 ins; 23 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5838.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838

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


From tschatzl at openjdk.java.net  Wed Nov 17 13:17:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 17 Nov 2021 13:17:50 GMT
Subject: RFR: 8276093: Improve naming in closures to iterate over card sets
Message-ID: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>

Hi all,

  can I have reviews for this renaming change that tries to change naming for some remembered set closures to include `Closure` instead of `Iterator` in their names. Additionally I removed two or so `G1` prefixes for nested classes. Hopefully this improves the situation a bit, although it's still a mess of nested closures.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - first attempt

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

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


From duke at openjdk.java.net  Wed Nov 17 15:01:49 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Wed, 17 Nov 2021 15:01:49 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <K7jsCs1jH5KCgaNJEPFAia2Ic6ythCCSwlTNxk00iqM=.514ae6e5-b81e-4734-89da-1d552a15a58c@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
 <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
 <K7jsCs1jH5KCgaNJEPFAia2Ic6ythCCSwlTNxk00iqM=.514ae6e5-b81e-4734-89da-1d552a15a58c@github.com>
Message-ID: <s4FXAH7sHIXHRAw_EMuoY4pbNi6RFwXIFfnRHKBfvIs=.0ca9d313-9b53-48e5-966a-4a3dd5bda60d@github.com>

On Tue, 16 Nov 2021 08:26:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> @vish-chan : the change for PR#5909 has finally been integrated. Sorry for the delay, things like a related bug delayed its integration more than expected.
>
>> @tschatzl I tested PR#5909 and this change: The combination of 1024b card/512M region is giving 2-3% improvement over 1024b card/32M region in SPECjbb2015 on my setup. I haven't analyzed this is detail though.
> 
> Good that the changed did not optimize away the improvements.
> 
>> 
>> Shall I update the pull request with new patch by:
>> 
>>     1. Removing min_card_size code as it is not relevant now.
> 
> Please do. It is unnecessary now as there are no limitations of the combination of card size/region size for G1 any more.
> 
>> 
>>     2. Update minimum card size supported from 512 to 128/256? Need your input on the min card size value and default card size value.
> 
> I'd say keep 512 bytes default. I looked a bit through literature, and the suggestion is that the minimum size used seems 128 bytes. That might be useful for smallish heaps.
> 
> Thanks,
>   Thomas
> 
> Edit: I messed up with the default value, @vish-chan, please keep 512 default.

@tschatzl I've updated the PR with a new patch: Removed the dependency of G1 heap region and card size. Set card size in [128. 1024] with 512 as default.

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

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


From tschatzl at openjdk.java.net  Wed Nov 17 15:25:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 17 Nov 2021 15:25:44 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v5]
In-Reply-To: <rpITYNVcNJkLTb5AC12K9Z9V8Krf8Yp6SgL-5u8MObc=.dc3779b4-bd0b-4b89-becb-ad033e227ebb@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <rpITYNVcNJkLTb5AC12K9Z9V8Krf8Yp6SgL-5u8MObc=.dc3779b4-bd0b-4b89-becb-ad033e227ebb@github.com>
Message-ID: <AbMTNZNHnRiDTXIbKMJV3YiKaRL7vkgWS8NOOKGP2Qc=.0a0317b9-9d2f-4091-96ab-551610b08db7@github.com>

On Wed, 17 Nov 2021 12:25:00 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove G1 region size and card size dependency
>  - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable
>  - Merge branch 'master' of https://github.com/vish-chan/jdk into card-size-configurable

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/objectStartArray.hpp line 61:

> 59:   // Maximum size an offset table entry can cover. This maximum is derived from that
> 60:   // we need an extra bit for possible offsets in the byte for backskip values, leaving 2^7 possible offsets.
> 61:   // Mininum object alignment is 8 bytes (2^3), so we can at most represent 2^10 offsets within a BOT value.

s/Mininum/Minimum/

src/hotspot/share/gc/parallel/objectStartArray.hpp line 62:

> 60:   // we need an extra bit for possible offsets in the byte for backskip values, leaving 2^7 possible offsets.
> 61:   // Mininum object alignment is 8 bytes (2^3), so we can at most represent 2^10 offsets within a BOT value.
> 62:   static const uint _max_block_size = 1024;

Static consts should be CamelCased.
Suggestion:

  static const uint MaxBlockSize = 1024;

src/hotspot/share/gc/shared/cardTable.cpp line 30:

> 28: #include "gc/shared/space.inline.hpp"
> 29: #include "gc/shared/gcLogPrecious.hpp"
> 30: #include "gc/parallel/objectStartArray.hpp"

This include is in the wrong order and should probably be guarded by `#if INCLUDE_PARALLELGC`.

src/hotspot/share/gc/shared/cardTable.cpp line 35:

> 33: #include "runtime/java.hpp"
> 34: #include "runtime/os.hpp"
> 35: #include "runtime/globals_extension.hpp"

I think we typically include the globals include that contains the flag - this should probably be `#include "gc/shared/gc_globals.hpp` (and sorted correctly in this list).

src/hotspot/share/gc/shared/cardTable.cpp line 47:

> 45:          "Initialize card size should only be called by card based collectors.");
> 46: 
> 47:   // Card size is the max. of minimum permissible value and GCCardSizeInBytes

Outdated comment. Remove.

src/hotspot/share/gc/shared/cardTable.cpp line 457:

> 455: uintx CardTable::ct_max_alignment_constraint() {
> 456:   // CardTable max alignment is computed with _card_size_max
> 457:   return _card_size_max * os::vm_page_size();

If the constraint were `AtParse`, the code could directly use `GCCardSizeInBytes`. Without needing to increase the minimum heap size.

src/hotspot/share/gc/shared/cardTable.hpp line 236:

> 234:   static uint card_size_in_words;
> 235: 
> 236:   // max permissible card size

s/max/Maximum

src/hotspot/share/gc/shared/gc_globals.hpp line 700:

> 698:           "Card table entry size (in bytes) for card based collectors")     \
> 699:           range(128, 1024)                                                  \
> 700:           constraint(GCCardSizeInBytesConstraintFunc, AfterErgo)            \

Suggestion:

          constraint(GCCardSizeInBytesConstraintFunc,AtParse)

Before `AfterErgo` there should be no space as in other constraints in this file. Also, since it is the last item in the macro, there is no need to have the `` at the very end.
If this constraint were made `AtParse` as suggested, then we can use the actual value of `GCCardSize` in the `ct_alignment_constraint()` function, not requiring a minimum heap size of 4MB (on x86), i.e. a doubling of minimum heap size.

src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 429:

> 427: JVMFlag::Error GCCardSizeInBytesConstraintFunc(uint value, bool verbose) {
> 428:   if(!(UseG1GC || UseParallelGC || UseSerialGC))
> 429:     return JVMFlag::SUCCESS;

Please remove this check - if we are doing the constraint check at parse time, the `Use***GC` flags have not been set. It does not hurt to do the unnecessary check either even a GC does not support that option.

src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 432:

> 430:   if (!is_power_of_2(value)) {
> 431:     JVMFlag::printError(verbose,
> 432:                         "GCCardSizeInBytes (" UINT32_FORMAT ") must be "

Please use `%u` instead of `UINT32_FORMAT`.

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

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


From tschatzl at openjdk.java.net  Wed Nov 17 15:25:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 17 Nov 2021 15:25:44 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v5]
In-Reply-To: <fqh9PqSdt6C4xbglNQ5KCqV5-i-l82zJg_2e3tIcnu4=.fed4eab1-21de-4ba8-93be-23e99f4a2661@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <MnFe4lM9ZWN08id93BlJwy5P--As0QVoGN7oodgCkxQ=.4d5dc6ce-67d0-4a62-a184-c45a4d94774a@github.com>
 <oDd3yWvx2o1V8rVgZ7gEYHbQX0Lpukg_qm_1KBbwycQ=.ee9d4f99-bff3-4069-82aa-37a009b43828@github.com>
 <BPPP3oS8d0NMdIxiQewyApX4kEb6N5aq3AGGTK5uY1o=.9f72a2b5-4b66-4650-9d3d-78ab5d1a4e74@github.com>
 <fqh9PqSdt6C4xbglNQ5KCqV5-i-l82zJg_2e3tIcnu4=.fed4eab1-21de-4ba8-93be-23e99f4a2661@github.com>
Message-ID: <alzIYhT6iMZ_DTKAqIKA4pWr8xZRb2xq1NJQdN5aky8=.d6d6ca64-1bc9-4354-88fd-3d19d5ea48ee@github.com>

On Tue, 16 Nov 2021 08:02:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Let's see what the second reviewer thinks. Otherwise this can be done separately as it might hide the interesting part of this change.
>
> Not a review (yet), just a response to these questions.
> 
> Public data members are very rare in HotSpot code.  There are a few POD/standard layout classes (examples include G1BufferNodeList and OopStorage::BasicParState::IterationData), but otherwise accessor functions are preferred.  The style-guide says
> "Use public accessor functions for member variables accessed outside the class."
> 
> The style-guide says this:
> "Class data member names have a leading underscore, and use lowercase with words separated by a single underscore (_foo_bar)."
> It makes no distinction for public or not, or for static or not.  That is intentional, based on some discussion about that question when I was updating the style-guide a while ago.
> 
> Of course, there are probably counter-examples to both of these lurking in the code base.

I would prefer if this introduction of getters were moved to an extra CR, but I'm good to do that now as well; not so much a problem with the `block_*` ones, more with the ones in `CardTable` that add lots of noise.

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

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


From ayang at openjdk.java.net  Wed Nov 17 15:49:48 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 17 Nov 2021 15:49:48 GMT
Subject: RFR: 8277336: Improve CollectedHeap::safepoint_workers comments
Message-ID: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>

Simple change of updating comments.

Test: build

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

Commit messages:
 - safepoint_workers_comment

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

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


From sjohanss at openjdk.java.net  Wed Nov 17 16:59:43 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 17 Nov 2021 16:59:43 GMT
Subject: RFR: 8277336: Improve CollectedHeap::safepoint_workers comments
In-Reply-To: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
References: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
Message-ID: <bIIr00QZ1YmCsa11pu3zjXQdIWjtpMo4LCnIzMZHiEI=.95bc5fac-f38e-49bc-a0a9-f9bdae2b2ffc@github.com>

On Wed, 17 Nov 2021 15:32:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of updating comments.
> 
> Test: build

Marked as reviewed by sjohanss (Reviewer).

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

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


From sjohanss at openjdk.java.net  Wed Nov 17 17:32:16 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 17 Nov 2021 17:32:16 GMT
Subject: RFR: 8276093: Improve naming in closures to iterate over card sets
In-Reply-To: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
References: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
Message-ID: <xbZo5IEywfDujEXPbyA11fOhRK7UoBDl4LaaJK0I6NI=.18b98a9c-8431-4bd8-b93b-8af2e7ac1c68@github.com>

On Wed, 17 Nov 2021 13:10:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this renaming change that tries to change naming for some remembered set closures to include `Closure` instead of `Iterator` in their names. Additionally I removed two or so `G1` prefixes for nested classes. Hopefully this improves the situation a bit, although it's still a mess of nested closures.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Looks good, some additional iter -> closure renames suggested below.

src/hotspot/share/gc/g1/g1CardSet.cpp line 824:

> 822: }
> 823: 
> 824: void G1CardSet::iterate_containers(CardSetPtrClosure* found, bool at_safepoint) {

Please change `found` to closure or cl as well.

src/hotspot/share/gc/g1/g1CardSet.cpp line 839:

> 837: 
> 838: public:
> 839:   G1ContainerCardsClosure(Closure& iter, uint region_idx) : _iter(iter), _region_idx(region_idx) { }

Maybe change `_iter` and `iter` to `_closure` and `closure`?

src/hotspot/share/gc/g1/g1CardSet.cpp line 861:

> 859: public:
> 860: 
> 861:   G1CardSetContainersClosure(G1CardSet* card_set,

Same as above.

src/hotspot/share/gc/g1/g1CardSet.cpp line 872:

> 870: };
> 871: 
> 872: void G1CardSet::iterate_cards(CardClosure& iter) {

iter -> closure

src/hotspot/share/gc/g1/g1CardSet.hpp line 363:

> 361:   };
> 362: 
> 363:   void iterate_containers(CardSetPtrClosure* iter, bool safepoint = false);

iter -> closure

src/hotspot/share/gc/g1/g1CardSet.hpp line 370:

> 368:   };
> 369: 
> 370:   void iterate_cards(CardClosure& iter);

iter -> closure

src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 90:

> 88: public:
> 89: 
> 90:   G1HeapRegionRemSetMergeCardClosure(G1CardSet* card_set,

`(_)iter` -> `(_)closure`

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Wed Nov 17 17:49:58 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 17 Nov 2021 17:49:58 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor
 args
In-Reply-To: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
Message-ID: <ZiLVAdhRqzEkeE3e_SDYIHh8n8_OO9fEy4uKuAShNuE=.115cbbb1-9252-4b22-9b01-282abc2eff80@github.com>

On Tue, 16 Nov 2021 15:39:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of dropping one arg in the constructor.
> 
> Test: hotspot_gc

For Parallel where we always passed in `true` as `mt_degree` we will now get `_discovery_is_mt` = false for ParallelGCThreads = 1. Not sure if this matters, but it is a change in behavior, right?

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

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


From sjohanss at openjdk.java.net  Wed Nov 17 17:50:37 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 17 Nov 2021 17:50:37 GMT
Subject: RFR: 8277045: G1: Remove unnecessary set_concurrency call in
 G1ConcurrentMark::weak_refs_work
In-Reply-To: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
References: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
Message-ID: <h2hQkvDtuRad0nvtjg2kmbBXhe0MpDo9SKQzu9sH4x8=.18826304-3545-4260-9424-6f6ed0c0c486@github.com>

On Fri, 12 Nov 2021 12:23:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary method call.
> 
> Test: hotspot_gc

+1

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

Marked as reviewed by sjohanss (Reviewer).

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


From ayang at openjdk.java.net  Wed Nov 17 18:30:37 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 17 Nov 2021 18:30:37 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor
 args
In-Reply-To: <ZiLVAdhRqzEkeE3e_SDYIHh8n8_OO9fEy4uKuAShNuE=.115cbbb1-9252-4b22-9b01-282abc2eff80@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
 <ZiLVAdhRqzEkeE3e_SDYIHh8n8_OO9fEy4uKuAShNuE=.115cbbb1-9252-4b22-9b01-282abc2eff80@github.com>
Message-ID: <BoGf6fre5Y6VYVufwEejLpkgSsdZV9qzPIKiVojXJjo=.c2e17fcb-90b7-4e80-92c9-675e8a369ffe@github.com>

On Wed, 17 Nov 2021 17:46:55 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> it is a change in behavior

The value of `_discovery_is_mt` is different, but the external behavior is the same. `ReferenceProcessor::get_discovered_list` will have `id == 0` in both cases, returning the same discovered list.

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

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


From albert.m.yang at oracle.com  Wed Nov 17 19:09:32 2021
From: albert.m.yang at oracle.com (Albert Yang)
Date: Wed, 17 Nov 2021 19:09:32 +0000
Subject: Discussion about unifying the wording buffer/node/element in G1, 
 especially classes using G1SegmentedArray and related classes
In-Reply-To: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
Message-ID: <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>

> A segmented array consists of several buffers one of which consists of several element (or node? we should choose one of element or node).

The term "buffer", to me, means a memory area used to hold data temporarily before data can be properly consumed, such as read/write buffers. Looking at the internals of `class G1SegmentedArrayBuffer`, I think it is essentially a dynamically-allocated array.

"element" often refers to an item, not the container. Maybe a more accurate word here is "slot".

Therefore, my 2 cents: a segment array consists of several singly-linked subarray of potentially different length and potentially different slot size.

/Albert

From tschatzl at openjdk.java.net  Wed Nov 17 20:34:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 17 Nov 2021 20:34:22 GMT
Subject: RFR: 8276093: Improve naming in closures to iterate over card sets
 [v2]
In-Reply-To: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
References: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
Message-ID: <XuBpnp8Y_x19Smwp_Qq9hJ0q4vn7YyNCBr6Iqfk-H-g=.72e3643c-0697-424a-9ae4-c4a999adf1ef@github.com>

> Hi all,
> 
>   can I have reviews for this renaming change that tries to change naming for some remembered set closures to include `Closure` instead of `Iterator` in their names. Additionally I removed two or so `G1` prefixes for nested classes. Hopefully this improves the situation a bit, although it's still a mess of nested closures.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  parameter names

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6430/files
  - new: https://git.openjdk.java.net/jdk/pull/6430/files/455488f8..de89746f

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

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

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


From ayang at openjdk.java.net  Wed Nov 17 21:04:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 17 Nov 2021 21:04:49 GMT
Subject: RFR: 8277045: G1: Remove unnecessary set_concurrency call in
 G1ConcurrentMark::weak_refs_work
In-Reply-To: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
References: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
Message-ID: <04XZGtRo6JswO3vWUwRTeQIuDHNrXExrZLOiLF5lh_0=.9c513832-6d69-4c7d-bde5-bcdf62ad0c5b@github.com>

On Fri, 12 Nov 2021 12:23:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary method call.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Nov 17 21:04:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 17 Nov 2021 21:04:49 GMT
Subject: Integrated: 8277045: G1: Remove unnecessary set_concurrency call in
 G1ConcurrentMark::weak_refs_work
In-Reply-To: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
References: <LQhMMbWT0KcL_lmLAMuLKx_agKukbf9c124zBTSpOeM=.eeff28c9-1d14-4793-83b7-df93b872f059@github.com>
Message-ID: <KTkSIJKxjNJ3X3LGekoBXsGMavVALNzAtJBKIvylD_A=.7d0ba78b-11cf-463d-aeb5-a9de7e9a597f@github.com>

On Fri, 12 Nov 2021 12:23:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary method call.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 45a60db5
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45a60db5a0aa78fa9eb1c2899bd167c136e0fa03
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8277045: G1: Remove unnecessary set_concurrency call in G1ConcurrentMark::weak_refs_work

Reviewed-by: tschatzl, sjohanss

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

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


From tschatzl at openjdk.java.net  Wed Nov 17 22:04:41 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 17 Nov 2021 22:04:41 GMT
Subject: RFR: 8277336: Improve CollectedHeap::safepoint_workers comments
In-Reply-To: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
References: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
Message-ID: <5RTIGAE62LfB2J9VbFvNKVUUG9eP7zWRvBiudfIzjNQ=.1f37d12a-c4a3-4497-8d67-979097cd304e@github.com>

On Wed, 17 Nov 2021 15:32:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of updating comments.
> 
> Test: build

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Nov 17 22:11:45 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 17 Nov 2021 22:11:45 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v3]
In-Reply-To: <s4FXAH7sHIXHRAw_EMuoY4pbNi6RFwXIFfnRHKBfvIs=.0ca9d313-9b53-48e5-966a-4a3dd5bda60d@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
 <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
 <K7jsCs1jH5KCgaNJEPFAia2Ic6ythCCSwlTNxk00iqM=.514ae6e5-b81e-4734-89da-1d552a15a58c@github.com>
 <s4FXAH7sHIXHRAw_EMuoY4pbNi6RFwXIFfnRHKBfvIs=.0ca9d313-9b53-48e5-966a-4a3dd5bda60d@github.com>
Message-ID: <78pYwfhY40XcomE-Ycr8--5fwuYgqe5sM5FewGhMyxE=.1ed1e3d9-d2dd-414f-a4ee-5f80e985e120@github.com>

On Wed, 17 Nov 2021 14:58:21 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>>> @tschatzl I tested PR#5909 and this change: The combination of 1024b card/512M region is giving 2-3% improvement over 1024b card/32M region in SPECjbb2015 on my setup. I haven't analyzed this is detail though.
>> 
>> Good that the changed did not optimize away the improvements.
>> 
>>> 
>>> Shall I update the pull request with new patch by:
>>> 
>>>     1. Removing min_card_size code as it is not relevant now.
>> 
>> Please do. It is unnecessary now as there are no limitations of the combination of card size/region size for G1 any more.
>> 
>>> 
>>>     2. Update minimum card size supported from 512 to 128/256? Need your input on the min card size value and default card size value.
>> 
>> I'd say keep 512 bytes default. I looked a bit through literature, and the suggestion is that the minimum size used seems 128 bytes. That might be useful for smallish heaps.
>> 
>> Thanks,
>>   Thomas
>> 
>> Edit: I messed up with the default value, @vish-chan, please keep 512 default.
>
> @tschatzl I've updated the PR with a new patch: Removed the dependency of G1 heap region and card size. Set card size in [128. 1024] with 512 as default.

Hi @vish-chan - I changed the name of the CR to "Configurable card table card size" because we are done with the investigation :) No, honestly, "investigate xyz" is a bad title for a specification change (CSR) and a release note.
You need to update the title of the PR accordingly. Only you as creator can do that. Thanks.

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

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


From lihuaming3 at huawei.com  Thu Nov 18 01:35:26 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Thu, 18 Nov 2021 01:35:26 +0000
Subject: =?gb2312?B?tPC4tDogRGlzY3Vzc2lvbiBhYm91dCB1bmlmeWluZyB0aGUgd29yZGluZyBi?=
 =?gb2312?B?dWZmZXIvbm9kZS9lbGVtZW50IGluIEcxLCBlc3BlY2lhbGx5IGNsYXNzZXMg?=
 =?gb2312?Q?using_G1SegmentedArray_and_related_classes?=
In-Reply-To: <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
Message-ID: <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>


> > A segmented array consists of several buffers one of which consists of several element (or node? we should choose one of element or node).
>
> The term "buffer", to me, means a memory area used to hold data temporarily before data can be properly consumed, such as read/write buffers. Looking at the internals of `class G1SegmentedArrayBuffer`, I think it is essentially a dynamically-allocated array.

Thanks Albert, yes, you're right. 

>
> "element" often refers to an item, not the container. Maybe a more accurate word here is "slot".

The relationship is: Segmented array (1) <---> (N) buffer (1) <---> (M) element. So element is an item, e.g. an offset, a pointer, ...

>
> Therefore, my 2 cents: a segment array consists of several singly-linked subarray of potentially different length and potentially different slot size.

I'm not sure if I understand your point correctly, can I assume you mean: Segmented array (1) <---> (N) slot (1) <---> (M) element ?

Thanks
-Hamlin

From duke at openjdk.java.net  Thu Nov 18 06:56:10 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Thu, 18 Nov 2021 06:56:10 GMT
Subject: RFR: 8272773: Investigate making card table size configurable [v6]
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <L45UDPARh9kp_QhboZYqHKSpyCTUjQwiavwghQN57c4=.61787ba7-1074-472c-849f-05c2380f287e@github.com>

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:

  Changes as per comments on 17-11-21

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5838/files
  - new: https://git.openjdk.java.net/jdk/pull/5838/files/1f0612a1..125a0afb

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

  Stats: 20 lines in 6 files changed: 4 ins; 9 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5838.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838

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


From duke at openjdk.java.net  Thu Nov 18 07:28:06 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Thu, 18 Nov 2021 07:28:06 GMT
Subject: RFR: 8272773: Configurable card table card size [v7]
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <azi7cB7kVkWDiC8XHOzTl880T3RM0DLUklvidBrcnBo=.6ce84842-951f-43e4-a1ea-ad5d60a482c1@github.com>

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:

  Changes as per comments on 17-11-21

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5838/files
  - new: https://git.openjdk.java.net/jdk/pull/5838/files/125a0afb..0d1e15df

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

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

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


From duke at openjdk.java.net  Thu Nov 18 07:32:42 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Thu, 18 Nov 2021 07:32:42 GMT
Subject: RFR: 8272773: Configurable card table card size [v3]
In-Reply-To: <78pYwfhY40XcomE-Ycr8--5fwuYgqe5sM5FewGhMyxE=.1ed1e3d9-d2dd-414f-a4ee-5f80e985e120@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
 <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
 <K7jsCs1jH5KCgaNJEPFAia2Ic6ythCCSwlTNxk00iqM=.514ae6e5-b81e-4734-89da-1d552a15a58c@github.com>
 <s4FXAH7sHIXHRAw_EMuoY4pbNi6RFwXIFfnRHKBfvIs=.0ca9d313-9b53-48e5-966a-4a3dd5bda60d@github.com>
 <78pYwfhY40XcomE-Ycr8--5fwuYgqe5sM5FewGhMyxE=.1ed1e3d9-d2dd-414f-a4ee-5f80e985e120@github.com>
Message-ID: <RZTZnXwhd3Xsfrj5tVP3jWwMTLo0nM9RR5D3TElcv2A=.f68b89d1-dafb-4b8a-b61d-deef0e8d118b@github.com>

On Wed, 17 Nov 2021 22:08:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> @tschatzl I've updated the PR with a new patch: Removed the dependency of G1 heap region and card size. Set card size in [128. 1024] with 512 as default.
>
> Hi @vish-chan - I changed the name of the CR to "Configurable card table card size" because we are done with the investigation :) No, honestly, "investigate xyz" is a bad title for a specification change (CSR) and a release note.
> You need to update the title of the PR accordingly. Only you as creator can do that. Thanks.

@tschatzl I've updated the title of the PR and also made code changes as per the review comments. Thanks.

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

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


From thomas.schatzl at oracle.com  Thu Nov 18 08:24:39 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 18 Nov 2021 09:24:39 +0100
Subject: =?UTF-8?B?UmU6IOetlOWkjTogRGlzY3Vzc2lvbiBhYm91dCB1bmlmeWluZyB0aGUg?=
 =?UTF-8?Q?wording_buffer/node/element_in_G1=2c_especially_classes_using_G1S?=
 =?UTF-8?Q?egmentedArray_and_related_classes?=
In-Reply-To: <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
Message-ID: <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>

Hi,

On 18.11.21 02:35, lihuaming (A) wrote:
> 
>>> A segmented array consists of several buffers one of which consists of several element (or node? we should choose one of element or node).
>>
>> The term "buffer", to me, means a memory area used to hold data temporarily before data can be properly consumed, such as read/write buffers. Looking at the internals of `class G1SegmentedArrayBuffer`, I think it is essentially a dynamically-allocated array.
> 
> Thanks Albert, yes, you're right.
> 
>>
>> "element" often refers to an item, not the container. Maybe a more accurate word here is "slot".
> 
> The relationship is: Segmented array (1) <---> (N) buffer (1) <---> (M) element. So element is an item, e.g. an offset, a pointer, ...
> 
>>
>> Therefore, my 2 cents: a segment array consists of several singly-linked subarray of potentially different length and potentially different slot size.
> 
> I'm not sure if I understand your point correctly, can I assume you mean: Segmented array (1) <---> (N) slot (1) <---> (M) element ?
> 

I think Albert suggests:

segmented array (1) <---> (N) ???? (1) <---> (M) slot

I am kind of taking a liking to "slot".

Another option to "buffer" for the ???? could be "segment".

Thanks,
   Thomas


From albert.m.yang at oracle.com  Thu Nov 18 08:31:52 2021
From: albert.m.yang at oracle.com (Albert Yang)
Date: Thu, 18 Nov 2021 08:31:52 +0000
Subject: Discussion about unifying the wording buffer/node/element in G1, 
 especially classes using G1SegmentedArray and related classes
In-Reply-To: <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
Message-ID: <PH0PR10MB466151FC12A6F21945CE83A5D39B9@PH0PR10MB4661.namprd10.prod.outlook.com>

> The relationship is: Segmented array (1) <---> (N) buffer (1) <---> (M) element. So element is an item, e.g. an offset, a pointer, ...

Picking one suggestion from your first email:

G1CardSetAllocator::_num_free_nodes

node -> elem

`_num_free_slot` is, IMO, more accurate. An element is sth the user of the segmented array who provides.

> can I assume you mean: Segmented array (1) <---> (N) slot (1) <---> (M) element ?

One segmented array contains N subarray, each subarray contains M slots (M can be different for different subarrays), each slot contains a single element (provided by users of this data structure) or empty (initial state).

segmented array (1) -- subarray (N) -- slot (M) -- element (1)

/Albert

From albert.m.yang at oracle.com  Thu Nov 18 08:33:14 2021
From: albert.m.yang at oracle.com (Albert Yang)
Date: Thu, 18 Nov 2021 08:33:14 +0000
Subject: =?big5?B?UmU6ILWqzmA6IERpc2N1c3Npb24gYWJvdXQgdW5pZnlpbmcgdGhlIHdvcmRpbmcg?=
 =?big5?B?YnVmZmVyL25vZGUvZWxlbWVudCBpbiBHMSwgZXNwZWNpYWxseSBjbGFzc2VzIHVz?=
 =?big5?Q?ing_G1SegmentedArray_and_related_classes?=
In-Reply-To: <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
 <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>
Message-ID: <PH0PR10MB466107F69E61678D55E7E09DD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>

> Another option to "buffer" for the ???? could be "segment".

"segment" is good as well, IMO.

/Albert



From ayang at openjdk.java.net  Thu Nov 18 08:50:51 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 08:50:51 GMT
Subject: RFR: 8277371: Remove unnecessary
 DefNewGeneration::ref_processor_init()
Message-ID: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>

Simple change of removing a method that just calls the overridden method in base class.

Test: build

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

Commit messages:
 - ref_processor_init

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

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


From lihuaming3 at huawei.com  Thu Nov 18 08:52:47 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Thu, 18 Nov 2021 08:52:47 +0000
Subject: =?gb2312?B?tPC4tDogtPC4tDogRGlzY3Vzc2lvbiBhYm91dCB1bmlmeWluZyB0aGUgd29y?=
 =?gb2312?B?ZGluZyBidWZmZXIvbm9kZS9lbGVtZW50IGluIEcxLCBlc3BlY2lhbGx5IGNs?=
 =?gb2312?B?YXNzZXMgdXNpbmcgRzFTZWdtZW50ZWRBcnJheSBhbmQgcmVsYXRlZCBjbGFz?=
 =?gb2312?Q?ses?=
In-Reply-To: <PH0PR10MB466107F69E61678D55E7E09DD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
 <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>
 <PH0PR10MB466107F69E61678D55E7E09DD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
Message-ID: <cbd0fab44a17462cbef21f4ecf554265@huawei.com>


> Another option to "buffer" for the ???? could be "segment".

"segment" is good as well, IMO.

I see, thanks for clarification.

How about following naming relationship?
	segmented array (1) -- segment (N) -- slot (M) -- element (1)

Thanks
-Hamlin


From stefank at openjdk.java.net  Thu Nov 18 08:55:38 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 18 Nov 2021 08:55:38 GMT
Subject: RFR: 8277371: Remove unnecessary
 DefNewGeneration::ref_processor_init()
In-Reply-To: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
References: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
Message-ID: <JDceonfPrBcBJEElflmpL3yxILRZrznsfUfBYpe_Yvo=.01acc598-6eb2-4373-910c-d4dd0bbac8ad@github.com>

On Thu, 18 Nov 2021 08:43:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a method that just calls the overridden method in base class.
> 
> Test: build

Marked as reviewed by stefank (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Nov 18 08:56:45 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 18 Nov 2021 08:56:45 GMT
Subject: RFR: 8272773: Configurable card table card size [v7]
In-Reply-To: <azi7cB7kVkWDiC8XHOzTl880T3RM0DLUklvidBrcnBo=.6ce84842-951f-43e4-a1ea-ad5d60a482c1@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <azi7cB7kVkWDiC8XHOzTl880T3RM0DLUklvidBrcnBo=.6ce84842-951f-43e4-a1ea-ad5d60a482c1@github.com>
Message-ID: <gEcBWHoF1y5vGC16acC7q9bbTusRQwOUYUntwbpl-QA=.bce79e51-d5bc-44f1-8086-705ecb803171@github.com>

On Thu, 18 Nov 2021 07:28:06 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes as per comments on 17-11-21

~I think this is good~. The change does not compile on Linux due to a missing include to define `INCLUDE_PARALLELGC`

I filed CRs for the renaming of the static members in [JDK-8277372](https://bugs.openjdk.java.net/browse/JDK-8277372)and looking into making card and BOT maximum size dependent on `ObjectAlignmentInBytes` in [JDK-8277373](https://bugs.openjdk.java.net/browse/JDK-8277373)

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

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


From duke at openjdk.java.net  Thu Nov 18 09:17:40 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Thu, 18 Nov 2021 09:17:40 GMT
Subject: RFR: 8272773: Configurable card table card size [v3]
In-Reply-To: <78pYwfhY40XcomE-Ycr8--5fwuYgqe5sM5FewGhMyxE=.1ed1e3d9-d2dd-414f-a4ee-5f80e985e120@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com>
 <y682Lus7Xk97M67HBogyKp0EKw9LWQD-2j6e3lvm_zM=.453a69a5-adeb-432f-8922-0621eaff0815@github.com>
 <9N6nZozU8JdS6GYjSzZYJ4iyjrIyweTmIYdzBaQa6bU=.7d9bd3c4-194c-444f-9b56-bcf29fd70b48@github.com>
 <K7jsCs1jH5KCgaNJEPFAia2Ic6ythCCSwlTNxk00iqM=.514ae6e5-b81e-4734-89da-1d552a15a58c@github.com>
 <s4FXAH7sHIXHRAw_EMuoY4pbNi6RFwXIFfnRHKBfvIs=.0ca9d313-9b53-48e5-966a-4a3dd5bda60d@github.com>
 <78pYwfhY40XcomE-Ycr8--5fwuYgqe5sM5FewGhMyxE=.1ed1e3d9-d2dd-414f-a4ee-5f80e985e120@github.com>
Message-ID: <9PTqM-TeQ8XK1_FoRVtG5qpEGqJf-YKTZT1OhfrIBkQ=.486aac35-ed64-4289-8210-f06d8fa4d726@github.com>

On Wed, 17 Nov 2021 22:08:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> @tschatzl I've updated the PR with a new patch: Removed the dependency of G1 heap region and card size. Set card size in [128. 1024] with 512 as default.
>
> Hi @vish-chan - I changed the name of the CR to "Configurable card table card size" because we are done with the investigation :) No, honestly, "investigate xyz" is a bad title for a specification change (CSR) and a release note.
> You need to update the title of the PR accordingly. Only you as creator can do that. Thanks.

@tschatzl Yes, the order of include is wrong, sorry about that. I'll add another patch with the correct order.

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

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


From sjohanss at openjdk.java.net  Thu Nov 18 09:28:36 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 18 Nov 2021 09:28:36 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor
 args
In-Reply-To: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
Message-ID: <rnc5-KboTJoHXGXVArySwopZ_89hyheCBCdA5UFNYUI=.122d786e-d593-4bd8-8b14-d972884d7ccd@github.com>

On Tue, 16 Nov 2021 15:39:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of dropping one arg in the constructor.
> 
> Test: hotspot_gc

Marked as reviewed by sjohanss (Reviewer).

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

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


From sjohanss at openjdk.java.net  Thu Nov 18 09:28:36 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 18 Nov 2021 09:28:36 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor
 args
In-Reply-To: <BoGf6fre5Y6VYVufwEejLpkgSsdZV9qzPIKiVojXJjo=.c2e17fcb-90b7-4e80-92c9-675e8a369ffe@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
 <ZiLVAdhRqzEkeE3e_SDYIHh8n8_OO9fEy4uKuAShNuE=.115cbbb1-9252-4b22-9b01-282abc2eff80@github.com>
 <BoGf6fre5Y6VYVufwEejLpkgSsdZV9qzPIKiVojXJjo=.c2e17fcb-90b7-4e80-92c9-675e8a369ffe@github.com>
Message-ID: <U9-0GapUBYwSEF30BfP13NNsVtipMaAqga-_PGpSnsM=.6163d522-a6af-4a0b-9e02-d4296819a1b5@github.com>

On Wed, 17 Nov 2021 18:27:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > it is a change in behavior
> 
> The value of `_discovery_is_mt` is different, but the external behavior is the same. `ReferenceProcessor::get_discovered_list` will have `id == 0` in both cases, returning the same discovered list.

Yes, and in `discover_reference(...)` we will use the non-mt path when adding to the list, but since we only have one thread this should be fine.

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

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


From thomas.schatzl at oracle.com  Thu Nov 18 09:46:14 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 18 Nov 2021 10:46:14 +0100
Subject: =?UTF-8?B?UmU6IOetlOWkjTog562U5aSNOiBEaXNjdXNzaW9uIGFib3V0IHVuaWZ5?=
 =?UTF-8?Q?ing_the_wording_buffer/node/element_in_G1=2c_especially_classes_u?=
 =?UTF-8?Q?sing_G1SegmentedArray_and_related_classes?=
In-Reply-To: <cbd0fab44a17462cbef21f4ecf554265@huawei.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
 <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>
 <PH0PR10MB466107F69E61678D55E7E09DD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cbd0fab44a17462cbef21f4ecf554265@huawei.com>
Message-ID: <9859a645-a7b9-5905-dd64-3b33cadcfe68@oracle.com>

Hi,

On 18.11.21 09:52, lihuaming (A) wrote:
> 
>> Another option to "buffer" for the ???? could be "segment".
> 
> "segment" is good as well, IMO.
> 
> I see, thanks for clarification.
> 
> How about following naming relationship?
> 	segmented array (1) -- segment (N) -- slot (M) -- element (1)
> 

fine with me.

Thomas


From duke at openjdk.java.net  Thu Nov 18 09:55:07 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Thu, 18 Nov 2021 09:55:07 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:

  Change to avoid compilation issue in hs builds

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5838/files
  - new: https://git.openjdk.java.net/jdk/pull/5838/files/0d1e15df..6d7b0844

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

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

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


From tschatzl at openjdk.java.net  Thu Nov 18 10:01:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 18 Nov 2021 10:01:52 GMT
Subject: RFR: 8277371: Remove unnecessary
 DefNewGeneration::ref_processor_init()
In-Reply-To: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
References: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
Message-ID: <fQbxxDTxVHJ_TTrbCdQv6VtPebZxoKbUjUawhkyXHmA=.8f2f19c2-af17-4897-be5d-2eea995eefbb@github.com>

On Thu, 18 Nov 2021 08:43:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a method that just calls the overridden method in base class.
> 
> Test: build

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Nov 18 10:34:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 18 Nov 2021 10:34:44 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
Message-ID: <NFvHa0MkgVo1rGaoCms1m1Ttzqfw0SQafM3B4lwIMJc=.874e37ad-1146-4cb0-a753-e20537e9b092@github.com>

On Thu, 18 Nov 2021 09:55:07 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to avoid compilation issue in hs builds

I will push it through internal testing. Will take a bit.

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

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


From albert.m.yang at oracle.com  Thu Nov 18 10:46:26 2021
From: albert.m.yang at oracle.com (Albert Yang)
Date: Thu, 18 Nov 2021 10:46:26 +0000
Subject: =?big5?B?UmU6ILWqzmA6IERpc2N1c3Npb24gYWJvdXQgdW5pZnlpbmcgdGhlIHdvcmRpbmcg?=
 =?big5?B?YnVmZmVyL25vZGUvZWxlbWVudCBpbiBHMSwgZXNwZWNpYWxseSBjbGFzc2VzIHVz?=
 =?big5?Q?ing_G1SegmentedArray_and_related_classes?=
In-Reply-To: <cbd0fab44a17462cbef21f4ecf554265@huawei.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
 <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>
 <PH0PR10MB466107F69E61678D55E7E09DD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cbd0fab44a17462cbef21f4ecf554265@huawei.com>
Message-ID: <PH0PR10MB466149A7651E1E3B1E1BC79BD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>

> How about following naming relationship?
>        segmented array (1) -- segment (N) -- slot (M) -- element (1)

+1

/Albert

From ayang at openjdk.java.net  Thu Nov 18 10:56:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 10:56:42 GMT
Subject: RFR: 8277215: Remove redundancy in ReferenceProcessor constructor
 args
In-Reply-To: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
Message-ID: <zTVi4xaXWHeMlQCTuNZxj2Ay3zQqMbFnenwv41tGt9U=.65318606-16dc-4d8c-bde0-a3b9c8cb986b@github.com>

On Tue, 16 Nov 2021 15:39:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of dropping one arg in the constructor.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Nov 18 10:56:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 10:56:42 GMT
Subject: Integrated: 8277215: Remove redundancy in ReferenceProcessor
 constructor args
In-Reply-To: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
References: <2avwIhRmHkh89mNtMvk3HTz5GTe3sx-vg_JVzMLQFVk=.cca3a2c1-755d-4674-aec4-243331ff12ec@github.com>
Message-ID: <Sz-9RNJnAoVOypGngf24UUfFP883SqOHV48-NjSuXGU=.dd562c59-a7f3-4cd1-adb1-57f2ea9515aa@github.com>

On Tue, 16 Nov 2021 15:39:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of dropping one arg in the constructor.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 77cc5088
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77cc508802899b370f1cdf592331f81efb8d9208
Stats:     7 lines in 5 files changed: 0 ins; 5 del; 2 mod

8277215: Remove redundancy in ReferenceProcessor constructor args

Reviewed-by: tschatzl, sjohanss

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

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


From ayang at openjdk.java.net  Thu Nov 18 12:41:08 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 12:41:08 GMT
Subject: RFR: 8277394: Remove the use of safepoint_workers in reference
 processor
Message-ID: <ViGZSkP7H_kIpOtNXZXMdP2O0Wcfh1ghCdWfc4e-R6g=.425fe95b-458d-4c34-8233-b5482717a633@github.com>

Simple change of passing workers to the reference processor constructor.

Test: hotspot_gc

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

Commit messages:
 - safepoint_workers

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

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


From stefank at openjdk.java.net  Thu Nov 18 13:36:41 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 18 Nov 2021 13:36:41 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements
In-Reply-To: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
Message-ID: <WYDSiwBqkpIPBRmOUQQTqr_QaHXCNvOMVv1M6PNbwYs=.5b404bcd-7140-4772-ae8a-86c1510ce56b@github.com>

On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.

Retrying with correct labels.

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

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


From stefank at openjdk.java.net  Thu Nov 18 13:46:56 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 18 Nov 2021 13:46:56 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of gc+phase=debug
Message-ID: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>

When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.

Output with -Xlog:gc,gc+phases=debug

Before:

[0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
[0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
[0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
[0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
[0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
[0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
[0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
[0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
[0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
[0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
[0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
[0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
[0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
[0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
[0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
[0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
[0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
[0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
[0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
[0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
[0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
[0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
[0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
[0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
[0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
[0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
[0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)

After:

[0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
[0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
[0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
[0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
[0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
[0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
[0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
[0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
[0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
[0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
[0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
[0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
[0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
[0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
[0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
[0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)

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

Commit messages:
 - 8277399: ZGC: Move worker thread logging out of gc+phase=debug

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

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


From eosterlund at openjdk.java.net  Thu Nov 18 13:51:44 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 18 Nov 2021 13:51:44 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug
In-Reply-To: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
Message-ID: <gjeYjfSTePazLR5_GnOk-UTDhS8DZU1FGch9uTXqwQA=.81f9b7a4-f98f-4660-a78b-e48279061cb2@github.com>

On Thu, 18 Nov 2021 13:31:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
> 
> Output with -Xlog:gc,gc+phases=debug
> 
> Before:
> 
> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
> 
> After:
> 
> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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


From eosterlund at openjdk.java.net  Thu Nov 18 14:25:47 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 18 Nov 2021 14:25:47 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements
In-Reply-To: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
Message-ID: <DrX_-6gOXfp75-2scLqHrEtwu0aO7qIoLk_i7sSXvBU=.34db18a7-952e-48d8-b777-eee77db29a2e@github.com>

On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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


From ayang at openjdk.java.net  Thu Nov 18 14:32:51 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 14:32:51 GMT
Subject: RFR: 8276093: Improve naming in closures to iterate over card sets
 [v2]
In-Reply-To: <XuBpnp8Y_x19Smwp_Qq9hJ0q4vn7YyNCBr6Iqfk-H-g=.72e3643c-0697-424a-9ae4-c4a999adf1ef@github.com>
References: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
 <XuBpnp8Y_x19Smwp_Qq9hJ0q4vn7YyNCBr6Iqfk-H-g=.72e3643c-0697-424a-9ae4-c4a999adf1ef@github.com>
Message-ID: <ev1-FxxN3zFFfWVMvmFOkgmeiV9JK0awpLw7ON6FPoU=.3ef93075-8e77-4fe4-84d8-ae71e1a254f6@github.com>

On Wed, 17 Nov 2021 20:34:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this renaming change that tries to change naming for some remembered set closures to include `Closure` instead of `Iterator` in their names. Additionally I removed two or so `G1` prefixes for nested classes. Hopefully this improves the situation a bit, although it's still a mess of nested closures.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   parameter names

Marked as reviewed by ayang (Reviewer).

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

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


From pliden at openjdk.java.net  Thu Nov 18 14:35:46 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 18 Nov 2021 14:35:46 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug
In-Reply-To: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
Message-ID: <A4d_9e9sJGC2O91mU7QJpgODja4mq6AJG-QOgBLnOlA=.721aa424-2f70-4cdf-939c-fd34d4b87121@github.com>

On Thu, 18 Nov 2021 13:31:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
> 
> Output with -Xlog:gc,gc+phases=debug
> 
> Before:
> 
> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
> 
> After:
> 
> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)

Looks good. But may I suggest that we use `gc+phases=trace` instead of `gc+phases+thread=debug`.

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

Marked as reviewed by pliden (Reviewer).

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


From duke at openjdk.java.net  Thu Nov 18 14:48:41 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Thu, 18 Nov 2021 14:48:41 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <NFvHa0MkgVo1rGaoCms1m1Ttzqfw0SQafM3B4lwIMJc=.874e37ad-1146-4cb0-a753-e20537e9b092@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
 <NFvHa0MkgVo1rGaoCms1m1Ttzqfw0SQafM3B4lwIMJc=.874e37ad-1146-4cb0-a753-e20537e9b092@github.com>
Message-ID: <Z2lguVPb1Y5PsV0P5Z8yvmCVTQN8DgAUvPaBymQnIng=.8569ec48-d7c4-479f-9a4c-c34fa24ae132@github.com>

On Thu, 18 Nov 2021 10:32:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I will push it through internal testing. Will take a bit.

@tschatzl Thank you. Regarding  [JDK-8277372](https://bugs.openjdk.java.net/browse/JDK-8277372), do we wait for this PR to integrate and then work on this?

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

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


From stefank at openjdk.java.net  Thu Nov 18 15:18:24 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 18 Nov 2021 15:18:24 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug [v2]
In-Reply-To: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
Message-ID: <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>

> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
> 
> Output with -Xlog:gc,gc+phases=debug
> 
> Before:
> 
> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
> 
> After:
> 
> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review Per

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6457/files
  - new: https://git.openjdk.java.net/jdk/pull/6457/files/313d5d97..8cc2221b

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

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

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


From stefank at openjdk.java.net  Thu Nov 18 15:18:25 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 18 Nov 2021 15:18:25 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug
In-Reply-To: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
Message-ID: <uY51b3CRXBNAm_f_iBZN4STo3L4Q9nINTeN01FdNhQ0=.64a009a7-57bf-4702-8c5c-8296c89b630d@github.com>

On Thu, 18 Nov 2021 13:31:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
> 
> Output with -Xlog:gc,gc+phases=debug
> 
> Before:
> 
> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
> 
> After:
> 
> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)

Updated with Per's suggestion. Thanks!

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

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


From eosterlund at openjdk.java.net  Thu Nov 18 15:24:41 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 18 Nov 2021 15:24:41 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug [v2]
In-Reply-To: <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
 <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>
Message-ID: <P9UCrbFLjvwAKZqI93GAchgu6Yk3LhpNIQo6j1wAsOQ=.efbcdf4b-aa83-419c-b72a-76cd6e3a8e1f@github.com>

On Thu, 18 Nov 2021 15:18:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
>> 
>> Output with -Xlog:gc,gc+phases=debug
>> 
>> Before:
>> 
>> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
>> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
>> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
>> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
>> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
>> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
>> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
>> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
>> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
>> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
>> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
>> 
>> After:
>> 
>> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
>> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
>> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
>> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
>> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
>> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
>> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
>> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
>> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
>> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
>> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Per

Marked as reviewed by eosterlund (Reviewer).

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

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


From ayang at openjdk.java.net  Thu Nov 18 15:57:46 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 15:57:46 GMT
Subject: RFR: 8277336: Improve CollectedHeap::safepoint_workers comments
In-Reply-To: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
References: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
Message-ID: <vd5gfs3ltDYafvGBDA83vas2yaNZgikhVBFTLE5kVQM=.5f5e46f3-6250-470b-ae76-9a8a9679c3f8@github.com>

On Wed, 17 Nov 2021 15:32:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of updating comments.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Nov 18 15:57:47 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 15:57:47 GMT
Subject: Integrated: 8277336: Improve CollectedHeap::safepoint_workers comments
In-Reply-To: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
References: <Mjf0SvI7wJtYjwjefGMhemBzTWEiehf06nRHrFTsTIY=.5ebf1b1a-bd17-4284-b276-411f3825efd9@github.com>
Message-ID: <d7yIrqkXSE1T9ME8ad3goD0AAo6LaUy6pyvlF0fnY0E=.fa547e67-a9a1-47f8-a1f6-1e04581f77ce@github.com>

On Wed, 17 Nov 2021 15:32:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of updating comments.
> 
> Test: build

This pull request has now been integrated.

Changeset: 354a34ea
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/354a34ea2077c9372e585adb1303df604827a2e2
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8277336: Improve CollectedHeap::safepoint_workers comments

Reviewed-by: sjohanss, tschatzl

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

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


From pliden at openjdk.java.net  Thu Nov 18 16:21:42 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 18 Nov 2021 16:21:42 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug [v2]
In-Reply-To: <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
 <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>
Message-ID: <LgLpD1ESs6SvFfmsTq9L_dx7Kyn6dwRivaKJSxZ_QMs=.580229be-5eda-4742-b62f-50c357b6c80f@github.com>

On Thu, 18 Nov 2021 15:18:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
>> 
>> Output with -Xlog:gc,gc+phases=debug
>> 
>> Before:
>> 
>> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
>> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
>> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
>> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
>> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
>> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
>> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
>> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
>> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
>> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
>> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
>> 
>> After:
>> 
>> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
>> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
>> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
>> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
>> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
>> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
>> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
>> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
>> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
>> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
>> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Per

Marked as reviewed by pliden (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Nov 18 17:02:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 18 Nov 2021 17:02:44 GMT
Subject: RFR: 8276093: Improve naming in closures to iterate over card sets
 [v2]
In-Reply-To: <ev1-FxxN3zFFfWVMvmFOkgmeiV9JK0awpLw7ON6FPoU=.3ef93075-8e77-4fe4-84d8-ae71e1a254f6@github.com>
References: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
 <XuBpnp8Y_x19Smwp_Qq9hJ0q4vn7YyNCBr6Iqfk-H-g=.72e3643c-0697-424a-9ae4-c4a999adf1ef@github.com>
 <ev1-FxxN3zFFfWVMvmFOkgmeiV9JK0awpLw7ON6FPoU=.3ef93075-8e77-4fe4-84d8-ae71e1a254f6@github.com>
Message-ID: <tAyi6kQRb0_b-8VPVL1TIMdIuQU8ZFCvTfDh7vM5_qg=.7e033419-27b6-4a7c-98b5-4b11eeec6c3b@github.com>

On Thu, 18 Nov 2021 14:29:31 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   parameter names
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews

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

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


From tschatzl at openjdk.java.net  Thu Nov 18 17:02:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 18 Nov 2021 17:02:44 GMT
Subject: Integrated: 8276093: Improve naming in closures to iterate over card
 sets
In-Reply-To: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
References: <JrQtp9a73DwxWxoTy6g5-2S4zmZF3GPQ-P3AsIkVqZQ=.9b6abc06-343f-4769-9e50-c00dcebd7e59@github.com>
Message-ID: <jvn64Ewm35Ojp1xQ3zNgkGB1oh3h3ApCSZqlm0EgItA=.1ae17705-6169-4dd7-ab01-990401e0ec05@github.com>

On Wed, 17 Nov 2021 13:10:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this renaming change that tries to change naming for some remembered set closures to include `Closure` instead of `Iterator` in their names. Additionally I removed two or so `G1` prefixes for nested classes. Hopefully this improves the situation a bit, although it's still a mess of nested closures.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: ce0f00f6
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ce0f00f66e78a504d5e40a25fa213325ec0af394
Stats:     62 lines in 5 files changed: 1 ins; 0 del; 61 mod

8276093: Improve naming in closures to iterate over card sets

Reviewed-by: sjohanss, ayang

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

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


From duke at openjdk.java.net  Thu Nov 18 18:14:01 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Nov 2021 18:14:01 GMT
Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent
Message-ID: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>

8277413: Remove unused local variables in jdk.hotspot.agent

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

Commit messages:
 - [PATCH] Remove unused local variables in jdk.hotspot.agent

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

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


From tschatzl at openjdk.java.net  Thu Nov 18 19:30:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 18 Nov 2021 19:30:49 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <Z2lguVPb1Y5PsV0P5Z8yvmCVTQN8DgAUvPaBymQnIng=.8569ec48-d7c4-479f-9a4c-c34fa24ae132@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
 <NFvHa0MkgVo1rGaoCms1m1Ttzqfw0SQafM3B4lwIMJc=.874e37ad-1146-4cb0-a753-e20537e9b092@github.com>
 <Z2lguVPb1Y5PsV0P5Z8yvmCVTQN8DgAUvPaBymQnIng=.8569ec48-d7c4-479f-9a4c-c34fa24ae132@github.com>
Message-ID: <9XPZgkUKyNieI3X3ictYSTNVOC5R9Rpm2GGsw7siZMc=.293faa7d-f154-46b9-9bcc-6912ef4d1399@github.com>

On Thu, 18 Nov 2021 14:45:18 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

> > I will push it through internal testing. Will take a bit.
> 
> @tschatzl Thank you. Regarding [JDK-8277372](https://bugs.openjdk.java.net/browse/JDK-8277372), do we wait for this PR to integrate and then work on this?

You can certainly start working on this, based on the current version, I'm assuming not too much will change. Integrating this is conditional on CSR approval (which is certain, but takes some time until reviewed).

I do not recommend making a PR already for the JDK-8277372 change yet - these dependent PRs never worked for me :)

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

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


From rkennke at openjdk.java.net  Thu Nov 18 21:35:51 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 18 Nov 2021 21:35:51 GMT
Subject: Integrated: 8275527: Refactor forward pointer access
In-Reply-To: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
References: <lLd1nmhXCgBhAySmq81KrMplWUSWMCJS4OybGZuMjco=.4012548b-6f1d-44ee-a59c-21f1077cba01@github.com>
Message-ID: <ABql1QFqXem4aRwxCiAqQiDqrAkZCXvtgoHhd20k70Y=.31336a91-c57f-4af5-a97c-5efe8a47cf4d@github.com>

On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Accessing the forward pointer is currently a little inconsistent. Some code paths call oopDesc::forwardee() / oopDesc::is_forwarded(), some code paths call forwardee() and check it for ==/!= NULL, some code paths even call markWord::decode_pointer() and markWord::is_marked() instead.
> 
> This change attempts to make the situation more consistent. For simple cases it preserves oopDesc::forwardee() / is_forwarded(), some cases need to use the markWord for consistency in concurrent GC, they now use markWord::forwardee() and markWord::is_forwarded(). Also, checking whether or not an object is forwarded is now consistently done using is_forwarded() and not by checking forwardee ==/!= NULL. This also resolves the mess in G1 full GC that changes not-forwarded objects to have a NULL (fake-) pointer. This is not necessary, because we can just as well use the lock bits to determine whether or not the object is forwarded.
> 
> Testing:
>  - [x] tier
>  - [x] tier2
>  - [x] hotspot_gc

This pull request has now been integrated.

Changeset: 89b125f4
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/89b125f4d4d6a467185b4b39861fd530a738e67f
Stats:     46 lines in 9 files changed: 4 ins; 26 del; 16 mod

8275527: Refactor forward pointer access

Reviewed-by: tschatzl, stefank

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

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


From ayang at openjdk.java.net  Thu Nov 18 21:55:48 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 18 Nov 2021 21:55:48 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
Message-ID: <IANlxOm-o3kjVOs40M9xB9AI4qPr0hXuGRowKYqpOXw=.14f27d1d-2d43-44c5-be81-3efe7b4e98e9@github.com>

On Thu, 18 Nov 2021 09:55:07 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to avoid compilation issue in hs builds

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1663:

> 1661:   // The G1FromCardCache reserves card with value 0 as "invalid", so the heap must not
> 1662:   // start within the first card.
> 1663:   guarantee(heap_rs.base() >= (char*)(uintptr_t)(G1CardTable::card_size), "Java heap must not start within the first card.");

How about `(uintptr_t)heap_rs.base() >= G1CardTable::card_size`? Converting an arbitrary integer to a pointer is implementation-defined.

src/hotspot/share/gc/g1/heapRegion.cpp line 94:

> 92: 
> 93:   // Initialize card size
> 94:   CardTable::initialize_card_size();

I see that `CardTable::initialize_card_size()` is called at the beginning of `GCArguments::initialize_alignments()` for Serial and Parallel. I wonder if it makes sense to do the same for G1.

src/hotspot/share/gc/shared/cardTable.cpp line 457:

> 455: 
> 456: uintx CardTable::ct_max_alignment_constraint() {
> 457:   return GCCardSizeInBytes * os::vm_page_size();

The reason why `card_size` can't be used here is that `card_size` haven't been set when this method is called, correct? If so, please put a comment here.

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

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


From jbachorik at openjdk.java.net  Fri Nov 19 00:04:45 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Fri, 19 Nov 2021 00:04:45 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements
In-Reply-To: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
Message-ID: <WQcfFSutLh0_XyaQwazrXBoD3YDj9hjJHsHCbSzTBMM=.2e7ea4c8-a360-4a51-832b-c2027bd873f6@github.com>

On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.

Changes requested by jbachorik (Reviewer).

src/hotspot/share/jfr/metadata/metadata.xml line 1037:

> 1035:   </Event>
> 1036: 
> 1037:   <Event name="ZThreadEvent" category="Java Virtual Machine, GC, Detailed" label="ZGC Thread Event" thread="true" experimental="true">

Can you add a description to the event?
For anyone coming from outside it would really help to understand what this event is supposed to represent.

src/jdk.jfr/share/conf/jfr/default.jfc line 778:

> 776:     </event>
> 777: 
> 778:     <event name="jdk.ZThreadEvent">

This is just a question - do we want/need to have this event enabled for the 'low overhead profiling' setup?

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

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


From lihuaming3 at huawei.com  Fri Nov 19 01:07:22 2021
From: lihuaming3 at huawei.com (lihuaming (A))
Date: Fri, 19 Nov 2021 01:07:22 +0000
Subject: =?gb2312?B?tPC4tDogtPC4tDogRGlzY3Vzc2lvbiBhYm91dCB1bmlmeWluZyB0aGUgd29y?=
 =?gb2312?B?ZGluZyBidWZmZXIvbm9kZS9lbGVtZW50IGluIEcxLCBlc3BlY2lhbGx5IGNs?=
 =?gb2312?B?YXNzZXMgdXNpbmcgRzFTZWdtZW50ZWRBcnJheSBhbmQgcmVsYXRlZCBjbGFz?=
 =?gb2312?Q?ses?=
In-Reply-To: <PH0PR10MB466149A7651E1E3B1E1BC79BD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
References: <b706dcb10f534edfb8b52838de4c99b3@huawei.com>
 <PH0PR10MB4661E962E62241AC9D52E375D39A9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cf2828c11c1f411ba9e378d0b5a2509a@huawei.com>
 <bd363c54-4611-9977-eaf0-fbc766005ddc@oracle.com>
 <PH0PR10MB466107F69E61678D55E7E09DD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
 <cbd0fab44a17462cbef21f4ecf554265@huawei.com>
 <PH0PR10MB466149A7651E1E3B1E1BC79BD39B9@PH0PR10MB4661.namprd10.prod.outlook.com>
Message-ID: <1da50cd994434b58b01f554a533631d8@huawei.com>


> > How about following naming relationship?
> >        segmented array (1) -- segment (N) -- slot (M) -- element (1)
>
> +1

Got it. Thanks Thomas, Albert for discussion.

-Hamlin

From mli at openjdk.java.net  Fri Nov 19 01:12:37 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 01:12:37 GMT
Subject: RFR: 8277371: Remove unnecessary
 DefNewGeneration::ref_processor_init()
In-Reply-To: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
References: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
Message-ID: <c6X8dpvaL__kOWNPMo_k9fOZLVUnJUgNrTpYAzHwEnE=.f985d560-c9bd-4a74-a27f-4f0c1ed675fb@github.com>

On Thu, 18 Nov 2021 08:43:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a method that just calls the overridden method in base class.
> 
> Test: build

Marked as reviewed by mli (Reviewer).

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

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


From mli at openjdk.java.net  Fri Nov 19 02:44:28 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 02:44:28 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v4]
In-Reply-To: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
Message-ID: <LPlSO3U2KB3Nak0K5oHkvAyvU7r4-Iv_iMp0ooF1SWM=.0fa29916-02ed-45a2-a1e1-43331fda6c20@github.com>

> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
> 
> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
> 
> I plan to do this in about 3 steps to smooth the review process:
>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>   2. refactor these classes to support freeing other freelist
>   3. some necessary cleanup
> 
> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
> Rename from G1CardSetXxx -> G1BufferListXxx.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Rename from G1BufferListXxx to G1SegmentedArrayXxx

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6289/files
  - new: https://git.openjdk.java.net/jdk/pull/6289/files/c15129e4..d7fb55c0

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

  Stats: 1291 lines in 19 files changed: 631 ins; 631 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6289/head:pull/6289

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


From mli at openjdk.java.net  Fri Nov 19 03:30:16 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 03:30:16 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v5]
In-Reply-To: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
Message-ID: <1q4XSNAOTgNOzcgghIEHc8MjS5s6C5y49Kri6heLnSQ=.61d33195-6e91-4029-835e-450c6903697f@github.com>

> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
> 
> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
> 
> I plan to do this in about 3 steps to smooth the review process:
>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>   2. refactor these classes to support freeing other freelist
>   3. some necessary cleanup
> 
> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
> Rename from G1CardSetXxx -> G1BufferListXxx.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Rename card set to segmented array

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6289/files
  - new: https://git.openjdk.java.net/jdk/pull/6289/files/d7fb55c0..a51ebcd5

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

  Stats: 24 lines in 7 files changed: 1 ins; 1 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6289/head:pull/6289

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


From mli at openjdk.java.net  Fri Nov 19 03:36:53 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 03:36:53 GMT
Subject: RFR: 8277428: G1: Move G1STWIsAliveClosure::do_object_b definition
 back to g1CollectedHeap.cpp
Message-ID: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>

This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.cpp.

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

Commit messages:
 - Initial commit

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

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


From mli at openjdk.java.net  Fri Nov 19 04:49:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 04:49:59 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v6]
In-Reply-To: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
Message-ID: <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>

> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
> 
> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
> 
> I plan to do this in about 3 steps to smooth the review process:
>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>   2. refactor these classes to support freeing other freelist
>   3. some necessary cleanup
> 
> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
> Rename from G1CardSetXxx -> G1BufferListXxx.

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

 - Merge with master
 - Rename card set to segmented array
 - Rename from G1BufferListXxx to G1SegmentedArrayXxx
 - Fix typo
 - Merge branch 'master' into rename-move-G1CardSetFreePool-out
 - Fix typos
 - Fix gtest tests
 - Fix missing in test
 - Fix missing files
 - move g1CardSetFreeMemoryTask.*
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f0bde1a...7cfe01fb

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

Changes: https://git.openjdk.java.net/jdk/pull/6289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6289&range=05
  Stats: 1228 lines in 19 files changed: 641 ins; 555 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6289.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6289/head:pull/6289

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


From ayang at openjdk.java.net  Fri Nov 19 05:10:43 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 19 Nov 2021 05:10:43 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
Message-ID: <ByNxndvW9yiO7d2zgh4dDwCdNJMz6XVwMpv-tKz-ZWY=.ffa2eab0-fe85-4b79-8746-c39e5a396751@github.com>

On Thu, 18 Nov 2021 09:55:07 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to avoid compilation issue in hs builds

Just some minor comments/suggestions.

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

Marked as reviewed by ayang (Reviewer).

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


From duke at openjdk.java.net  Fri Nov 19 05:10:44 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Fri, 19 Nov 2021 05:10:44 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <IANlxOm-o3kjVOs40M9xB9AI4qPr0hXuGRowKYqpOXw=.14f27d1d-2d43-44c5-be81-3efe7b4e98e9@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
 <IANlxOm-o3kjVOs40M9xB9AI4qPr0hXuGRowKYqpOXw=.14f27d1d-2d43-44c5-be81-3efe7b4e98e9@github.com>
Message-ID: <xmRR-nlU8NYtEiOK64cg9JWamDOCQX9Nx8FmUiJWLfk=.9c5ce8a7-7426-4423-9b5b-98dd8c325da7@github.com>

On Thu, 18 Nov 2021 21:49:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change to avoid compilation issue in hs builds
>
> src/hotspot/share/gc/g1/heapRegion.cpp line 94:
> 
>> 92: 
>> 93:   // Initialize card size
>> 94:   CardTable::initialize_card_size();
> 
> I see that `CardTable::initialize_card_size()` is called at the beginning of `GCArguments::initialize_alignments()` for Serial and Parallel. I wonder if it makes sense to do the same for G1.

The reason for having `CardTable::initialize_card_size()` here in the initial patch was the dependency between card size and G1 heap region size. Since the dependency is no longer there, we can safely move this initialization to `G1Arguments::initialize_alignments`

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

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


From mli at openjdk.java.net  Fri Nov 19 06:47:05 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 06:47:05 GMT
Subject: RFR: 8277439: G1: Correct include guard name in
 G1EvacFailureObjectsSet.hpp
Message-ID: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>

This is a trivial patch to fix the include guard name in G1EvacFailureObjectsSet.hpp

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

Commit messages:
 - Initial commit

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

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


From stefank at openjdk.java.net  Fri Nov 19 07:50:41 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 19 Nov 2021 07:50:41 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements
In-Reply-To: <WQcfFSutLh0_XyaQwazrXBoD3YDj9hjJHsHCbSzTBMM=.2e7ea4c8-a360-4a51-832b-c2027bd873f6@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <WQcfFSutLh0_XyaQwazrXBoD3YDj9hjJHsHCbSzTBMM=.2e7ea4c8-a360-4a51-832b-c2027bd873f6@github.com>
Message-ID: <KZHQVWVMGModLDve185EHlVQC2-6Or7rgatf32rLDgs=.a2dbdc6e-590f-4dd1-b96b-f9f0a2414082@github.com>

On Thu, 18 Nov 2021 23:59:45 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> src/hotspot/share/jfr/metadata/metadata.xml line 1037:
> 
>> 1035:   </Event>
>> 1036: 
>> 1037:   <Event name="ZThreadEvent" category="Java Virtual Machine, GC, Detailed" label="ZGC Thread Event" thread="true" experimental="true">
> 
> Can you add a description to the event?
> For anyone coming from outside it would really help to understand what this event is supposed to represent.

Great idea.

> src/jdk.jfr/share/conf/jfr/default.jfc line 778:
> 
>> 776:     </event>
>> 777: 
>> 778:     <event name="jdk.ZThreadEvent">
> 
> This is just a question - do we want/need to have this event enabled for the 'low overhead profiling' setup?

Yes. I always use default.jfc. The profile.jfc is creating too many allocation related events to make it usable when running with ZGC. I know that there has been some plans to fix that, but I don't know if that made it into JDK 17 or not.

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

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


From stefank at openjdk.java.net  Fri Nov 19 08:02:12 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 19 Nov 2021 08:02:12 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v2]
In-Reply-To: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
Message-ID: <TtXfWfhmsLADm0RYw3h6SdYslHqjlX4K9iTJGAzpEy0=.efd78613-45fe-43f0-a082-676c0b439b2e@github.com>

> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review jbachorik

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6454/files
  - new: https://git.openjdk.java.net/jdk/pull/6454/files/85f9b141..478c38a4

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

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

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


From ayang at openjdk.java.net  Fri Nov 19 08:34:46 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 19 Nov 2021 08:34:46 GMT
Subject: RFR: 8277371: Remove unnecessary
 DefNewGeneration::ref_processor_init()
In-Reply-To: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
References: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
Message-ID: <xe6IRBRpURiCgYtEwBeCKF2g3mZup3q26o552_3fkuA=.6cff2012-e372-4091-9e1c-215878418fd3@github.com>

On Thu, 18 Nov 2021 08:43:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a method that just calls the overridden method in base class.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Fri Nov 19 08:34:46 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 19 Nov 2021 08:34:46 GMT
Subject: Integrated: 8277371: Remove unnecessary
 DefNewGeneration::ref_processor_init()
In-Reply-To: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
References: <7txhVE4K3zT9dFgoApiI_AsfUp9HUowYMKiYljUUJQ0=.967997d7-c7e5-416c-9317-7f98ea8a84c5@github.com>
Message-ID: <vgLOOe6dixNxiLN4cSdnhFuR0N1KuqxcHCEcWOQb8bg=.7e18cee9-1d83-4111-99b7-cac14af0ea79@github.com>

On Thu, 18 Nov 2021 08:43:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a method that just calls the overridden method in base class.
> 
> Test: build

This pull request has now been integrated.

Changeset: 7a046e0f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a046e0f765e0ad04fd52c9a882c5d90b085bc00
Stats:     8 lines in 3 files changed: 0 ins; 7 del; 1 mod

8277371: Remove unnecessary DefNewGeneration::ref_processor_init()

Reviewed-by: stefank, tschatzl, mli

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

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


From stefank at openjdk.java.net  Fri Nov 19 08:49:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 19 Nov 2021 08:49:14 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
Message-ID: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>

> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Rename ZThreadEvent to ZThreadDebug

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6454/files
  - new: https://git.openjdk.java.net/jdk/pull/6454/files/478c38a4..15f4d9a7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6454&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6454&range=01-02

  Stats: 34 lines in 6 files changed: 0 ins; 18 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6454.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6454/head:pull/6454

PR: https://git.openjdk.java.net/jdk/pull/6454


From stefank at openjdk.java.net  Fri Nov 19 08:49:16 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 19 Nov 2021 08:49:16 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v2]
In-Reply-To: <TtXfWfhmsLADm0RYw3h6SdYslHqjlX4K9iTJGAzpEy0=.efd78613-45fe-43f0-a082-676c0b439b2e@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <TtXfWfhmsLADm0RYw3h6SdYslHqjlX4K9iTJGAzpEy0=.efd78613-45fe-43f0-a082-676c0b439b2e@github.com>
Message-ID: <FqUcyGitZoAxdlblzUnJwEbOgAILBYXGPKYNgtzIRPU=.7d60730b-b892-4bdc-a6fe-874ebdbc111f@github.com>

On Fri, 19 Nov 2021 08:02:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review jbachorik

I discussed the naming of this event with @pliden, and we decided to rename it to make it more clear that this was only intended for debugging/development of ZGC.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From pliden at openjdk.java.net  Fri Nov 19 08:53:44 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 19 Nov 2021 08:53:44 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <QNUauJg3-_DT_zyZXxzfYbF2NjfBkL636ISx19zCoWQ=.d5ad972e-c238-445b-9b0e-ea36875859ca@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

Looks good.

-------------

Marked as reviewed by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6454


From tschatzl at openjdk.java.net  Fri Nov 19 08:59:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 19 Nov 2021 08:59:43 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
Message-ID: <kh6f910KfdBNnFD56cMOGkSkqVsrCpngrb974N3tbBY=.a1f616b8-813d-4cb0-9f55-f91de36b7ab0@github.com>

On Thu, 18 Nov 2021 09:55:07 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change to avoid compilation issue in hs builds

Testing tier1-5 in our CI looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5838


From kbarrett at openjdk.java.net  Fri Nov 19 09:40:42 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 19 Nov 2021 09:40:42 GMT
Subject: RFR: 8277394: Remove the use of safepoint_workers in reference
 processor
In-Reply-To: <ViGZSkP7H_kIpOtNXZXMdP2O0Wcfh1ghCdWfc4e-R6g=.425fe95b-458d-4c34-8233-b5482717a633@github.com>
References: <ViGZSkP7H_kIpOtNXZXMdP2O0Wcfh1ghCdWfc4e-R6g=.425fe95b-458d-4c34-8233-b5482717a633@github.com>
Message-ID: <I640y9wnW70wJxz3yN4728V8SC4kfhmkiOg9byyiUag=.6a382334-0c33-47b0-81f2-6ffa573d7bac@github.com>

On Thu, 18 Nov 2021 12:31:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of passing workers to the reference processor constructor.
> 
> Test: hotspot_gc

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/referenceProcessor.hpp line 257:

> 255: 
> 256:   // Workers to process the discovered non-strong references.
> 257:   WorkerThreads* _workers;

Rather than adding a WorkerThreads member at construction time, it seems better to me to add an argument to ReferenceProcessor::run_task.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6453


From tschatzl at openjdk.java.net  Fri Nov 19 09:44:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 19 Nov 2021 09:44:39 GMT
Subject: RFR: 8277439: G1: Correct include guard name in
 G1EvacFailureObjectsSet.hpp
In-Reply-To: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
References: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
Message-ID: <VSdmdHa7EzRx5m8Ly4rPjjWIQMqsP_WaPl_dFczMJQk=.c2e6dd3c-1b60-4818-8605-bb89db2b26a5@github.com>

On Fri, 19 Nov 2021 06:41:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial patch to fix the include guard name in G1EvacFailureObjectsSet.hpp

Ship it. Agree that this is trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6474


From sjohanss at openjdk.java.net  Fri Nov 19 10:13:41 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 19 Nov 2021 10:13:41 GMT
Subject: RFR: 8277439: G1: Correct include guard name in
 G1EvacFailureObjectsSet.hpp
In-Reply-To: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
References: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
Message-ID: <GnRNATR4DhoULltwc-g7T4YE7z9GWG9-88tK9ILyBkY=.0b61c09c-2c92-4ddb-996e-8945cda41386@github.com>

On Fri, 19 Nov 2021 06:41:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial patch to fix the include guard name in G1EvacFailureObjectsSet.hpp

Marked as reviewed by sjohanss (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6474


From mli at openjdk.java.net  Fri Nov 19 10:18:46 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 10:18:46 GMT
Subject: RFR: 8277439: G1: Correct include guard name in
 G1EvacFailureObjectsSet.hpp
In-Reply-To: <VSdmdHa7EzRx5m8Ly4rPjjWIQMqsP_WaPl_dFczMJQk=.c2e6dd3c-1b60-4818-8605-bb89db2b26a5@github.com>
References: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
 <VSdmdHa7EzRx5m8Ly4rPjjWIQMqsP_WaPl_dFczMJQk=.c2e6dd3c-1b60-4818-8605-bb89db2b26a5@github.com>
Message-ID: <RvW_N4-y309ob5miDiodgesDu2ZQyM0xGYvfE3eQRU8=.51bc4843-e0c8-4171-99fc-67960ae4440d@github.com>

On Fri, 19 Nov 2021 09:41:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This is a trivial patch to fix the include guard name in G1EvacFailureObjectsSet.hpp
>
> Ship it. Agree that this is trivial.

Thanks @tschatzl @kstefanj for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6474


From mli at openjdk.java.net  Fri Nov 19 10:18:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 10:18:47 GMT
Subject: Integrated: 8277439: G1: Correct include guard name in
 G1EvacFailureObjectsSet.hpp
In-Reply-To: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
References: <oc4Qy3f8ijjulueaxKUgJWjkU4ZPwjBQKw-H0bTgZJ0=.ceebedce-fd47-4c2d-8f27-8b4ccfdf1f8c@github.com>
Message-ID: <eb34ksfl92VKhmghJxC52PUflrsmIajmlXnfALsY_W4=.65806083-90b8-4aa0-b1fb-6b604d1ccf22@github.com>

On Fri, 19 Nov 2021 06:41:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial patch to fix the include guard name in G1EvacFailureObjectsSet.hpp

This pull request has now been integrated.

Changeset: 11d819d6
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11d819d68a3ce2ae0973b496141c52aa419f90f0
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8277439: G1: Correct include guard name in G1EvacFailureObjectsSet.hpp

Reviewed-by: tschatzl, sjohanss

-------------

PR: https://git.openjdk.java.net/jdk/pull/6474


From tschatzl at openjdk.java.net  Fri Nov 19 10:36:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 19 Nov 2021 10:36:37 GMT
Subject: RFR: 8277428: G1: Move G1STWIsAliveClosure::do_object_b definition
 back to g1CollectedHeap.cpp
In-Reply-To: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
Message-ID: <iVgl2qVwB2wqZtvPmH7UpY7plrmqVX-ZDOVrsK0vX0k=.534888cc-24b4-4e8a-b862-0299684c0c96@github.com>

On Fri, 19 Nov 2021 03:29:04 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.cpp.

Without checking performance, I think the definition should be moved to `g1CollectedHeap.inline.hpp`, not the .cpp file (and includes fixed up).

It's used on every reference for a few operations.

-------------

Changes requested by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6470


From tschatzl at openjdk.java.net  Fri Nov 19 10:57:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 19 Nov 2021 10:57:49 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <ByNxndvW9yiO7d2zgh4dDwCdNJMz6XVwMpv-tKz-ZWY=.ffa2eab0-fe85-4b79-8746-c39e5a396751@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
 <ByNxndvW9yiO7d2zgh4dDwCdNJMz6XVwMpv-tKz-ZWY=.ffa2eab0-fe85-4b79-8746-c39e5a396751@github.com>
Message-ID: <E9XKIfH80cjSC1L1lN69wmCnik51p3hKXIHexceUboo=.f6279cde-5099-45cb-bcb3-96d7fb6c7707@github.com>

On Thu, 18 Nov 2021 21:52:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change to avoid compilation issue in hs builds
>
> Just some minor comments/suggestions.

CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) and release note (https://bugs.openjdk.java.net/browse/JDK-8277448) are done. After addressing @albertnetymk 's comments this is ready to go.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5838


From mli at openjdk.java.net  Fri Nov 19 11:34:21 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 11:34:21 GMT
Subject: RFR: 8277428: G1: Move G1STWIsAliveClosure::do_object_b definition
 back to g1CollectedHeap.cpp [v2]
In-Reply-To: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
Message-ID: <Him1P3iIKHpt2aKf9XQC5XEOyUvhBBhKwCBVwyLfkmY=.a17079ff-c3b3-4c12-8a35-88e07337858f@github.com>

> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.cpp.

Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into move-G1STWIsAliveClosure-do_object_b
 - Inline G1STWIsAliveClosure::do_object_b
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6470/files
  - new: https://git.openjdk.java.net/jdk/pull/6470/files/65bb61c1..1612e833

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6470&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6470&range=00-01

  Stats: 41851 lines in 729 files changed: 30266 ins; 5463 del; 6122 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6470/head:pull/6470

PR: https://git.openjdk.java.net/jdk/pull/6470


From mli at openjdk.java.net  Fri Nov 19 11:34:22 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 19 Nov 2021 11:34:22 GMT
Subject: RFR: 8277428: G1: Move G1STWIsAliveClosure::do_object_b definition
 back to g1CollectedHeap.cpp
In-Reply-To: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
Message-ID: <Nhzj32Ay9g7_BEVcT10fRUsZgHiTxa6mDa-VvZktZIA=.3a266ec7-2dd3-4837-ad61-73e5fa36dc71@github.com>

On Fri, 19 Nov 2021 03:29:04 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.cpp.

Thanks Thomas.

Not sure if this method be inlined in original code, but I inline it anyway as you suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6470


From duke at openjdk.java.net  Fri Nov 19 13:06:17 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Fri, 19 Nov 2021 13:06:17 GMT
Subject: RFR: 8272773: Configurable card table card size [v9]
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <p68xjRjaTfd-bU9jzfRxnQfK-L88KimrbG32kUXLmok=.f305312d-60b9-46b5-9b41-aab3c98f1db1@github.com>

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:

  Changes to address @albertnetymk comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5838/files
  - new: https://git.openjdk.java.net/jdk/pull/5838/files/6d7b0844..a3551a0e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=07-08

  Stats: 8 lines in 4 files changed: 4 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5838.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838

PR: https://git.openjdk.java.net/jdk/pull/5838


From duke at openjdk.java.net  Fri Nov 19 13:06:18 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Fri, 19 Nov 2021 13:06:18 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <ByNxndvW9yiO7d2zgh4dDwCdNJMz6XVwMpv-tKz-ZWY=.ffa2eab0-fe85-4b79-8746-c39e5a396751@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
 <ByNxndvW9yiO7d2zgh4dDwCdNJMz6XVwMpv-tKz-ZWY=.ffa2eab0-fe85-4b79-8746-c39e5a396751@github.com>
Message-ID: <D9O2viKkZauPDt_U2LnzPyM_XMfJFasH2vo4WkJxlpM=.970c7db0-6b1c-4899-a729-e8ab4de6fb93@github.com>

On Thu, 18 Nov 2021 21:52:12 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change to avoid compilation issue in hs builds
>
> Just some minor comments/suggestions.

> CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) and release note (https://bugs.openjdk.java.net/browse/JDK-8277448) are done. After addressing @albertnetymk 's comments this is ready to go.

@tschatzl I've added a new patch to address @albertnetymk 's comments

-------------

PR: https://git.openjdk.java.net/jdk/pull/5838


From sjohanss at openjdk.java.net  Fri Nov 19 13:17:47 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 19 Nov 2021 13:17:47 GMT
Subject: RFR: 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 [v2]
In-Reply-To: <Him1P3iIKHpt2aKf9XQC5XEOyUvhBBhKwCBVwyLfkmY=.a17079ff-c3b3-4c12-8a35-88e07337858f@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
 <Him1P3iIKHpt2aKf9XQC5XEOyUvhBBhKwCBVwyLfkmY=.a17079ff-c3b3-4c12-8a35-88e07337858f@github.com>
Message-ID: <6Lz72sQfWMcotTOUEEMiCC_XIJOcmg7cW2K730UQdL8=.c54160dd-d261-410e-a2cc-1ed26552478b@github.com>

On Fri, 19 Nov 2021 11:34:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.inline.hpp.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into move-G1STWIsAliveClosure-do_object_b
>  - Inline G1STWIsAliveClosure::do_object_b
>  - Initial commit

A lot of the changes to include `g1CollectedHeap.inline.hpp` look strange to me, are they really needed? And the normal `hpp`-files that now include it are wrong, we should never have normal `hpp`-files including `inline.hpp`-files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6470


From tschatzl at openjdk.java.net  Fri Nov 19 14:05:44 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 19 Nov 2021 14:05:44 GMT
Subject: RFR: 8272773: Configurable card table card size [v9]
In-Reply-To: <p68xjRjaTfd-bU9jzfRxnQfK-L88KimrbG32kUXLmok=.f305312d-60b9-46b5-9b41-aab3c98f1db1@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <p68xjRjaTfd-bU9jzfRxnQfK-L88KimrbG32kUXLmok=.f305312d-60b9-46b5-9b41-aab3c98f1db1@github.com>
Message-ID: <3PzkhnuL2m4E7s8SzrVD7ddZ5qLXAiy8LhBXUoIc3eM=.7384fb44-e2ff-47c9-b3a9-f63625804636@github.com>

On Fri, 19 Nov 2021 13:06:17 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes to address @albertnetymk comments

lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5838


From eosterlund at openjdk.java.net  Fri Nov 19 17:31:59 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 19 Nov 2021 17:31:59 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <DYDWnyEeUvh8t5EpqqRDYXdIBDThM-UKN_hwzu1PHpk=.98d15ca4-29e3-4a26-a9be-d073bf942050@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

Marked as reviewed by eosterlund (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From duke at openjdk.java.net  Fri Nov 19 19:30:14 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Fri, 19 Nov 2021 19:30:14 GMT
Subject: RFR: 8272773: Configurable card table card size [v8]
In-Reply-To: <E9XKIfH80cjSC1L1lN69wmCnik51p3hKXIHexceUboo=.f6279cde-5099-45cb-bcb3-96d7fb6c7707@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <bbAikSVtytXqC8LFmboIhPnTRq_TIyANe3_rEn_r3ko=.95f26ca0-a72b-456d-9dea-bdd5b64dcecc@github.com>
 <ByNxndvW9yiO7d2zgh4dDwCdNJMz6XVwMpv-tKz-ZWY=.ffa2eab0-fe85-4b79-8746-c39e5a396751@github.com>
 <E9XKIfH80cjSC1L1lN69wmCnik51p3hKXIHexceUboo=.f6279cde-5099-45cb-bcb3-96d7fb6c7707@github.com>
Message-ID: <ZQZhSQ-ILJmZC2hXm1ZWXQzfZUibrUfjf-_ICPkLQIM=.c0bf6719-9f1e-4c86-af72-b1a45c681483@github.com>

On Fri, 19 Nov 2021 10:54:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Just some minor comments/suggestions.
>
> CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) and release note (https://bugs.openjdk.java.net/browse/JDK-8277448) are done. After addressing @albertnetymk 's comments this is ready to go.

@tschatzl is there anything else left from my end?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5838


From tschatzl at openjdk.java.net  Sat Nov 20 09:26:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Sat, 20 Nov 2021 09:26:12 GMT
Subject: RFR: 8272773: Configurable card table card size [v9]
In-Reply-To: <p68xjRjaTfd-bU9jzfRxnQfK-L88KimrbG32kUXLmok=.f305312d-60b9-46b5-9b41-aab3c98f1db1@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
 <p68xjRjaTfd-bU9jzfRxnQfK-L88KimrbG32kUXLmok=.f305312d-60b9-46b5-9b41-aab3c98f1db1@github.com>
Message-ID: <lDsXDeX2Ljk4irSA_bepaC2DTtYHTJxHpiQXrPPB3Yc=.f0c1c019-b98f-403f-8c02-a064bc824fa8@github.com>

On Fri, 19 Nov 2021 13:06:17 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
>> 
>> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
>> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
>> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.
>
> Vishal Chand has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes to address @albertnetymk comments

As the bot suggested:

>To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

Then I'll do the sponsoring (/sponsor) if necesasry.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5838


From duke at openjdk.java.net  Sat Nov 20 10:07:12 2021
From: duke at openjdk.java.net (Vishal Chand)
Date: Sat, 20 Nov 2021 10:07:12 GMT
Subject: Integrated: 8272773: Configurable card table card size
In-Reply-To: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
References: <X3_R9YVv1eWM4aNF_omDn-DPHulPM8pUl0Pv8CMt8Dk=.28703e9e-18e4-4cc5-84e0-88aca5d90fd6@github.com>
Message-ID: <_TnsGsSQkbn75OoqSkXNvyOaUzEZGQvQ-kgPYrBQmyU=.7c724c82-6d63-4638-b6a0-5caeb7c1301c@github.com>

On Wed, 6 Oct 2021 12:50:25 GMT, Vishal Chand <duke at openjdk.java.net> wrote:

> Hi,
> 
> Please review the changes to make CardTable entry size configurable. The changes primarily consists of:
> 
> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable.
> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths.
> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size.

This pull request has now been integrated.

Changeset: 1c215f33
Author:    Vishal Chand <vishalchand2492 at gmail.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1c215f33698ba2aef4fb230475a9bd33ed3005f9
Stats:     115 lines in 13 files changed: 91 ins; 4 del; 20 mod

8272773: Configurable card table card size

Reviewed-by: tschatzl, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/5838


From jbachorik at openjdk.java.net  Sat Nov 20 12:10:16 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Sat, 20 Nov 2021 12:10:16 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <1ar4WRPlOYCGpmV-ROI9LI7CoX-2YS_XuLnF7Zdgeik=.89d41895-8ca6-4d50-bc21-5a6f4caf0302@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

Marked as reviewed by jbachorik (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From lmesnik at openjdk.java.net  Sun Nov 21 00:17:05 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Sun, 21 Nov 2021 00:17:05 GMT
Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent
In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
Message-ID: <U1Tl86YO1BXQa8cSqAwDECqrOpl6z6cd-SqrN1h8ajk=.5fa84d8a-268d-430b-88e0-99e25049815d@github.com>

On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8277413: Remove unused local variables in jdk.hotspot.agent

Marked as reviewed by lmesnik (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6329


From mli at openjdk.java.net  Mon Nov 22 03:35:10 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 03:35:10 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v6]
In-Reply-To: <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
Message-ID: <18ChXiJXU2kFT98S9WMTIeCnO0SGZ540bJ_07p-hVf0=.9be59af6-de04-4de3-ae16-b0c8b8550b4a@github.com>

On Fri, 19 Nov 2021 04:49:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge with master
>  - Rename card set to segmented array
>  - Rename from G1BufferListXxx to G1SegmentedArrayXxx
>  - Fix typo
>  - Merge branch 'master' into rename-move-G1CardSetFreePool-out
>  - Fix typos
>  - Fix gtest tests
>  - Fix missing in test
>  - Fix missing files
>  - move g1CardSetFreeMemoryTask.*
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f0bde1a...7cfe01fb

kindly reminder ~

-------------

PR: https://git.openjdk.java.net/jdk/pull/6289


From mli at openjdk.java.net  Mon Nov 22 03:40:28 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 03:40:28 GMT
Subject: RFR: 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 [v3]
In-Reply-To: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
Message-ID: <FDDQYq-GUZpXaSYMnSPkbZZcyZh6rxnviqNgFv3zEwE=.96602522-efc4-4dc7-94e8-4a5f9d5e43f2@github.com>

> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.inline.hpp.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Stefan review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6470/files
  - new: https://git.openjdk.java.net/jdk/pull/6470/files/1612e833..99eaad0d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6470&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6470&range=01-02

  Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6470/head:pull/6470

PR: https://git.openjdk.java.net/jdk/pull/6470


From mli at openjdk.java.net  Mon Nov 22 03:40:33 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 03:40:33 GMT
Subject: RFR: 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 [v2]
In-Reply-To: <Him1P3iIKHpt2aKf9XQC5XEOyUvhBBhKwCBVwyLfkmY=.a17079ff-c3b3-4c12-8a35-88e07337858f@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
 <Him1P3iIKHpt2aKf9XQC5XEOyUvhBBhKwCBVwyLfkmY=.a17079ff-c3b3-4c12-8a35-88e07337858f@github.com>
Message-ID: <J9Kqc659Zv8IlJlwZfo_UKogo5UjOfewiSo586FBBiY=.a1e95668-1133-49ef-8f61-8346ba2bdcd7@github.com>

On Fri, 19 Nov 2021 11:34:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.inline.hpp.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into move-G1STWIsAliveClosure-do_object_b
>  - Inline G1STWIsAliveClosure::do_object_b
>  - Initial commit

Thanks Stefan, I remove the unnecessary inline includes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6470


From tschatzl at openjdk.java.net  Mon Nov 22 08:30:17 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 08:30:17 GMT
Subject: RFR: 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 [v3]
In-Reply-To: <FDDQYq-GUZpXaSYMnSPkbZZcyZh6rxnviqNgFv3zEwE=.96602522-efc4-4dc7-94e8-4a5f9d5e43f2@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
 <FDDQYq-GUZpXaSYMnSPkbZZcyZh6rxnviqNgFv3zEwE=.96602522-efc4-4dc7-94e8-4a5f9d5e43f2@github.com>
Message-ID: <CL8ZF1tnwkkuLEi8dB4NEic5PciJ61XKfY4NMddVE7s=.a2aa28c2-e7c9-4d79-adb1-a3366af22447@github.com>

On Mon, 22 Nov 2021 03:40:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.inline.hpp.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan review

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6470


From ayang at openjdk.java.net  Mon Nov 22 09:33:27 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 09:33:27 GMT
Subject: RFR: 8277534: Remove unused
 ReferenceProcessor::has_discovered_references
Message-ID: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>

Trivial change of removing dead code.

Test: build

-------------

Commit messages:
 - trivial

Changes: https://git.openjdk.java.net/jdk/pull/6496/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6496&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277534
  Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6496.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6496/head:pull/6496

PR: https://git.openjdk.java.net/jdk/pull/6496


From ayang at openjdk.java.net  Mon Nov 22 09:44:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 09:44:12 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v6]
In-Reply-To: <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
Message-ID: <sPEqB-ZucarzsAMpEDqZbHEprj1Vk0BDh6Q7JB48PSo=.07e4a16d-f07a-49be-bc7f-1388a32b667a@github.com>

On Fri, 19 Nov 2021 04:49:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge with master
>  - Rename card set to segmented array
>  - Rename from G1BufferListXxx to G1SegmentedArrayXxx
>  - Fix typo
>  - Merge branch 'master' into rename-move-G1CardSetFreePool-out
>  - Fix typos
>  - Fix gtest tests
>  - Fix missing in test
>  - Fix missing files
>  - move g1CardSetFreeMemoryTask.*
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f0bde1a...7cfe01fb

I think splitting "move" and "rename" into two PRs (the current commits history is a bit hard to follow) will make the review process much easier and the included meaningful changes more discernible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6289


From tschatzl at openjdk.java.net  Mon Nov 22 09:55:14 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 09:55:14 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v6]
In-Reply-To: <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
Message-ID: <e33n2oiKQH1a1ComsDYw57aKj8Vs4iNw_rTKDLKmC5c=.8045b941-c450-409a-b4a1-bd3e3d6de6a1@github.com>

On Fri, 19 Nov 2021 04:49:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge with master
>  - Rename card set to segmented array
>  - Rename from G1BufferListXxx to G1SegmentedArrayXxx
>  - Fix typo
>  - Merge branch 'master' into rename-move-G1CardSetFreePool-out
>  - Fix typos
>  - Fix gtest tests
>  - Fix missing in test
>  - Fix missing files
>  - move g1CardSetFreeMemoryTask.*
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f0bde1a...7cfe01fb

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1CardSetMemory.cpp line 28:

> 26: 
> 27: #include "gc/g1/g1CardSetMemory.inline.hpp"
> 28: #include "gc/g1/g1CardSetContainers.inline.hpp"

Include order, must be sorted alphabetically

src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 28:

> 26: #define SHARE_GC_G1_G1CARDSETMEMORY_HPP
> 27: 
> 28: #include "gc/g1/g1SegmentedArrayFreePool.hpp"

Include order, must be sorted alphabetically

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 36:

> 34: #include "gc/g1/g1BarrierSet.hpp"
> 35: #include "gc/g1/g1BatchedTask.hpp"
> 36: #include "gc/g1/g1SegmentedArrayFreeMemoryTask.hpp"

Include order, must be sorted alphabetically

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 30:

> 28: #include "gc/g1/g1BarrierSet.hpp"
> 29: #include "gc/g1/g1BiasedArray.hpp"
> 30: #include "gc/g1/g1SegmentedArrayFreeMemoryTask.hpp"

Include order, must be sorted alphabetically

src/hotspot/share/gc/g1/g1SegmentedArrayFreeMemoryTask.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #include "gc/g1/g1SegmentedArrayFreeMemoryTask.hpp"

Include order, must be sorted alphabetically

src/hotspot/share/gc/g1/g1SegmentedArrayFreeMemoryTask.cpp line 42:

> 40: 
> 41: bool G1SegmentedArrayFreeMemoryTask::deadline_exceeded(jlong deadline) {
> 42:   return os::elapsed_counter() >= deadline;

The include for `os` seems to be missing (pre-existing)

src/hotspot/share/gc/g1/g1SegmentedArrayFreeMemoryTask.hpp line 29:

> 27: 
> 28: #include "gc/g1/g1ServiceThread.hpp"
> 29: #include "gc/g1/g1SegmentedArrayFreePool.hpp"

Include order, must be sorted alphabetically

src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.hpp line 32:

> 30: #include "utilities/growableArray.hpp"
> 31: 
> 32: // Statistics for a fixed set of buffer lists. Contains the number of buffers and memory

s/fixed set of buffer lists/segmented array/ 
Contains the number of segments and memory.... Afair that's part of the other renaming change coming up.

src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.hpp line 39:

> 37: 
> 38:   size_t _num_mem_sizes[G1CardSetConfiguration::num_mem_object_types()];
> 39:   size_t _num_buffers[G1CardSetConfiguration::num_mem_object_types()];

The renaming of `_num_buffers` to `_num_segments` should be done in the other renaming change (which is fine).

src/hotspot/share/gc/g1/g1YoungCollector.hpp line 36:

> 34: class G1Allocator;
> 35: class G1BatchedTask;
> 36: class G1SegmentedArrayMemoryStats;

Must be sorted alphabetically.

test/hotspot/gtest/gc/g1/test_g1CardSet.cpp line 25:

> 23: 
> 24: #include "precompiled.hpp"
> 25: #include "gc/g1/g1SegmentedArrayFreePool.hpp"

Must be sorted alphabetically.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6289


From tschatzl at openjdk.java.net  Mon Nov 22 10:02:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 10:02:05 GMT
Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent
In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
Message-ID: <ZmiFFfE62cSkbVkQ4Z7DnAVD5VcJO-j4tNyH1uO5kgg=.b179dda2-3ce5-4231-bf0b-f5e9e98963d7@github.com>

On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8277413: Remove unused local variables in jdk.hotspot.agent

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6329


From tschatzl at openjdk.java.net  Mon Nov 22 10:02:11 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 10:02:11 GMT
Subject: RFR: 8277534: Remove unused
 ReferenceProcessor::has_discovered_references
In-Reply-To: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>
References: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>
Message-ID: <4NSVU0pA458GXToHkq6r5pvuu2iHCQkaWWdzSwlokFs=.b7f282f4-4e14-4bf1-9e24-99dd89b96d6b@github.com>

On Mon, 22 Nov 2021 09:24:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Lgtm and trivial

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6496


From ayang at openjdk.java.net  Mon Nov 22 10:02:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 10:02:12 GMT
Subject: RFR: 8277534: Remove unused
 ReferenceProcessor::has_discovered_references
In-Reply-To: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>
References: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>
Message-ID: <wOrHXrMVqKYq-fggB46eJyGpoy6vvaIeL7AifroV9GA=.ff242199-b661-4ce3-9214-cf061b296202@github.com>

On Mon, 22 Nov 2021 09:24:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6496


From ayang at openjdk.java.net  Mon Nov 22 10:02:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 10:02:12 GMT
Subject: Integrated: 8277534: Remove unused
 ReferenceProcessor::has_discovered_references
In-Reply-To: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>
References: <jZCAZWx05VLJScnKIa8VsxO4hwiF2UJsRkGluWStfZQ=.f35cad14-311e-4aa3-b13e-fe8efa521d5f@github.com>
Message-ID: <V2TK5noqrvs_-CwZsOqDZ5FQU3xhCL1dfV2OiUhV1Yg=.8cdbb80a-c6f2-4f4a-9a11-8d7160c2ed14@github.com>

On Mon, 22 Nov 2021 09:24:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: 8051041e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8051041eb2b3d70d4cc62b6f2726279d51e44733
Stats:     12 lines in 2 files changed: 0 ins; 12 del; 0 mod

8277534: Remove unused ReferenceProcessor::has_discovered_references

Reviewed-by: tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6496


From mgronlun at openjdk.java.net  Mon Nov 22 10:28:11 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 22 Nov 2021 10:28:11 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <DfsGFLVLIMU0kVrY0jod-67WKErvxOsntkCvY5Rm0ms=.eb82713e-2312-4c9a-9892-fa8f40f32594@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

What's the overhead of this event being enabled in default.jfc with threshold=0? Do all users really need to have this experimental event enabled by default when running ZGC?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From sspitsyn at openjdk.java.net  Mon Nov 22 10:36:07 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Mon, 22 Nov 2021 10:36:07 GMT
Subject: RFR: 8277413: Remove unused local variables in jdk.hotspot.agent
In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
Message-ID: <jRT2bKogQA_CpVntnFIKxKx_w1ds8YplIuz3ZyT36Rk=.2f61c2fa-0cf6-47dc-8be5-1acf5d141152@github.com>

On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8277413: Remove unused local variables in jdk.hotspot.agent

Looks good.
Thanks,
Serguei

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6329


From stefank at openjdk.java.net  Mon Nov 22 10:46:08 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 22 Nov 2021 10:46:08 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <t_anK2EyJDxKzYKuqQQHjaVX2ynMrmha7rrddlK30mc=.39105559-257e-4788-a842-0030e64dffe6@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

> 

The overhead should be virtually zero, since no event is sent. Having this turned off by default makes this feature more annoying to use. Is this causing problems for the users?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From sjohanss at openjdk.java.net  Mon Nov 22 10:49:12 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 22 Nov 2021 10:49:12 GMT
Subject: RFR: 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 [v3]
In-Reply-To: <FDDQYq-GUZpXaSYMnSPkbZZcyZh6rxnviqNgFv3zEwE=.96602522-efc4-4dc7-94e8-4a5f9d5e43f2@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
 <FDDQYq-GUZpXaSYMnSPkbZZcyZh6rxnviqNgFv3zEwE=.96602522-efc4-4dc7-94e8-4a5f9d5e43f2@github.com>
Message-ID: <fULIw6YRXrg8hIxNabzt5kpAYGPAWW8JhxpQfOVfZb4=.7dbd503b-499a-44ba-930b-687c0d48d701@github.com>

On Mon, 22 Nov 2021 03:40:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.inline.hpp.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan review

?

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6470


From mgronlun at openjdk.java.net  Mon Nov 22 10:56:08 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 22 Nov 2021 10:56:08 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <U_KOD_jPVFNlhHSHcwcH8zaiyrlu8Fhoe9XY8WI_GAw=.7d3ca634-a478-4d49-80ea-c3cf3d4cbba0@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

Ah. So "debug" means only used in "development builds" of the VM? In that case, there is no problem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From stefank at openjdk.java.net  Mon Nov 22 10:56:08 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 22 Nov 2021 10:56:08 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <gRa39pRv8q_lqKQMvWUQZokL9hw-gom9JtVBD9HgEO8=.4e165539-bf3e-43b0-8a8f-8ab4ce9f3b04@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

> 

No, this is more likely to be used in release builds to identify and measure performance issues in ZGC. It is intended for us during debugging and development of various features in ZGC.

Think of this similar to the UseNewCode flag.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From mgronlun at openjdk.java.net  Mon Nov 22 11:01:11 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 22 Nov 2021 11:01:11 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <I88EnF3eThoX0A9kDFnlfN-gom-clUXXBCeuNb8HAKk=.178f1345-5f47-495d-bed6-d8eac8ad29cf@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

Marked as reviewed by mgronlun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From mli at openjdk.java.net  Mon Nov 22 11:30:17 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 11:30:17 GMT
Subject: Integrated: 8277428: G1: Move and inline
 G1STWIsAliveClosure::do_object_b
In-Reply-To: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
Message-ID: <tK7m2WHtS5nGtnWnBVKlJ9YDvP-7Vszhy9CSbYtibsk=.143c9f25-6906-498e-a623-d5f8dbf50558@github.com>

On Fri, 19 Nov 2021 03:29:04 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a trivial patch to move G1STWIsAliveClosure::do_object_b definition to the right file g1CollectedHeap.inline.hpp.

This pull request has now been integrated.

Changeset: d427c79d
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d427c79d3bd6c80b67c10d15a461f13ae7e0f84b
Stats:     13 lines in 2 files changed: 6 ins; 6 del; 1 mod

8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b

Reviewed-by: tschatzl, sjohanss

-------------

PR: https://git.openjdk.java.net/jdk/pull/6470


From mli at openjdk.java.net  Mon Nov 22 11:30:16 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 11:30:16 GMT
Subject: RFR: 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b
 [v3]
In-Reply-To: <CL8ZF1tnwkkuLEi8dB4NEic5PciJ61XKfY4NMddVE7s=.a2aa28c2-e7c9-4d79-adb1-a3366af22447@github.com>
References: <0z2c8z7EI1sr5oHfk2hXY_5j2EWAyd7F0y5sk5yj09Y=.372755c6-be13-4278-ae8b-9db1ad352e9b@github.com>
 <FDDQYq-GUZpXaSYMnSPkbZZcyZh6rxnviqNgFv3zEwE=.96602522-efc4-4dc7-94e8-4a5f9d5e43f2@github.com>
 <CL8ZF1tnwkkuLEi8dB4NEic5PciJ61XKfY4NMddVE7s=.a2aa28c2-e7c9-4d79-adb1-a3366af22447@github.com>
Message-ID: <an3zvILJ5RR2lAtlNbY_04zNZ6oXdpd3fwLhFryBUDE=.e9070c42-8a09-4b61-937a-a6be12c6bd88@github.com>

On Mon, 22 Nov 2021 08:26:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Stefan review
>
> Lgtm.

Thansk @tschatzl @kstefanj for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6470


From mli at openjdk.java.net  Mon Nov 22 11:37:14 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 11:37:14 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v6]
In-Reply-To: <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
Message-ID: <ZbEHp8GasfRSq8_cr8NJ7kaeACOFc3nzEkQ1FpGtrrc=.b6f45fec-332d-488c-abe3-acb05f1f07ab@github.com>

On Fri, 19 Nov 2021 04:49:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge with master
>  - Rename card set to segmented array
>  - Rename from G1BufferListXxx to G1SegmentedArrayXxx
>  - Fix typo
>  - Merge branch 'master' into rename-move-G1CardSetFreePool-out
>  - Fix typos
>  - Fix gtest tests
>  - Fix missing in test
>  - Fix missing files
>  - move g1CardSetFreeMemoryTask.*
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f0bde1a...7cfe01fb

I will put the "move" in a separate PR and later "rename" in another PR (including Thomas's suggestion till now)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6289


From mli at openjdk.java.net  Mon Nov 22 11:45:31 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 22 Nov 2021 11:45:31 GMT
Subject: RFR: 8277542: G1: Move G1CardSetFreePool and related classes to
 separate files
Message-ID: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>

As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6499/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6499&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277542
  Stats: 582 lines in 4 files changed: 326 ins; 256 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6499.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6499/head:pull/6499

PR: https://git.openjdk.java.net/jdk/pull/6499


From ayang at openjdk.java.net  Mon Nov 22 13:50:11 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 13:50:11 GMT
Subject: RFR: 8277556: Call ReferenceProcessorPhaseTimes::set_processing_is_mt
 once
Message-ID: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>

Simple change of moving the call site of `set_processing_is_mt`.

Test: hotspot_gc

-------------

Commit messages:
 - set_processing_is_mt

Changes: https://git.openjdk.java.net/jdk/pull/6500/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6500&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277556
  Stats: 6 lines in 1 file changed: 2 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6500.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6500/head:pull/6500

PR: https://git.openjdk.java.net/jdk/pull/6500


From sjohanss at openjdk.java.net  Mon Nov 22 14:37:13 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 22 Nov 2021 14:37:13 GMT
Subject: RFR: 8277556: Call
 ReferenceProcessorPhaseTimes::set_processing_is_mt once
In-Reply-To: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
References: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
Message-ID: <Xsxmx_-AMWQQc5Yn4175qOk1FCAC8m2JZwRoesQSLHU=.8460d925-2b5a-4819-a4cb-d51f549d75a2@github.com>

On Mon, 22 Nov 2021 13:44:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving the call site of `set_processing_is_mt`.
> 
> Test: hotspot_gc

Marked as reviewed by sjohanss (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6500


From ayang at openjdk.java.net  Mon Nov 22 14:46:31 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 14:46:31 GMT
Subject: RFR: 8277542: G1: Move G1CardSetFreePool and related classes to
 separate files
In-Reply-To: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
References: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
Message-ID: <Kqb8cPABQFrd6yX-mWSKsSYqCI56yktY8oGIRzDMddw=.196311d0-83ad-4272-8ab2-d6d1a1c19038@github.com>

On Mon, 22 Nov 2021 11:38:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out.

I was using `git diff --color-moved` to help me review the diff. However, the unnecessary change to
`G1CardSetFreePool::free_list` (moving from hpp to cpp) introduced some friction. Please refrain from mixing mechanical and manual changes in the same commit; you can use a second commit in this PR for the manual tuning.

I see the same def is duplicated in two places:
in `g1SegmentedArrayFreePool.hpp`:

typedef G1SegmentedArrayBuffer<mtGCCardSet> G1CardSetBuffer;
typedef G1SegmentedArrayBufferList<mtGCCardSet> G1CardSetBufferList;

and `g1CardSetMemory.hpp`:


typedef G1SegmentedArrayBuffer<mtGCCardSet> G1CardSetBuffer;

typedef G1SegmentedArrayBufferList<mtGCCardSet> G1CardSetBufferList;


I believe such duplication is only transient -- later refactoring/renaming will fix this, so I am fine with the current PR.

-------------

Marked as reviewed by ayang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6499


From ayang at openjdk.java.net  Mon Nov 22 14:03:37 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 14:03:37 GMT
Subject: RFR: 8277560: Remove WorkerDataArray::_is_serial
Message-ID: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>

Simple change of removing effectively dead code.

Test: build

-------------

Commit messages:
 - WorkerDataArray._is_serial

Changes: https://git.openjdk.java.net/jdk/pull/6502/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6502&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277560
  Stats: 35 lines in 2 files changed: 5 ins; 15 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6502.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6502/head:pull/6502

PR: https://git.openjdk.java.net/jdk/pull/6502


From sjohanss at openjdk.java.net  Mon Nov 22 15:07:21 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 22 Nov 2021 15:07:21 GMT
Subject: RFR: 8277560: Remove WorkerDataArray::_is_serial [v2]
In-Reply-To: <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
References: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
 <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
Message-ID: <Mh5wkrUGDvb7HDgpNNkPue1q7i67Bj9asnzcoFboaYY=.fe57dd6b-562e-4d82-939b-1508ab164207@github.com>

On Mon, 22 Nov 2021 15:03:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good, but please do the additional removal mentioned below.

src/hotspot/share/gc/shared/workerDataArray.inline.hpp line 173:

> 171:   if (start < _length) {
> 172:     if (_is_serial) {
> 173:       WDAPrinter::summary(out, get(0));

>From what I can tell these two function will no longer be used after your change:

WDAPrinter::summary(outputStream* out, double time);
WDAPrinter::summary(outputStream* out, size_t value);

Please remove them.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6502


From ayang at openjdk.java.net  Mon Nov 22 15:07:22 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 15:07:22 GMT
Subject: RFR: 8277560: Remove WorkerDataArray::_is_serial [v2]
In-Reply-To: <Mh5wkrUGDvb7HDgpNNkPue1q7i67Bj9asnzcoFboaYY=.fe57dd6b-562e-4d82-939b-1508ab164207@github.com>
References: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
 <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
 <Mh5wkrUGDvb7HDgpNNkPue1q7i67Bj9asnzcoFboaYY=.fe57dd6b-562e-4d82-939b-1508ab164207@github.com>
Message-ID: <qwIJR1Z7dK_-yzutf2VE9urxcZQiBMc9NrH-yjWUhJw=.1b7cde36-71de-4bde-bc6a-8111436fb371@github.com>

On Mon, 22 Nov 2021 14:40:39 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/shared/workerDataArray.inline.hpp line 173:
> 
>> 171:   if (start < _length) {
>> 172:     if (_is_serial) {
>> 173:       WDAPrinter::summary(out, get(0));
> 
> From what I can tell these two function will no longer be used after your change:
> 
> WDAPrinter::summary(outputStream* out, double time);
> WDAPrinter::summary(outputStream* out, size_t value);
> 
> Please remove them.

Removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6502


From ayang at openjdk.java.net  Mon Nov 22 15:07:20 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 22 Nov 2021 15:07:20 GMT
Subject: RFR: 8277560: Remove WorkerDataArray::_is_serial [v2]
In-Reply-To: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
References: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
Message-ID: <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>

> Simple change of removing effectively dead code.
> 
> Test: build

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6502/files
  - new: https://git.openjdk.java.net/jdk/pull/6502/files/7138fb8d..14926d2f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6502&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6502&range=00-01

  Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6502.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6502/head:pull/6502

PR: https://git.openjdk.java.net/jdk/pull/6502


From tschatzl at openjdk.java.net  Mon Nov 22 16:17:23 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 16:17:23 GMT
Subject: RFR: 8277560: Remove WorkerDataArray::_is_serial [v2]
In-Reply-To: <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
References: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
 <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
Message-ID: <OCzJ4p7End1UvCBibPb_B8_GqYAxyPERcSSt4CVJlT8=.2ddcb2d9-8e1c-4609-946e-ac61f0568076@github.com>

On Mon, 22 Nov 2021 15:07:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6502


From tschatzl at openjdk.java.net  Mon Nov 22 16:23:16 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 16:23:16 GMT
Subject: RFR: 8277556: Call
 ReferenceProcessorPhaseTimes::set_processing_is_mt once
In-Reply-To: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
References: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
Message-ID: <1vc4GXIE4Ad1HNVg_T99o6QIis9vwPI6lvuJlIOq_uM=.8966ae12-129d-472d-b530-3f964e405560@github.com>

On Mon, 22 Nov 2021 13:44:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving the call site of `set_processing_is_mt`.
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6500


From tschatzl at openjdk.java.net  Mon Nov 22 16:54:18 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 22 Nov 2021 16:54:18 GMT
Subject: RFR: 8277542: G1: Move G1CardSetFreePool and related classes to
 separate files
In-Reply-To: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
References: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
Message-ID: <J6WaF4DRuxn5Wt1Tz4gOvPxWSavfHvTQL2OX-oLrdAg=.26a70cb9-586a-4a46-abc7-ed6303db55f9@github.com>

On Mon, 22 Nov 2021 11:38:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6499


From dcubed at openjdk.java.net  Mon Nov 22 19:07:44 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 22 Nov 2021 19:07:44 GMT
Subject: Integrated: 8277576: ProblemList
 runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
Message-ID: <B8RyFsZR3ajgar90_oKmq6uPkJWmhhwvfuQLmI2VuEA=.7954457d-98bf-4dea-958c-6423176835c5@github.com>

A few trivial ProblemListings:

8277576 ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
8277577 ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64
8277578 ProblemList applications/jcstress/acqrel.java on linux-aarch64

-------------

Commit messages:
 - 8277578: ProblemList applications/jcstress/acqrel.java on linux-aarch64
 - 8277577: ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64
 - 8277576: ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64

Changes: https://git.openjdk.java.net/jdk/pull/6507/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6507&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277576
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6507.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6507/head:pull/6507

PR: https://git.openjdk.java.net/jdk/pull/6507


From mikael at openjdk.java.net  Mon Nov 22 19:07:44 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Mon, 22 Nov 2021 19:07:44 GMT
Subject: Integrated: 8277576: ProblemList
 runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
In-Reply-To: <B8RyFsZR3ajgar90_oKmq6uPkJWmhhwvfuQLmI2VuEA=.7954457d-98bf-4dea-958c-6423176835c5@github.com>
References: <B8RyFsZR3ajgar90_oKmq6uPkJWmhhwvfuQLmI2VuEA=.7954457d-98bf-4dea-958c-6423176835c5@github.com>
Message-ID: <RIiaQ6okGq57CldxxRFXACMPyOEo6zCYLi0AFB_7Hnk=.765ab904-7f0d-41c7-a59d-dbfbb6ef52e5@github.com>

On Mon, 22 Nov 2021 18:46:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A few trivial ProblemListings:
> 
> 8277576 ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
> 8277577 ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64
> 8277578 ProblemList applications/jcstress/acqrel.java on linux-aarch64

Marked as reviewed by mikael (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6507


From dcubed at openjdk.java.net  Mon Nov 22 19:07:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 22 Nov 2021 19:07:45 GMT
Subject: Integrated: 8277576: ProblemList
 runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
In-Reply-To: <RIiaQ6okGq57CldxxRFXACMPyOEo6zCYLi0AFB_7Hnk=.765ab904-7f0d-41c7-a59d-dbfbb6ef52e5@github.com>
References: <B8RyFsZR3ajgar90_oKmq6uPkJWmhhwvfuQLmI2VuEA=.7954457d-98bf-4dea-958c-6423176835c5@github.com>
 <RIiaQ6okGq57CldxxRFXACMPyOEo6zCYLi0AFB_7Hnk=.765ab904-7f0d-41c7-a59d-dbfbb6ef52e5@github.com>
Message-ID: <JYzV9fWXUJQ8TrswkzF4vJ7Qy2s9yVVgege3ONxLn6s=.9299fa27-e8a1-4ed9-8e8d-555d42d5c2db@github.com>

On Mon, 22 Nov 2021 18:52:20 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> A few trivial ProblemListings:
>> 
>> 8277576 ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
>> 8277577 ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64
>> 8277578 ProblemList applications/jcstress/acqrel.java on linux-aarch64
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6507


From dcubed at openjdk.java.net  Mon Nov 22 19:07:47 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 22 Nov 2021 19:07:47 GMT
Subject: Integrated: 8277576: ProblemList
 runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
In-Reply-To: <B8RyFsZR3ajgar90_oKmq6uPkJWmhhwvfuQLmI2VuEA=.7954457d-98bf-4dea-958c-6423176835c5@github.com>
References: <B8RyFsZR3ajgar90_oKmq6uPkJWmhhwvfuQLmI2VuEA=.7954457d-98bf-4dea-958c-6423176835c5@github.com>
Message-ID: <4uPl1LAAipGVsPSsdFq43CGDgxgXhy8VpCn1PKbu60E=.4cc6a6da-ac51-4efb-aaff-bc4cbcb7d304@github.com>

On Mon, 22 Nov 2021 18:46:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A few trivial ProblemListings:
> 
> 8277576 ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
> 8277577 ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64
> 8277578 ProblemList applications/jcstress/acqrel.java on linux-aarch64

This pull request has now been integrated.

Changeset: 1049aba1
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1049aba1fb65fd70bd723c80a84250512a68d653
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8277576: ProblemList runtime/ErrorHandling/CreateCoredumpOnCrash.java on macosx-X64
8277577: ProblemList compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java on linux-aarch64
8277578: ProblemList applications/jcstress/acqrel.java on linux-aarch64

Reviewed-by: mikael

-------------

PR: https://git.openjdk.java.net/jdk/pull/6507


From mli at openjdk.java.net  Tue Nov 23 01:01:13 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 23 Nov 2021 01:01:13 GMT
Subject: RFR: 8277542: G1: Move G1CardSetFreePool and related classes to
 separate files
In-Reply-To: <Kqb8cPABQFrd6yX-mWSKsSYqCI56yktY8oGIRzDMddw=.196311d0-83ad-4272-8ab2-d6d1a1c19038@github.com>
References: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
 <Kqb8cPABQFrd6yX-mWSKsSYqCI56yktY8oGIRzDMddw=.196311d0-83ad-4272-8ab2-d6d1a1c19038@github.com>
Message-ID: <fJgW4vOj_iOMfLenoBqDu2NRM9kkd44yokTanjePALo=.2c2a521b-c19a-470c-8343-70e2d58d1f75@github.com>

On Mon, 22 Nov 2021 14:43:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out.
>
> I was using `git diff --color-moved` to help me review the diff. However, the unnecessary change to
> `G1CardSetFreePool::free_list` (moving from hpp to cpp) introduced some friction. Please refrain from mixing mechanical and manual changes in the same commit; you can use a second commit in this PR for the manual tuning.
> 
> I see the same def is duplicated in two places:
> in `g1SegmentedArrayFreePool.hpp`:
> 
> typedef G1SegmentedArrayBuffer<mtGCCardSet> G1CardSetBuffer;
> typedef G1SegmentedArrayBufferList<mtGCCardSet> G1CardSetBufferList;
> 
> and `g1CardSetMemory.hpp`:
> 
> 
> typedef G1SegmentedArrayBuffer<mtGCCardSet> G1CardSetBuffer;
> 
> typedef G1SegmentedArrayBufferList<mtGCCardSet> G1CardSetBufferList;
> 
> 
> I believe such duplication is only transient -- later refactoring/renaming will fix this, so I am fine with the current PR.

@albertnetymk Yes, such changes are only transient, they will be reverted in next PR.

Thanks @tschatzl @albertnetymk for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6499


From mli at openjdk.java.net  Tue Nov 23 01:01:16 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 23 Nov 2021 01:01:16 GMT
Subject: Integrated: 8277542: G1: Move G1CardSetFreePool and related classes to
 separate files
In-Reply-To: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
References: <yz1gc8Ltc4yuFmaH7utqIr6Bz_xaDrPSB4hhT48JBrc=.b122f46f-3e53-4de9-92c9-b585b29ba6fe@github.com>
Message-ID: <B5DNTfNZ4CrluCJezJQr7o_vGvI_wi_jsbMDiMN0wMg=.a642627f-1608-4b06-bb71-c875fbfc2604@github.com>

On Mon, 22 Nov 2021 11:38:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out.

This pull request has now been integrated.

Changeset: bb11c55d
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb11c55dff86706a010c93ee2cc60c87bb2d53b6
Stats:     582 lines in 4 files changed: 326 ins; 256 del; 0 mod

8277542: G1: Move G1CardSetFreePool and related classes to separate files

Reviewed-by: ayang, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6499


From mli at openjdk.java.net  Tue Nov 23 06:32:13 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 23 Nov 2021 06:32:13 GMT
Subject: RFR: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes [v6]
In-Reply-To: <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
 <XwXcxhIn3FGryRzXGYtFlw6hafpyMWaOFLydM_pluY0=.f468d875-a1f5-4824-b9b2-6214efef153b@github.com>
Message-ID: <ku9FRPdM0hzrspOdFGtI3piFaEoq1-ox2ZRYcroUlek=.a3b5cc17-65ce-46f4-92e1-f2c14ba8f37c@github.com>

On Fri, 19 Nov 2021 04:49:59 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
>> 
>> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
>> 
>> I plan to do this in about 3 steps to smooth the review process:
>>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>>   2. refactor these classes to support freeing other freelist
>>   3. some necessary cleanup
>> 
>> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
>> Rename from G1CardSetXxx -> G1BufferListXxx.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge with master
>  - Rename card set to segmented array
>  - Rename from G1BufferListXxx to G1SegmentedArrayXxx
>  - Fix typo
>  - Merge branch 'master' into rename-move-G1CardSetFreePool-out
>  - Fix typos
>  - Fix gtest tests
>  - Fix missing in test
>  - Fix missing files
>  - move g1CardSetFreeMemoryTask.*
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2f0bde1a...7cfe01fb

I will close this pr, as #6514 is the newly created one which only "rename" (including Thomas's suggestion in this pr till now)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6289


From mli at openjdk.java.net  Tue Nov 23 06:32:13 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 23 Nov 2021 06:32:13 GMT
Subject: Withdrawn: 8276670: G1: Move and rename G1CardSetFreePool and related
 classes
In-Reply-To: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
References: <o04J9qpz14plhJUO3eRG8hlvLAETCX5dWJSS99DpzOA=.668638e6-0351-45d2-8371-3f8300224a42@github.com>
Message-ID: <KBrDo07rVp725hYhq0J7CNfoOIZ_q7FWnN-D_s0_nkM=.0afd52bc-9af9-4dd7-bfb7-ca21af28b45e@github.com>

On Mon, 8 Nov 2021 02:09:44 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.
> 
> After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.
> 
> I plan to do this in about 3 steps to smooth the review process:
>   1. move G1CardSetFreePool and related classes to new file, rename these classes
>   2. refactor these classes to support freeing other freelist
>   3. some necessary cleanup
> 
> This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
> Rename from G1CardSetXxx -> G1BufferListXxx.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6289


From mli at openjdk.java.net  Tue Nov 23 06:35:33 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 23 Nov 2021 06:35:33 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
Message-ID: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>

As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.

-------------

Commit messages:
 - Rename log messages
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6514/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6514&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276670
  Stats: 730 lines in 19 files changed: 332 ins; 316 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6514.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6514/head:pull/6514

PR: https://git.openjdk.java.net/jdk/pull/6514


From ayang at openjdk.java.net  Tue Nov 23 10:58:16 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 23 Nov 2021 10:58:16 GMT
Subject: RFR: 8277560: Remove WorkerDataArray::_is_serial [v2]
In-Reply-To: <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
References: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
 <maQH2HRgAU311avwt4NJeCQ1ZZxJZ-MM7SacS9buVgk=.97f1b266-b8a0-4db1-bc23-96be9b8c0d58@github.com>
Message-ID: <SGHX0TlPrtm6TCNnNaZHQsVcDdkXBVdUXx-I8J5DkDM=.a8f98d5a-1fbb-4273-b57a-c82854f7797d@github.com>

On Mon, 22 Nov 2021 15:07:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6502


From ayang at openjdk.java.net  Tue Nov 23 10:59:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 23 Nov 2021 10:59:14 GMT
Subject: RFR: 8277556: Call
 ReferenceProcessorPhaseTimes::set_processing_is_mt once
In-Reply-To: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
References: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
Message-ID: <aWMHgMzdY2F1Q706nWzJ52axFyGujMTYQs0w__s0mG0=.7a70fa26-c015-4631-b72f-75305b010893@github.com>

On Mon, 22 Nov 2021 13:44:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving the call site of `set_processing_is_mt`.
> 
> Test: hotspot_gc

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6500


From ayang at openjdk.java.net  Tue Nov 23 10:59:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 23 Nov 2021 10:59:14 GMT
Subject: Integrated: 8277556: Call
 ReferenceProcessorPhaseTimes::set_processing_is_mt once
In-Reply-To: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
References: <K4gh5oviHYzjaeWe0ewH6AgVUdx1MrvI2nM5jn93lK8=.e275c60d-e1d9-4500-b021-aaa762b65043@github.com>
Message-ID: <2n-JEdnVjbdnXL6nLAXj-nSmqvbfJrzLrhzuDTRXY1g=.63c3b0c6-bec9-41ce-9cd9-a6d76ee6fb20@github.com>

On Mon, 22 Nov 2021 13:44:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving the call site of `set_processing_is_mt`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 017df140
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/017df140ba65058270c5184db82162d42e42b908
Stats:     6 lines in 1 file changed: 2 ins; 4 del; 0 mod

8277556: Call ReferenceProcessorPhaseTimes::set_processing_is_mt once

Reviewed-by: sjohanss, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6500


From ayang at openjdk.java.net  Tue Nov 23 11:01:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 23 Nov 2021 11:01:14 GMT
Subject: Integrated: 8277560: Remove WorkerDataArray::_is_serial
In-Reply-To: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
References: <t_hQC3wBev9AY8whzD02waoKJBALpYlZznNuvcVPlO0=.19e77323-fcdd-402f-a8ed-0ffe764b304f@github.com>
Message-ID: <Q4Cn4Rk7nZvwSU5i1xclE08WqzQTkMKNa454YSQ6K4A=.0b230033-0e61-4287-b9bc-160b5bf9c9b8@github.com>

On Mon, 22 Nov 2021 13:53:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: 36b887a8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/36b887a885c76ddbbb1e21b32b8e7d9cc92f6ce2
Stats:     47 lines in 3 files changed: 5 ins; 27 del; 15 mod

8277560: Remove WorkerDataArray::_is_serial

Reviewed-by: sjohanss, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6502


From duke at openjdk.java.net  Tue Nov 23 12:36:13 2021
From: duke at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Nov 2021 12:36:13 GMT
Subject: Integrated: 8277413: Remove unused local variables in
 jdk.hotspot.agent
In-Reply-To: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
References: <4LVzvuGAayrX0k2csVEX-A_0jUCi1tY51N_fzY07Vus=.e60bc671-2609-496b-be31-9641dfc11e04@github.com>
Message-ID: <2dDByjhg7f6KvM1CE8VrnwZwfKAQc-gmgob8adjXqRw=.fd805610-4493-4840-99b4-1a6d9d5102ef@github.com>

On Wed, 10 Nov 2021 09:33:23 GMT, Andrey Turbanov <duke at openjdk.java.net> wrote:

> 8277413: Remove unused local variables in jdk.hotspot.agent

This pull request has now been integrated.

Changeset: 66eaf652
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66eaf6526126eb27c18acc64c2bb0791142815c9
Stats:     26 lines in 8 files changed: 0 ins; 14 del; 12 mod

8277413: Remove unused local variables in jdk.hotspot.agent

Reviewed-by: lmesnik, tschatzl, sspitsyn

-------------

PR: https://git.openjdk.java.net/jdk/pull/6329


From tschatzl at openjdk.java.net  Tue Nov 23 14:05:26 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 23 Nov 2021 14:05:26 GMT
Subject: RFR: 8277450: Record number of references into collection set during
 gc
Message-ID: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>

Hi all,

  could I have reviews for this change that adds logging for the number of heap roots found and pushed onto the task queues from the scanned cards? This can help with finding a good card size.

Thanks,
  Thomas

-------------

Commit messages:
 - Added "Found Roots" metric to Scan Heap Roots logging

Changes: https://git.openjdk.java.net/jdk/pull/6519/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6519&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277450
  Stats: 19 lines in 6 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6519.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6519/head:pull/6519

PR: https://git.openjdk.java.net/jdk/pull/6519


From stefank at openjdk.java.net  Wed Nov 24 08:28:14 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 24 Nov 2021 08:28:14 GMT
Subject: Integrated: 8277397: ZGC: Add JFR event for temporary latency
 measurements
In-Reply-To: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
Message-ID: <5iysj9BCFn72qN-D-QuMv9iuCvMHlqLLMXao4sd6Hvw=.e4339dbf-3660-4265-81a1-b0ae6772a029@github.com>

On Thu, 18 Nov 2021 13:09:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.

This pull request has now been integrated.

Changeset: 712b8756
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/712b8756828c88d4f71292d19fddb598d188c429
Stats:     43 lines in 6 files changed: 37 ins; 0 del; 6 mod

8277397: ZGC: Add JFR event for temporary latency measurements

Reviewed-by: eosterlund, jbachorik, pliden, mgronlun

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From stefank at openjdk.java.net  Wed Nov 24 08:30:10 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 24 Nov 2021 08:30:10 GMT
Subject: RFR: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug [v2]
In-Reply-To: <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
 <p9xDq_rg4Ih_Vm2-l_lpOIHlYEmYHkER23Ww1aEYmtA=.3f2c5080-5229-4cf0-b296-e25639fc0b75@github.com>
Message-ID: <eEehrHPbfNLwBuDiugWdTTLTl3vdy7zN1eS92gPHMMk=.51c44d44-a794-40f6-8c64-1c6087ac257d@github.com>

On Thu, 18 Nov 2021 15:18:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
>> 
>> Output with -Xlog:gc,gc+phases=debug
>> 
>> Before:
>> 
>> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
>> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
>> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
>> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
>> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
>> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
>> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
>> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
>> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
>> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
>> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
>> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
>> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
>> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
>> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
>> 
>> After:
>> 
>> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
>> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
>> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
>> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
>> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
>> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
>> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
>> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
>> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
>> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
>> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
>> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
>> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
>> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Per

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6457


From stefank at openjdk.java.net  Wed Nov 24 08:28:13 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 24 Nov 2021 08:28:13 GMT
Subject: RFR: 8277397: ZGC: Add JFR event for temporary latency
 measurements [v3]
In-Reply-To: <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
References: <yD1yxe9zzlk0043jw7jTG2MRkF4Umk8RIGl-eIOX6H0=.e6123f9e-8b75-47b7-b69a-f138d1b1d411@github.com>
 <CM2d4D_GAofyTECs5PFHh0y9t85T4SXWj5GKnezd4yk=.59344d52-5564-401b-8088-b5390901b06d@github.com>
Message-ID: <4RY4BtQy2QUlT4oPo661nFIpzGZk5cgEsPtHNHEIf-s=.631befb8-ddcd-4d84-81bb-107a2485fd01@github.com>

On Fri, 19 Nov 2021 08:49:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I often measure latencies and stalls using JFR events. I'd like to add an event that can be used for these ad-hoc measurements during development and debugging.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZThreadEvent to ZThreadDebug

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6454


From stefank at openjdk.java.net  Wed Nov 24 08:30:11 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 24 Nov 2021 08:30:11 GMT
Subject: Integrated: 8277399: ZGC: Move worker thread logging out of
 gc+phase=debug
In-Reply-To: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
References: <rtDw081jOh6ZHrRyHHVFTs5LMy5ubQdL0a_Bn7P_qSI=.aea74794-c418-4806-b56d-479c429e0eb3@github.com>
Message-ID: <vq694_bniUHqpEiA80tfPXzghSHCfGbd5iEOYgPwTJ0=.96d40448-0317-4f81-870b-d79e70cb1fa9@github.com>

On Thu, 18 Nov 2021 13:31:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> When extra ZGC phase logging is turned on with -Xlog:gc+phase=debug log sub-phases, but we also log what the individual threads are doing. The thread logging is often quite excessive, and not always wanted. I propose that we move it to its own tagset -Xlog:gc+phase+thread=debug.
> 
> Output with -Xlog:gc,gc+phases=debug
> 
> Before:
> 
> [0,625s][info ][gc,phases] GC(1) Pause Mark Start 0,006ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#5) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#2) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#4) 0,005ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#4) 0,002ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#7) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#3) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#0) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#1) 0,014ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#2) 0,004ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#1) 0,011ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots OopStorageSet (ZWorker#6) 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#7) 0,088ms
> [0,625s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#3) 0,120ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#0) 0,150ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots ClassLoaderDataGraph (ZWorker#5) 0,230ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Roots JavaThreads (ZWorker#4) 1,099ms
> [0,627s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,029ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,628s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,057ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,055ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#2) 0,016ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Flush (ZWorker#4) 0,014ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,019ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#4) 0,000ms
> [0,629s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#4) 2,414ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#6) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#6) 3,173ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#0) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#0) 3,178ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#3) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#3) 3,335ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#2) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#2) 3,390ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#1) 1,056ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#7) 1,054ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#7) 3,427ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#1) 3,420ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark Try Terminate (ZWorker#5) 1,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Mark (ZWorker#5) 3,442ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark 4,630ms
> [0,630s][info ][gc,phases] GC(1) Pause Mark End 0,047ms
> [0,630s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,630s][debug][gc,phases] GC(1) Concurrent References Process (ZDriver) 0,029ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#6) 0,055ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#4) 0,063ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#5) 0,058ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#3) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#0) 0,062ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#2) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#7) 0,061ms
> [0,630s][debug][gc,phases] GC(1) Concurrent Weak Roots OopStorageSet (ZWorker#1) 0,057ms
> [0,630s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,630s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Unlink (ZDriver) 0,413ms
> [0,631s][debug][gc,phases] GC(1) Concurrent Classes Purge (ZDriver) 0,024ms
> [0,631s][debug][gc,phases] GC(1) Concurrent References Enqueue (ZDriver) 0,000ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,625ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,633s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,594ms
> [0,633s][info ][gc,phases] GC(1) Pause Relocate Start 0,021ms
> [0,634s][info ][gc,phases] GC(1) Concurrent Relocate 1,308ms
> [0,634s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->16M(0%)
> 
> After:
> 
> [0,622s][info ][gc,phases] GC(1) Pause Mark Start 0,004ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark 3,555ms
> [0,625s][info ][gc,phases] GC(1) Pause Mark End 0,078ms
> [0,625s][info ][gc,phases] GC(1) Concurrent Mark Free 0,000ms
> [0,625s][debug][gc,phases] GC(1) Concurrent References Process 0,018ms
> [0,626s][debug][gc,phases] GC(1) ClassLoaderData 0,003ms
> [0,626s][debug][gc,phases] GC(1) Trigger cleanups 0,000ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Unlink 0,350ms
> [0,626s][debug][gc,phases] GC(1) Concurrent Classes Purge 0,019ms
> [0,626s][debug][gc,phases] GC(1) Concurrent References Enqueue 0,000ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Process Non-Strong References 0,495ms
> [0,626s][info ][gc,phases] GC(1) Concurrent Reset Relocation Set 0,001ms
> [0,629s][info ][gc,phases] GC(1) Concurrent Select Relocation Set 1,997ms
> [0,629s][info ][gc,phases] GC(1) Pause Relocate Start 0,029ms
> [0,631s][info ][gc,phases] GC(1) Concurrent Relocate 1,525ms
> [0,631s][info ][gc       ] GC(1) Garbage Collection (System.gc()) 16M(0%)->14M(0%)

This pull request has now been integrated.

Changeset: 6d734604
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6d734604a38447d81df36f4d4ca57ce71bd570af
Stats:     15 lines in 1 file changed: 11 ins; 0 del; 4 mod

8277399: ZGC: Move worker thread logging out of gc+phase=debug

Reviewed-by: eosterlund, pliden

-------------

PR: https://git.openjdk.java.net/jdk/pull/6457


From tschatzl at openjdk.java.net  Wed Nov 24 13:33:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 24 Nov 2021 13:33:04 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
In-Reply-To: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
Message-ID: <PZYKZIBq-9oxnZkoQuN9mid5ywrbOf_GO_lDGqprKF8=.89a02a7d-b8ce-47e6-b0ce-dd49234a8b73@github.com>

On Tue, 23 Nov 2021 06:26:19 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.

Lgtm. Thanks for fixing some pre-existing include-orderings...

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6514


From ayang at openjdk.java.net  Wed Nov 24 15:19:08 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 24 Nov 2021 15:19:08 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
In-Reply-To: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
Message-ID: <Af8HoaHUb7v0NP4H0Mc7d6SgBhnSIaJDzm0XBQgOvGo=.7ecd1611-7fdd-4c33-ae9e-4d9c21a49bab@github.com>

On Tue, 23 Nov 2021 06:26:19 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.

Some minor comments/suggestions.

src/hotspot/share/gc/g1/g1CardSetMemory.cpp line 208:

> 206:   for (uint i = 0; i < num_mem_object_types(); i++) {
> 207:     result._num_mem_sizes[i] += _allocators[i].mem_size();
> 208:     result._num_segments[i] += _allocators[i].num_buffers();

I see a few other places where `buffer` is *not* renamed to `segment`. Having a dedicated PR for `buffer` -> `segment` renaming can increase the cohesion of each PR, IMO.

src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 147:

> 145: public:
> 146:   G1CardSetMemoryManager(G1CardSetConfiguration* config,
> 147:                          G1SegmentedArrayFreePool<mtGCCardSet>* free_list_pool);

Instead of using `G1SegmentedArrayFreePool<mtGCCardSet>` explicitly, I think the current name, `G1CardSetFreePool`, is more meaningful in this context (user site).

Therefore, I wonder if it's possible to place `using G1CardSetFreePool = G1SegmentedArrayFreePool<mtGCCardSet>` somewhere and keep using the current name.

src/hotspot/share/gc/g1/g1SegmentedArrayFreeMemoryTask.hpp line 86:

> 84: 
> 85: public:
> 86:   explicit G1SegmentedArrayFreeMemoryTask(const char* name);

Looking at the call-site and implementation of `execute()` method, I am not sure this class is generic enough to be called `G1SegmentedArrayFreeMemoryTask`. (Maybe this class will be used for sth other than Card Set in the near future?)

src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.hpp line 39:

> 37: 
> 38:   size_t _num_mem_sizes[G1CardSetConfiguration::num_mem_object_types()];
> 39:   size_t _num_segments[G1CardSetConfiguration::num_mem_object_types()];

It's a bit odd to have `G1CardSetXXX` embedded inside this class. Can be fixed in a followup PR.

src/hotspot/share/gc/g1/g1SegmentedArrayFreePool.hpp line 62:

> 60: class G1SegmentedArrayFreePool {
> 61:   // The global free pool.
> 62:   static G1SegmentedArrayFreePool<flag> _freelist_pool;

I think one can drop `<flag>` here and in other similar places

-------------

PR: https://git.openjdk.java.net/jdk/pull/6514


From iwalulya at openjdk.java.net  Wed Nov 24 15:59:35 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 24 Nov 2021 15:59:35 GMT
Subject: RFR: 8277786: G1: Rename log2_card_region_per_heap_region used in
 G1CardSet
Message-ID: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>

Hi all,

Please review this small change to  rename log2_card_region_per_heap_region to log2_card_regions_per_heap_region in order to improve readability.

//

-------------

Commit messages:
 - initial

Changes: https://git.openjdk.java.net/jdk/pull/6539/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6539&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277786
  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6539.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6539/head:pull/6539

PR: https://git.openjdk.java.net/jdk/pull/6539


From ayang at openjdk.java.net  Wed Nov 24 16:20:18 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 24 Nov 2021 16:20:18 GMT
Subject: RFR: 8277786: G1: Rename log2_card_region_per_heap_region used in
 G1CardSet
In-Reply-To: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
References: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
Message-ID: <iXfGq0KBDWyvi8F3S3qEy5kvTkv-dsCf9iCk_zoUA4w=.1451734e-96f5-4a9a-b133-430b273215d1@github.com>

On Wed, 24 Nov 2021 15:50:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small change to  rename log2_card_region_per_heap_region to log2_card_regions_per_heap_region in order to improve readability.
> 
> //

Marked as reviewed by ayang (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6539


From tschatzl at openjdk.java.net  Wed Nov 24 17:28:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 24 Nov 2021 17:28:04 GMT
Subject: RFR: 8277786: G1: Rename log2_card_region_per_heap_region used in
 G1CardSet
In-Reply-To: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
References: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
Message-ID: <mTmOpZwRrqrTMsAINsKkcTTAAP_17T71KCXeszrmhQ4=.efced8ed-b7af-41a7-828d-e903fcd48420@github.com>

On Wed, 24 Nov 2021 15:50:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small change to  rename log2_card_region_per_heap_region to log2_card_regions_per_heap_region in order to improve readability.
> 
> //

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6539


From kbarrett at openjdk.java.net  Wed Nov 24 23:00:21 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 24 Nov 2021 23:00:21 GMT
Subject: RFR: 8277807: Increase default initial concurrent refinement threshold
Message-ID: <QRADGyYH849nRuOyjCnj47SW3k5Z0HdyNAnyfiIAGio=.179d7023-1e88-425b-b88d-212ba7fb1e4d@github.com>

Please review this change to the default initial concurrent refinement
threshold.  The new value takes into account options that should provide a
starting point that is closer to the long-term range.

Testing:
mach5 tier1
manually verified logged initial value matched expectations.

-------------

Commit messages:
 - increase default initial green zone value

Changes: https://git.openjdk.java.net/jdk/pull/6549/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6549&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277807
  Stats: 13 lines in 1 file changed: 8 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6549/head:pull/6549

PR: https://git.openjdk.java.net/jdk/pull/6549


From mli at openjdk.java.net  Thu Nov 25 01:00:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 25 Nov 2021 01:00:08 GMT
Subject: RFR: 8277786: G1: Rename log2_card_region_per_heap_region used in
 G1CardSet
In-Reply-To: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
References: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
Message-ID: <PuTpe1KYEitXHUwssyE36xPvYKykheSU87DrLEUWANk=.56d1ead2-ee6c-4c7d-b978-7811a31f1c94@github.com>

On Wed, 24 Nov 2021 15:50:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small change to  rename log2_card_region_per_heap_region to log2_card_regions_per_heap_region in order to improve readability.
> 
> //

Marked as reviewed by mli (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6539


From kbarrett at openjdk.java.net  Thu Nov 25 03:02:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 25 Nov 2021 03:02:07 GMT
Subject: RFR: 8277450: Record number of references into collection set
 during gc
In-Reply-To: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
References: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
Message-ID: <0wOwK8eM_PvBVB98R6fQ75eUBGUkoAMPdfvQAf0Vo_E=.515833fc-1aea-4c31-a81e-5b6c2a96678f@github.com>

On Tue, 23 Nov 2021 13:55:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   could I have reviews for this change that adds logging for the number of heap roots found and pushed onto the task queues from the scanned cards? This can help with finding a good card size.
> 
> Thanks,
>   Thomas

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6519


From mli at openjdk.java.net  Thu Nov 25 04:02:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 25 Nov 2021 04:02:08 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
In-Reply-To: <Af8HoaHUb7v0NP4H0Mc7d6SgBhnSIaJDzm0XBQgOvGo=.7ecd1611-7fdd-4c33-ae9e-4d9c21a49bab@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
 <Af8HoaHUb7v0NP4H0Mc7d6SgBhnSIaJDzm0XBQgOvGo=.7ecd1611-7fdd-4c33-ae9e-4d9c21a49bab@github.com>
Message-ID: <JI3qEop-ckOq8rxIxRLFJEer5UqqonCYT0hnxZa56Ds=.4060515f-1bc1-496b-9895-df0e25050ba3@github.com>

On Wed, 24 Nov 2021 13:59:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.
>
> src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 147:
> 
>> 145: public:
>> 146:   G1CardSetMemoryManager(G1CardSetConfiguration* config,
>> 147:                          G1SegmentedArrayFreePool<mtGCCardSet>* free_list_pool);
> 
> Instead of using `G1SegmentedArrayFreePool<mtGCCardSet>` explicitly, I think the current name, `G1CardSetFreePool`, is more meaningful in this context (user site).
> 
> Therefore, I wonder if it's possible to place `using G1CardSetFreePool = G1SegmentedArrayFreePool<mtGCCardSet>` somewhere and keep using the current name.

good idea!

> src/hotspot/share/gc/g1/g1SegmentedArrayFreeMemoryTask.hpp line 86:
> 
>> 84: 
>> 85: public:
>> 86:   explicit G1SegmentedArrayFreeMemoryTask(const char* name);
> 
> Looking at the call-site and implementation of `execute()` method, I am not sure this class is generic enough to be called `G1SegmentedArrayFreeMemoryTask`. (Maybe this class will be used for sth other than Card Set in the near future?)

Yes, it will be used by some other places, e.g. evecuation failure processing. This class and related others will be refactored further to be more generic after the move and rename.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6514


From mli at openjdk.java.net  Thu Nov 25 04:12:46 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 25 Nov 2021 04:12:46 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
 [v2]
In-Reply-To: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
Message-ID: <pOtz8wvwoxYjOb92mwfCU3E_w68Sy90P7p28En3kP0Q=.d0f1a683-b270-4db0-bde4-5dbeb437bd88@github.com>

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Albert review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6514/files
  - new: https://git.openjdk.java.net/jdk/pull/6514/files/d2cd5c5d..3de196a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6514&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6514&range=00-01

  Stats: 12 lines in 7 files changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6514.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6514/head:pull/6514

PR: https://git.openjdk.java.net/jdk/pull/6514


From kbarrett at openjdk.java.net  Thu Nov 25 04:32:17 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 25 Nov 2021 04:32:17 GMT
Subject: RFR: 8277814: ConcurrentRefineThread should report rate when
 deactivating
Message-ID: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>

Please review this change to the logging by concurrent refinement threads.
This change adds the cards processed per ms to the deactivation log message.

Testing:
mach5 tier1
locally ran a test with gc+refine=debug logging enabled and verified the
expected change to the deactivation log message.

-------------

Commit messages:
 - log refinement rate

Changes: https://git.openjdk.java.net/jdk/pull/6550/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6550&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277814
  Stats: 17 lines in 3 files changed: 10 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6550.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6550/head:pull/6550

PR: https://git.openjdk.java.net/jdk/pull/6550


From kbarrett at openjdk.java.net  Thu Nov 25 04:32:32 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 25 Nov 2021 04:32:32 GMT
Subject: RFR: 8277807: Increase default initial concurrent refinement
 threshold [v2]
In-Reply-To: <QRADGyYH849nRuOyjCnj47SW3k5Z0HdyNAnyfiIAGio=.179d7023-1e88-425b-b88d-212ba7fb1e4d@github.com>
References: <QRADGyYH849nRuOyjCnj47SW3k5Z0HdyNAnyfiIAGio=.179d7023-1e88-425b-b88d-212ba7fb1e4d@github.com>
Message-ID: <8DQHFkgfflb6n1kHxNRuKnjdjtk2ATkeCqCnWfZszLw=.27404d20-5ee0-486f-9a31-899b466e74e4@github.com>

> Please review this change to the default initial concurrent refinement
> threshold.  The new value takes into account options that should provide a
> starting point that is closer to the long-term range.
> 
> Testing:
> mach5 tier1
> manually verified logged initial value matched expectations.

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  update copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6549/files
  - new: https://git.openjdk.java.net/jdk/pull/6549/files/b0025145..0adb6a5a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6549&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6549&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6549.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6549/head:pull/6549

PR: https://git.openjdk.java.net/jdk/pull/6549


From kbarrett at openjdk.java.net  Thu Nov 25 06:02:18 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 25 Nov 2021 06:02:18 GMT
Subject: RFR: 8151594: Move concurrent refinement thread activation logging out
 of GC pause
Message-ID: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>

Please review this move of the thread activation logging by concurrent
refinment threads to be within the suspendible thread set context, rather
than before it.  This prevents the logging for the thread activation
sometimes being intermixed with GC pause-time logging.

Testing:
mach5 tier1

-------------

Commit messages:
 - move thread active logging inside sts

Changes: https://git.openjdk.java.net/jdk/pull/6551/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6551&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8151594
  Stats: 9 lines in 1 file changed: 4 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6551.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6551/head:pull/6551

PR: https://git.openjdk.java.net/jdk/pull/6551


From ayang at openjdk.java.net  Thu Nov 25 09:38:20 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 25 Nov 2021 09:38:20 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor
Message-ID: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>

Simple change removing effectively dead code, and some general cleanup.

Test: hotspot_gc

-------------

Commit messages:
 - rp-time-tracker

Changes: https://git.openjdk.java.net/jdk/pull/6555/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6555&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277824
  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6555/head:pull/6555

PR: https://git.openjdk.java.net/jdk/pull/6555


From ayang at openjdk.java.net  Thu Nov 25 10:06:16 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 25 Nov 2021 10:06:16 GMT
Subject: RFR: 8277825: Remove unused
 ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms
Message-ID: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>

Simple change of removing effectively dead code.

Test: build

-------------

Commit messages:
 - remove_unused

Changes: https://git.openjdk.java.net/jdk/pull/6557/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6557&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277825
  Stats: 17 lines in 2 files changed: 0 ins; 17 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6557.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6557/head:pull/6557

PR: https://git.openjdk.java.net/jdk/pull/6557


From tschatzl at openjdk.java.net  Thu Nov 25 10:44:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 25 Nov 2021 10:44:02 GMT
Subject: RFR: 8277825: Remove unused
 ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms
In-Reply-To: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>
References: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>
Message-ID: <EaoHrXsF1vGoRDGIhOWWhuTgxNJdUE1xsoyAUVPWlzM=.003952d4-376a-4573-b1ca-ea368c97bc74@github.com>

On Thu, 25 Nov 2021 09:57:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: build

Lgtm and trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6557


From tschatzl at openjdk.java.net  Thu Nov 25 10:44:01 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 25 Nov 2021 10:44:01 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor
In-Reply-To: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
Message-ID: <rp07z9HTtAQtltZN2_zGiKOsHKTrzPECfekPhDQXFeI=.29488c55-e94b-4a94-8e6f-1d00d5ab17e1@github.com>

On Thu, 25 Nov 2021 09:29:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change removing effectively dead code, and some general cleanup.
> 
> Test: hotspot_gc

Lgtm and trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6555


From duke at openjdk.java.net  Thu Nov 25 10:50:10 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 25 Nov 2021 10:50:10 GMT
Subject: Withdrawn: 8273392: Improve usability of stack-less exceptions due to
 -XX:+OmitStackTraceInFastThrow
In-Reply-To: <sAGoUJfd3NgyqGm3uhT3sqmkPLWZyyuUTfs2QkXECok=.0cacde1b-47af-4256-960f-779a4329f790@github.com>
References: <sAGoUJfd3NgyqGm3uhT3sqmkPLWZyyuUTfs2QkXECok=.0cacde1b-47af-4256-960f-779a4329f790@github.com>
Message-ID: <SY1z7vKeInk-nkXNw0l-NJETydLC1_dokwLl29Mu8CI=.cc74efc4-7e3e-470d-95ba-941760d00d49@github.com>

On Tue, 7 Sep 2021 15:25:46 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-XX:+OmitStackTraceInFastThrow` (which is the default) C2 will optimize certain "hot" implicit exceptions (i.e. AIOOBE, NullPointerExceptions,..) and replace them by a static, pre-allocated exception without any stacktrace.
> 
> However, we can actually do better. Instead of using a single, pre-allocated exception object for all methods we can let the compiler allocate specific exceptions for each compilation unit (i.e. nmethod) and fill them with at least one stack frame with the method /line-number information of the currently compiled method. If the method in question is being inlined (which often happens), we can add stackframes for all callers up to the inlining depth of the method in question.
> 
> For the attached JTreg test, we get the following exception in interpreter mode:
> 
> java.lang.NullPointerException: Cannot read the array length because "<parameter2>" is null
>         at compiler.exceptions.StackFrameInFastThrow.throwImplicitException(StackFrameInFastThrow.java:76)
>         at compiler.exceptions.StackFrameInFastThrow.level2(StackFrameInFastThrow.java:95)
>         at compiler.exceptions.StackFrameInFastThrow.level1(StackFrameInFastThrow.java:99)
>         at compiler.exceptions.StackFrameInFastThrow.main(StackFrameInFastThrow.java:233)
> 
> Once the method gets compiled with `-XX:+OmitStackTraceInFastThrow` the same exception will look as follows:
> 
> java.lang.NullPointerException
> 
> After this change, if `StackFrameInFastThrow.throwImplicitException()` will be compiled stand alone, we will get:
> 
> java.lang.NullPointerException
>         at compiler.exceptions.StackFrameInFastThrow.throwImplicitException(StackFrameInFastThrow.java:76)
> 
> and if `StackFrameInFastThrow.throwImplicitException()` will be inlined into `level2()` and `level2()` into `level1()` we will get the following exception (altough we're still running with `-XX:+OmitStackTraceInFastThrow`):
> 
> java.lang.NullPointerException
>         at compiler.exceptions.StackFrameInFastThrow.throwImplicitException(StackFrameInFastThrow.java:76)
>         at compiler.exceptions.StackFrameInFastThrow.level2(StackFrameInFastThrow.java:95)
>         at compiler.exceptions.StackFrameInFastThrow.level1(StackFrameInFastThrow.java:99)
> 
> The new functionality is guarded by `-XX:+/-StackFrameInFastThrow`, but switched on by default (I'll create a CSR for the new option once reviewers are comfortable with the change). Notice that the optimization comes at no run-time costs because all the extra work will be done at compile time.
> 
> ## Implementation details
> 
> - Already the current implementation of `-XX:+OmitStackTraceInFastThrow` potentially lazy-allocates the empty singleton exceptions like AIOOBE in `ciEnv::ArrayStoreException_instance()`. With this change, if running with `-XX:+StackFrameInFastThrow` we will always allocate new exception objects and populate them with the stack frames which are statically available at compile time (see `java_lang_Throwable::fill_in_stack_trace_of_implicit_exception()`).
> - Because nmethods don't act as strong GC roots, we have to create a global JNI handle for every newly generated exception to prevent GC from collecting them.
> - In order to avoid a memory leak we have to release these global JNI handles once a nmethod gets unloaded. In order to achieve this, I've added a new section "implicit exceptions" to the nmethod which holds these JNI handles.
> - While adding the new  "implicit exceptions" section to the corresponding stats (`print_nmethod_stats()` and printing routines (`nmethod::print()`) I realized that a previous change ([JDK-8254231: Implementation of Foreign Linker API (Incubator)](https://bugs.openjdk.java.net/browse/JDK-8254231)) had already introduced a new nmethod section ("native invokers") but missed to add it to the corresponding stats and printing routines so I've added that section as well.
> - The `#ifdef COMPILER2` guards are only required to not break the `zero`/`minimal` builds.
> - The JTreg test is using `-XX:PerMethodTrapLimit=0` to handle all implicit exceptions as "hot". This makes the test simpler and at the same time provokes the allocation of more implicit exceptions.
> - Manually verified that the created Exception objects are freed by GC once the corresponding nmethods have been flushed.
> - Manual "stress" test with a very small heap and continuous recompilation of methods with explicit exceptions to provoke GCs during compilation didn't reveal any issues.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5392


From mli at openjdk.java.net  Thu Nov 25 13:00:30 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 25 Nov 2021 13:00:30 GMT
Subject: RFR: 8277736: G1: Configure the distribution of objects failing
 evacuation among regions
Message-ID: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>

Currently, debug options of evacuation failure, like G1EvacuationFailureALotInterval and G1EvacuationFailureALotCount only config the ratio of objects failing evacuation, basically the distribution of objects failing evacuation is even among regions.

JDK-8256265 is trying to improve parallelism in regions that failed evacuation, it'll be helpful if there is option to config the distribution of objects failing evacuation among regions, so implementation of JDK-8256265 could be profiled more precisely.

This is to add the support and necessary vm options.

-------------

Commit messages:
 - Fix compilation error; refine code
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277736
  Stats: 51 lines in 6 files changed: 44 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6561/head:pull/6561

PR: https://git.openjdk.java.net/jdk/pull/6561


From iwalulya at openjdk.java.net  Thu Nov 25 14:14:12 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 25 Nov 2021 14:14:12 GMT
Subject: RFR: 8277786: G1: Rename log2_card_region_per_heap_region used in
 G1CardSet
In-Reply-To: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
References: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
Message-ID: <ijMDJ5lj1tLwQRU36RBwVh6GZAbk7ye5OEkaCvlYJuI=.9a2f9e86-b65b-43eb-9d8d-4a5e80a2afc4@github.com>

On Wed, 24 Nov 2021 15:50:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small change to  rename log2_card_region_per_heap_region to log2_card_regions_per_heap_region in order to improve readability.
> 
> //

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6539


From iwalulya at openjdk.java.net  Thu Nov 25 14:14:12 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 25 Nov 2021 14:14:12 GMT
Subject: Integrated: 8277786: G1: Rename log2_card_region_per_heap_region used
 in G1CardSet
In-Reply-To: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
References: <mgKA_KJcU1CF6r95xoc86G9w-Fn_8-6xst2IoofBOCk=.cbaae388-79d4-4723-9eb8-7996026b2374@github.com>
Message-ID: <5Kf26zTbCy1qWd24INdqi7kOgMurxf2XDzApGPpRt28=.102f4001-49f7-44c1-a3a1-874c78787142@github.com>

On Wed, 24 Nov 2021 15:50:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small change to  rename log2_card_region_per_heap_region to log2_card_regions_per_heap_region in order to improve readability.
> 
> //

This pull request has now been integrated.

Changeset: f7888349
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f788834998eeb9083e971857446321ed173aa916
Stats:     13 lines in 3 files changed: 0 ins; 0 del; 13 mod

8277786: G1: Rename log2_card_region_per_heap_region used in G1CardSet

Reviewed-by: ayang, tschatzl, mli

-------------

PR: https://git.openjdk.java.net/jdk/pull/6539


From ayang at openjdk.java.net  Thu Nov 25 14:58:09 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 25 Nov 2021 14:58:09 GMT
Subject: RFR: 8277825: Remove unused
 ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms
In-Reply-To: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>
References: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>
Message-ID: <7EZ_FW7JaTLCgTOuJvccfqgdOqD9QBsG5pbwOqjUhec=.032baae1-bd0c-422c-8161-32904e24fb63@github.com>

On Thu, 25 Nov 2021 09:57:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: build

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6557


From ayang at openjdk.java.net  Thu Nov 25 14:58:10 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 25 Nov 2021 14:58:10 GMT
Subject: Integrated: 8277825: Remove unused
 ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms
In-Reply-To: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>
References: <JbsQHlYqcmHbI9O85ERGzOLMuie5o6PMFTRsZ2OVbic=.4317040d-e2dc-4ed6-8524-821e41828327@github.com>
Message-ID: <DU1CT8dv9cM3PgKj9LjTnqahCR6u_O6wM3Zdq5Gfn7M=.f8caa655-614a-4e01-aaae-7c97ab5968a3@github.com>

On Thu, 25 Nov 2021 09:57:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: 98799204
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/987992042454f92936d3efbd01e7beb921e3b70e
Stats:     17 lines in 2 files changed: 0 ins; 17 del; 0 mod

8277825: Remove unused ReferenceProcessorPhaseTimes::_sub_phases_total_time_ms

Reviewed-by: tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6557


From tschatzl at openjdk.java.net  Thu Nov 25 19:27:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 25 Nov 2021 19:27:07 GMT
Subject: RFR: 8277736: G1: Configure the distribution of objects failing
 evacuation among regions
In-Reply-To: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
References: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
Message-ID: <i7eqM81MoHcyCbFM4rTnRC9GOEzEexzlzTqJc5b_ahs=.2d2d6086-e963-4dbe-a226-1225c40262df@github.com>

On Thu, 25 Nov 2021 12:54:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, debug options of evacuation failure, like G1EvacuationFailureALotInterval and G1EvacuationFailureALotCount only config the ratio of objects failing evacuation, basically the distribution of objects failing evacuation is even among regions.
> 
> JDK-8256265 is trying to improve parallelism in regions that failed evacuation, it'll be helpful if there is option to config the distribution of objects failing evacuation among regions, so implementation of JDK-8256265 could be profiled more precisely.
> 
> This is to add the support and necessary vm options.

src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.cpp line 47:

> 45:       _regions.set_bit(r->hrm_index());
> 46:       --_evac_failure_regions_num;
> 47:       return false;

Just an initial comment to think about and discuss: This would most likely always ever select the same regions (probably eden) that are first in the collection set.
I think selecting by probability (with G1EvacuationFailureALotCSetPercent uniform probability) would be more interesting even if it makes the selection more random.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6561


From tschatzl at openjdk.java.net  Thu Nov 25 19:28:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 25 Nov 2021 19:28:06 GMT
Subject: RFR: 8151594: Move concurrent refinement thread activation logging
 out of GC pause
In-Reply-To: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
References: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
Message-ID: <ctRmmmgRdkDugnLUYf18XaQ9ttsf4s25eNnZ4Kb7TYo=.744ca794-40b8-4dde-a5dc-e1ee38d44696@github.com>

On Thu, 25 Nov 2021 05:56:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this move of the thread activation logging by concurrent
> refinment threads to be within the suspendible thread set context, rather
> than before it.  This prevents the logging for the thread activation
> sometimes being intermixed with GC pause-time logging.
> 
> Testing:
> mach5 tier1

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6551


From iwalulya at openjdk.java.net  Thu Nov 25 20:38:16 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 25 Nov 2021 20:38:16 GMT
Subject: RFR: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used
 interchangeably
Message-ID: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>

Hi all,

Please review this small refactoring to consistently use prefix `max_` for variable names where the variable represents a limit in G1CardSetConfiguration.

Thanks

-------------

Commit messages:
 - 8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used interchangeably

Changes: https://git.openjdk.java.net/jdk/pull/6567/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6567&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277789
  Stats: 52 lines in 5 files changed: 0 ins; 2 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6567/head:pull/6567

PR: https://git.openjdk.java.net/jdk/pull/6567


From mli at openjdk.java.net  Fri Nov 26 01:11:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 26 Nov 2021 01:11:08 GMT
Subject: RFR: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_
 used interchangeably
In-Reply-To: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
References: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
Message-ID: <0Sf5ZgTuygdT8LTv1Lah-yZPJXKJsM4VlFiW9b94sjw=.30dd6923-f0c8-4a79-8221-24bc0174d59a@github.com>

On Thu, 25 Nov 2021 20:30:51 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small refactoring to consistently use prefix `max_` for variable names where the variable represents a limit in G1CardSetConfiguration.
> 
> Thanks

Marked as reviewed by mli (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6567


From mli at openjdk.java.net  Fri Nov 26 02:38:07 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 26 Nov 2021 02:38:07 GMT
Subject: RFR: 8277736: G1: Configure the distribution of objects failing
 evacuation among regions
In-Reply-To: <i7eqM81MoHcyCbFM4rTnRC9GOEzEexzlzTqJc5b_ahs=.2d2d6086-e963-4dbe-a226-1225c40262df@github.com>
References: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
 <i7eqM81MoHcyCbFM4rTnRC9GOEzEexzlzTqJc5b_ahs=.2d2d6086-e963-4dbe-a226-1225c40262df@github.com>
Message-ID: <rjQSZ2zn8E5MOqiVKdZa419tb7q2mPeeznCrn4NtYR0=.27100d70-a232-483e-9e42-c1adc83e01ab@github.com>

On Thu, 25 Nov 2021 19:24:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Currently, debug options of evacuation failure, like G1EvacuationFailureALotInterval and G1EvacuationFailureALotCount only config the ratio of objects failing evacuation, basically the distribution of objects failing evacuation is even among regions.
>> 
>> JDK-8256265 is trying to improve parallelism in regions that failed evacuation, it'll be helpful if there is option to config the distribution of objects failing evacuation among regions, so implementation of JDK-8256265 could be profiled more precisely.
>> 
>> This is to add the support and necessary vm options, and the implementation will be to select regions from start, i.e. not randomly, the motivation is to configure a more stable selection of evacuation failure regions, which will help verify the effect of JDK-8256265 implementation.
>
> src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.cpp line 47:
> 
>> 45:       _regions.set_bit(r->hrm_index());
>> 46:       --_evac_failure_regions_num;
>> 47:       return false;
> 
> Just an initial comment to think about and discuss: This would most likely always ever select the same regions (probably eden) that are first in the collection set.
> I think selecting by probability (with G1EvacuationFailureALotCSetPercent uniform probability) would be more interesting even if it makes the selection more random.

Yes, currently I only make it select regions starting from first.
The reason I don't add random selection is that, currently we need this functionality to verify the functionality and perf improvement of JDK-8256265 implementation, so a more stable selection of evacuation failure regions will help to verify the effect of JDK-8256265.

I agree that random selection is an interesting option to supply too, I just file https://bugs.openjdk.java.net/browse/JDK-8277851 to track the issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6561


From jiefu at openjdk.java.net  Fri Nov 26 06:37:19 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Nov 2021 06:37:19 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be limited
 to 512 for 32-bit platforms
Message-ID: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>

Hi all,

runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.

This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.

So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
[2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

-------------

Commit messages:
 - 8277854: The upper bound of GCCardSizeInBytes should be limited to 512 for 32-bit platforms

Changes: https://git.openjdk.java.net/jdk/pull/6569/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6569&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277854
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6569.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6569/head:pull/6569

PR: https://git.openjdk.java.net/jdk/pull/6569


From mli at openjdk.java.net  Fri Nov 26 07:51:06 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 26 Nov 2021 07:51:06 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
Message-ID: <jDkhkGuO2S1sgtXxr1acl8dNnkVP4AC6bAXb74WlSRk=.3b83740a-0cc0-4de7-976c-1bfc1cb21290@github.com>

On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
> 
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
> 
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

Several initial comments:
 - Not sure if the lower bound should also be distinguished between 32 and 64. It's not because of crash, but as you're touching it, should we consider this?
 - Does a CSR needed?
 - A regression test would be helpful.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From jiefu at openjdk.java.net  Fri Nov 26 08:36:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Nov 2021 08:36:04 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
Message-ID: <eSLPP_tdmNkZjTRjf-pa_zyAVW19VPOd3yTIc9w44Tg=.d5bd3617-23ad-4983-bcb6-c0bbfcb4cd6d@github.com>

On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
> 
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
> 
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

Good questions!
Thanks @Hamlin-Li for your review.


> Several initial comments:
> 
> * Not sure if the lower bound should also be distinguished between 32 and 64. It's not because of crash, but as you're touching it, should we consider this?

Not sure if there is any benefit to distinguish the lower bounds between 32-bit and 64-bit platforms.
But this pr aims at fixing the crash caused by the incorrect upper bound on 32-bit platforms.
So a separate pr seems better if the lower bound needs to be re-considered.

> * Does a CSR needed?

Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet.
But I'm not sure.

> * A regression test would be helpful.

There is already a jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java for this regression.

Thanks.
Best regards,
Jie

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From tschatzl at openjdk.java.net  Fri Nov 26 09:21:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 26 Nov 2021 09:21:08 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
Message-ID: <8unjBMzRPNdBaKNyxlsxGg0iywu3w3ITXApatJlmIR4=.dc246ad2-17c8-4847-89bc-a3428d1a61e8@github.com>

On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
> 
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
> 
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

Thanks for spotting this - that slipped past our testing (we do not do much 32 bit testing).

>>  Does a CSR needed?
>
> Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet.
> But I'm not sure.

I will talk to the CSR team whether there needs to be an amendment to the CSR for 32 bit platforms. please do not integrate before this has been handled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From rkennke at openjdk.java.net  Fri Nov 26 09:38:19 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 26 Nov 2021 09:38:19 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call
Message-ID: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>

The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)

Testing:
 - [x] hotspot_gc_shenandoah
 - [x] specjvm -XX:+UseShenandoahGC
 - [x] tier1
 - [x] tier2
 - [x] tier3

-------------

Commit messages:
 - 8277654: Shenandoah: Don't produce new memory state in C2 LRB runtime call

Changes: https://git.openjdk.java.net/jdk/pull/6526/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6526&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277654
  Stats: 32 lines in 2 files changed: 0 ins; 26 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6526/head:pull/6526

PR: https://git.openjdk.java.net/jdk/pull/6526


From rkennke at openjdk.java.net  Fri Nov 26 09:42:34 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 26 Nov 2021 09:42:34 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
Message-ID: <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>

> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] specjvm -XX:+UseShenandoahGC
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove verify_raw_mem()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6526/files
  - new: https://git.openjdk.java.net/jdk/pull/6526/files/294389df..06c2b9eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6526&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6526&range=00-01

  Stats: 101 lines in 2 files changed: 0 ins; 101 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6526.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6526/head:pull/6526

PR: https://git.openjdk.java.net/jdk/pull/6526


From tschatzl at openjdk.java.net  Fri Nov 26 11:31:00 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 26 Nov 2021 11:31:00 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
Message-ID: <WGK9UJwD18DgDI-PzJWipPEZUaMZcpn0GOJQ3Dy6pcA=.336f9856-d629-4a0d-811d-9a3db7fd2e9d@github.com>

On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
> 
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
> 
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

I think this is good, but I had to amend the CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) for it for this case. As soon as it has been approved again sometime next week, this change can be integrated.
Also fixed the release note.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6569


From tschatzl at openjdk.java.net  Fri Nov 26 11:34:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 26 Nov 2021 11:34:05 GMT
Subject: RFR: 8277814: ConcurrentRefineThread should report rate when
 deactivating
In-Reply-To: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
References: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
Message-ID: <YagyR-aN6MIk2UCeWDN0hSDDiknLnoRmHN4OA9rQKRA=.aa32f746-c7b9-4f7d-a4ca-184e58b76955@github.com>

On Thu, 25 Nov 2021 04:24:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the logging by concurrent refinement threads.
> This change adds the cards processed per ms to the deactivation log message.
> 
> Testing:
> mach5 tier1
> locally ran a test with gc+refine=debug logging enabled and verified the
> expected change to the deactivation log message.

src/hotspot/share/gc/g1/g1ConcurrentRefineStats.cpp line 38:

> 36:   // Report 0 when no time recorded because no refinement performed.
> 37:   double secs = refinement_time().seconds();
> 38:   return (secs > 0) ? (refined_cards() / (secs * MILLIUNITS)) : 0.0;

Not sure how this is used, but in similar calculations we only use and return a value if the elapsed time is large enough (something like a microsecond or so) to remove extreme outliers. Not sure if that is needed here too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6550


From duke at openjdk.java.net  Fri Nov 26 11:54:25 2021
From: duke at openjdk.java.net (Takuya Kiriyama)
Date: Fri, 26 Nov 2021 11:54:25 GMT
Subject: RFR: 8277866: gc/epsilon/TestMemoryMXBeans.java failed with wrong
 initial heap size
Message-ID: <PIWg71Tn_415RtJdk1EdjN-ygQ8cDZYFHsZ_fh1SHwU=.90412842-c964-41aa-86aa-2be55dd4db50@github.com>

I would like to fix the bug reported in JDK-8277866.  
There is a typo in test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java as suggested in the issue.  
The second test case is expected to run with -Xms in addition to -Xmx option. However, -Xmx option appears twice in the test.  
This typo causes a failure of the test, and after fixing this typo, the test successfully passed.  
Although ProblemList contains TestMemoryMXBeans.java, this typo should be fixed.

-------------

Commit messages:
 - 8277866: gc/epsilon/TestMemoryMXBeans.java failed with wrong initial heap size

Changes: https://git.openjdk.java.net/jdk/pull/6574/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6574&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277866
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6574.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6574/head:pull/6574

PR: https://git.openjdk.java.net/jdk/pull/6574


From jiefu at openjdk.java.net  Fri Nov 26 13:30:09 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 26 Nov 2021 13:30:09 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <WGK9UJwD18DgDI-PzJWipPEZUaMZcpn0GOJQ3Dy6pcA=.336f9856-d629-4a0d-811d-9a3db7fd2e9d@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
 <WGK9UJwD18DgDI-PzJWipPEZUaMZcpn0GOJQ3Dy6pcA=.336f9856-d629-4a0d-811d-9a3db7fd2e9d@github.com>
Message-ID: <BsXzOJx4XeAWNmbIosIfPIBslOF3Nd4PQL8WuHR9IPM=.b2ef33ae-3a8e-4029-8b83-38a4f4190dd7@github.com>

On Fri, 26 Nov 2021 11:28:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I think this is good, but I had to amend the CSR (https://bugs.openjdk.java.net/browse/JDK-8275142) for it for this case. As soon as it has been approved again sometime next week, this change can be integrated. Also fixed the release note.

Sure.
Thanks @tschatzl for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From ayang at openjdk.java.net  Fri Nov 26 14:37:05 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 26 Nov 2021 14:37:05 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
 [v2]
In-Reply-To: <pOtz8wvwoxYjOb92mwfCU3E_w68Sy90P7p28En3kP0Q=.d0f1a683-b270-4db0-bde4-5dbeb437bd88@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
 <pOtz8wvwoxYjOb92mwfCU3E_w68Sy90P7p28En3kP0Q=.d0f1a683-b270-4db0-bde4-5dbeb437bd88@github.com>
Message-ID: <LiejRKZwxjBTxJtFXq2-zYiRMfJTMBcYjH9AJL4aD38=.3abf05c1-a27f-4d1c-a73d-0d527a2d36f2@github.com>

On Thu, 25 Nov 2021 04:12:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

1. There are still a few places where `G1SegmentedArrayFreePool<mtGCCardSet>` is used, instead of `G1CardSetFreePool`. I am not entirely sure if that's intended.

2. It's undesirable to include some `buffer -> segment` renames in this PR.

Both are very subjective though.

-------------

Marked as reviewed by ayang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6514


From lkorinth at openjdk.java.net  Fri Nov 26 14:43:28 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Fri, 26 Nov 2021 14:43:28 GMT
Subject: RFR: 8277865: G1: Change integer division to floating point division
Message-ID: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>

In the class G1PreConcurrentStartTask::NoteStartOfMarkTask the method `worker_cost` returns a cost of type double, unfortunately the return value is calculated using an integer division:

`return _claimer.n_regions() / regions_per_thread;`

-------------

Commit messages:
 - 8277865: G1: Change integer division to floating point division

Changes: https://git.openjdk.java.net/jdk/pull/6577/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6577&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277865
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6577/head:pull/6577

PR: https://git.openjdk.java.net/jdk/pull/6577


From ayang at openjdk.java.net  Fri Nov 26 14:55:08 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 26 Nov 2021 14:55:08 GMT
Subject: RFR: 8277865: G1: Change integer division to floating point
 division
In-Reply-To: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>
References: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>
Message-ID: <mKfk9bohUA5sB52xdZZHi7_0hCZbkqvbHFIeNq_zZTQ=.a0a3a742-6f05-4499-8221-ddb1e74ad6a4@github.com>

On Fri, 26 Nov 2021 14:35:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> In the class G1PreConcurrentStartTask::NoteStartOfMarkTask the method `worker_cost` returns a cost of type double, unfortunately the return value is calculated using an integer division:
> 
> `return _claimer.n_regions() / regions_per_thread;`

Marked as reviewed by ayang (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6577


From tschatzl at openjdk.java.net  Fri Nov 26 15:20:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 26 Nov 2021 15:20:04 GMT
Subject: RFR: 8277865: G1: Change integer division to floating point
 division
In-Reply-To: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>
References: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>
Message-ID: <F_fuuqS7ks2Vh6fAJccp2m43xCjZQaFQY-_S3cWwqTQ=.0106e2f2-4639-482b-907f-eeab17a14be0@github.com>

On Fri, 26 Nov 2021 14:35:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> In the class G1PreConcurrentStartTask::NoteStartOfMarkTask the method `worker_cost` returns a cost of type double, unfortunately the return value is calculated using an integer division:
> 
> `return _claimer.n_regions() / regions_per_thread;`

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6577


From tschatzl at openjdk.java.net  Fri Nov 26 15:22:03 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 26 Nov 2021 15:22:03 GMT
Subject: RFR: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_
 used interchangeably
In-Reply-To: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
References: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
Message-ID: <TQOMjK6bKEU3XZ_gN1oa0l0dx6Rb48pL5BTdi14GQjM=.bd3e096a-6115-469e-862a-05417897106f@github.com>

On Thu, 25 Nov 2021 20:30:51 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small refactoring to consistently use prefix `max_` for variable names where the variable represents a limit in G1CardSetConfiguration.
> 
> Thanks

Lgtm apart from that small proposed comment update.

src/hotspot/share/gc/g1/g1CardSet.hpp line 97:

> 95: 
> 96:   // Array of Cards configuration
> 97:   // Number of cards in "Array of Cards" set; 0 to disable.

Maybe add a "Maximum" here too.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6567


From iwalulya at openjdk.java.net  Fri Nov 26 15:59:34 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 26 Nov 2021 15:59:34 GMT
Subject: RFR: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_
 used interchangeably [v2]
In-Reply-To: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
References: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
Message-ID: <gpTx7R1qhDf-06FejXJOK-4bhAkXe5RkRNCVjyI83f4=.9347293f-e2a5-41da-b1e9-ffb84f059162@github.com>

> Hi all,
> 
> Please review this small refactoring to consistently use prefix `max_` for variable names where the variable represents a limit in G1CardSetConfiguration.
> 
> Thanks

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6567/files
  - new: https://git.openjdk.java.net/jdk/pull/6567/files/ceb50a6a..886ee68e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6567&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6567&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6567.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6567/head:pull/6567

PR: https://git.openjdk.java.net/jdk/pull/6567


From roland at openjdk.java.net  Fri Nov 26 16:28:07 2021
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 26 Nov 2021 16:28:07 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
 <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
Message-ID: <ViZGo0LhHdIfxeS14Q3UtH-iMHD-XkJ2AYgSJvw2A_E=.c8dc9c16-f994-4db8-a8f9-c0b7f5685cd7@github.com>

On Fri, 26 Nov 2021 09:42:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] specjvm -XX:+UseShenandoahGC
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove verify_raw_mem()

Looks good to me.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6526


From mli at openjdk.java.net  Sat Nov 27 00:50:16 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 27 Nov 2021 00:50:16 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
 [v2]
In-Reply-To: <LiejRKZwxjBTxJtFXq2-zYiRMfJTMBcYjH9AJL4aD38=.3abf05c1-a27f-4d1c-a73d-0d527a2d36f2@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
 <pOtz8wvwoxYjOb92mwfCU3E_w68Sy90P7p28En3kP0Q=.d0f1a683-b270-4db0-bde4-5dbeb437bd88@github.com>
 <LiejRKZwxjBTxJtFXq2-zYiRMfJTMBcYjH9AJL4aD38=.3abf05c1-a27f-4d1c-a73d-0d527a2d36f2@github.com>
Message-ID: <mAYnpUGW4Sy777AvjTcHbQJUYw4yV59QsU8nQ5STHGA=.e83defaf-904b-411a-b3a5-0ce71292bb01@github.com>

On Fri, 26 Nov 2021 14:33:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 1. There are still a few places where `G1SegmentedArrayFreePool<mtGCCardSet>` is used, instead of `G1CardSetFreePool`. I am not entirely sure if that's intended.

Yes, it's intended, will be refactored in later related pr.

> 2. It's undesirable to include some `buffer -> segment` renames in this PR.

I see, will pay attention in the future.

> 
> Both are very subjective though.

Thanks for detailed comments. :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/6514


From mli at openjdk.java.net  Sat Nov 27 00:51:09 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 27 Nov 2021 00:51:09 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <eSLPP_tdmNkZjTRjf-pa_zyAVW19VPOd3yTIc9w44Tg=.d5bd3617-23ad-4983-bcb6-c0bbfcb4cd6d@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
 <eSLPP_tdmNkZjTRjf-pa_zyAVW19VPOd3yTIc9w44Tg=.d5bd3617-23ad-4983-bcb6-c0bbfcb4cd6d@github.com>
Message-ID: <tlhZhp039_xz5XmSvzt5uBRy15sIrjYxhVkh_KPTou0=.3d54cf89-269a-4a6a-86d2-e77c01c70b35@github.com>

On Fri, 26 Nov 2021 08:33:27 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > * Not sure if the lower bound should also be distinguished between 32 and 64. It's not because of crash, but as you're touching it, should we consider this?
> 
> Not sure if there is any benefit to distinguish the lower bounds between 32-bit and 64-bit platforms. But this pr aims at fixing the crash caused by the incorrect upper bound on 32-bit platforms. So a separate pr seems better if the lower bound needs to be re-considered.

I'm fine with it.

> 
> > * Does a CSR needed?
> 
> Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet. But I'm not sure.

Please follow Thomas's suggestion.

> 
> > * A regression test would be helpful.
> 
> There is already a jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java for this regression.
> 

I was wondering why it's not caught by regionion test until I saw Thomas' response.

Thanks for clarifying and fixing this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From mli at openjdk.java.net  Sat Nov 27 00:51:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 27 Nov 2021 00:51:08 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
Message-ID: <VaQSg1r-ANEmq7MAPRFMmGD1KPwvKpfFJ3g1swqFB5E=.cb4773df-4223-433e-b4a2-f45a5050a0d9@github.com>

On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
> 
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
> 
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

Marked as reviewed by mli (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From mli at openjdk.java.net  Sat Nov 27 00:50:17 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 27 Nov 2021 00:50:17 GMT
Subject: RFR: 8276670: G1: Rename G1CardSetFreePool and related classes
 [v2]
In-Reply-To: <PZYKZIBq-9oxnZkoQuN9mid5ywrbOf_GO_lDGqprKF8=.89a02a7d-b8ce-47e6-b0ce-dd49234a8b73@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
 <PZYKZIBq-9oxnZkoQuN9mid5ywrbOf_GO_lDGqprKF8=.89a02a7d-b8ce-47e6-b0ce-dd49234a8b73@github.com>
Message-ID: <EaKFAUg0m8fnvHk8HDYQ2ufmoNDzaOsDRtLukJUKYkc=.4c248f81-0279-4340-b636-3efbb1b63c96@github.com>

On Wed, 24 Nov 2021 13:29:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert review
>
> Lgtm. Thanks for fixing some pre-existing include-orderings...

Thanks @tschatzl @albertnetymk for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6514


From mli at openjdk.java.net  Sat Nov 27 00:50:20 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 27 Nov 2021 00:50:20 GMT
Subject: Integrated: 8276670: G1: Rename G1CardSetFreePool and related classes
In-Reply-To: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
References: <2Vnydt891tDy-BR2SlCFJnVXeuOxARVhLMZMr5DAChM=.83fd8e41-734c-4983-9c72-12e8d6a4d411@github.com>
Message-ID: <gjIwl5oRR1BqDWIRctIfc4ZLqgxk6zp3pmljvnRo7XQ=.75760cc8-72a9-4c0b-87c4-32fd5205763f@github.com>

On Tue, 23 Nov 2021 06:26:19 GMT, Hamlin Li <mli at openjdk.org> wrote:

> As G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be renamed.

This pull request has now been integrated.

Changeset: e9b36a83
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e9b36a83160d3c1fa79841692e9fadf336bf7954
Stats:     725 lines in 17 files changed: 334 ins; 316 del; 75 mod

8276670: G1: Rename G1CardSetFreePool and related classes

Reviewed-by: tschatzl, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/6514


From jiefu at openjdk.java.net  Sat Nov 27 04:11:09 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 27 Nov 2021 04:11:09 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <tlhZhp039_xz5XmSvzt5uBRy15sIrjYxhVkh_KPTou0=.3d54cf89-269a-4a6a-86d2-e77c01c70b35@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
 <eSLPP_tdmNkZjTRjf-pa_zyAVW19VPOd3yTIc9w44Tg=.d5bd3617-23ad-4983-bcb6-c0bbfcb4cd6d@github.com>
 <tlhZhp039_xz5XmSvzt5uBRy15sIrjYxhVkh_KPTou0=.3d54cf89-269a-4a6a-86d2-e77c01c70b35@github.com>
Message-ID: <e0QM72UpPlBIFAK-UAIKtejbvql99s5q3BJ6UAIyoTo=.bb2b0456-683c-4050-a52f-e4ce7c144a2c@github.com>

On Sat, 27 Nov 2021 00:47:55 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Good questions!
>> Thanks @Hamlin-Li for your review.
>> 
>> 
>>> Several initial comments:
>>> 
>>> * Not sure if the lower bound should also be distinguished between 32 and 64. It's not because of crash, but as you're touching it, should we consider this?
>> 
>> Not sure if there is any benefit to distinguish the lower bounds between 32-bit and 64-bit platforms.
>> But this pr aims at fixing the crash caused by the incorrect upper bound on 32-bit platforms.
>> So a separate pr seems better if the lower bound needs to be re-considered.
>> 
>>> * Does a CSR needed?
>> 
>> Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet.
>> But I'm not sure.
>> 
>>> * A regression test would be helpful.
>> 
>> There is already a jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java for this regression.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
>> > * Not sure if the lower bound should also be distinguished between 32 and 64. It's not because of crash, but as you're touching it, should we consider this?
>> 
>> Not sure if there is any benefit to distinguish the lower bounds between 32-bit and 64-bit platforms. But this pr aims at fixing the crash caused by the incorrect upper bound on 32-bit platforms. So a separate pr seems better if the lower bound needs to be re-considered.
> 
> I'm fine with it.
> 
>> 
>> > * Does a CSR needed?
>> 
>> Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet. But I'm not sure.
> 
> Please follow Thomas's suggestion.
> 
>> 
>> > * A regression test would be helpful.
>> 
>> There is already a jtreg test runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java for this regression.
>> 
> 
> I was wondering why it's not caught by regionion test until I saw Thomas' response.
> 
> Thanks for clarifying and fixing this.

Thanks @Hamlin-Li for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From kbarrett at openjdk.java.net  Sun Nov 28 20:10:22 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 28 Nov 2021 20:10:22 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
Message-ID: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>

Please review this change which fixes a rare assert failure in
G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
referencing values from the forwardee, and that isn't safe. When an object is
copied and forwarded to the copy, the forwarding is performed with a relaxed
cmpxchg. This means the data being copied into the forwardee might not be
visible to a different thread that has obtained the forwardee. All uses of a
forwardee must take care to avoid reading from it without performing
additional synchronization. The assert in question violates that restriction.

The incorrect assertion is

assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");

obj is the forwardee of a different object.

It's okay here to examine the contents of obj when it's in the cset.  In
that case it's not a copy; it's the original object, self-forwarded due to
evacuation failure.

But it's not okay to examine the contents of obj when it's not in the cset,
e.g. when it's a forwardee copy of the original object.  Doing so violates
the above restriction.

So that tells us this code is wrong, but it's still not obvious this is the
cause of the failure in question.  The failure we're seeing appears to be
that obj->is_forwarded() returns true, but the assert of the same thing in
forwardee returns false.  But is_forwarded() should never be true for a
copied forwardee.  But it turns out a copied forwardee might temporarily
appear to be forwarded, due to the unordered copy + forward sequence.
Consider the following scenario:

A thread is evacuating an object and allocates a candidate forwardee, copies
into it, and finally discovers the forwarding race was lost even before the
copy.  The candidate forwardee appears to be marked as forwarded.  That
candidate is deallocated and the real forwardee is used by the thread.

That same thread evacuates a second object, reallocating some of the same
memory as from the previous candidate.  It copies the second object into the
new forwardee, successfully performs the forwarding, and uses that newly
created forwardee.

A second thread attempts to evacuate that same second object, and finds it
already forwarded.  It goes into write_ref_field_post, reaches the assert,
and attempts to use values from the forwardee.  Because the copy and the
forwarding by the first thread were unordered, this second thread might see
the old copy that appears to be forwarded, rather than the up to date copy.
So the first call to is_forwarded() returns true.  The forwardee() assert of
the same thing might instead get the up to date contents, resulting in the
reported failure.  Alternatively, it might still get old data, in which case
nothing gets noticed because the self-forward check will fail and the
write_ref_field_post assert will (accidentally) succeed.

So there's a very small window in which the reported failure can occur.  But
it's all caused by the write_ref_field_post assert performing invalid
accesses.  Stop doing that and the problem should go away.

I think this failure couldn't have happened before JDK-8271579, but that's
kind of accidental and doesn't change that the write_ref_field_post assert
was performing invalid accesses.  (Those accesses were introduced later.)

Testing:
mach5 tier1-5.

Ran applications/jcstress/acqrel.java 100 times without failure.
Without the change I had a 25-30% failure rate for that test.
I don't know why that test was such a good canary, when this failure seems to
otherwise be pretty rare, but glad that it was.

-------------

Commit messages:
 - remove test from problemlist
 - avoid assert based on possibly bad data

Changes: https://git.openjdk.java.net/jdk/pull/6582/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6582&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277434
  Stats: 10 lines in 3 files changed: 6 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6582/head:pull/6582

PR: https://git.openjdk.java.net/jdk/pull/6582


From kbarrett at openjdk.java.net  Mon Nov 29 05:11:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 29 Nov 2021 05:11:07 GMT
Subject: RFR: 8277814: ConcurrentRefineThread should report rate when
 deactivating
In-Reply-To: <YagyR-aN6MIk2UCeWDN0hSDDiknLnoRmHN4OA9rQKRA=.aa32f746-c7b9-4f7d-a4ca-184e58b76955@github.com>
References: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
 <YagyR-aN6MIk2UCeWDN0hSDDiknLnoRmHN4OA9rQKRA=.aa32f746-c7b9-4f7d-a4ca-184e58b76955@github.com>
Message-ID: <PcgZ_7PpZ7hvGYPUtp9XpRplTozW_06Im8Quf2Szf-A=.fd046625-2b70-4d7a-bb06-0d5c84e4f03a@github.com>

On Fri, 26 Nov 2021 11:31:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change to the logging by concurrent refinement threads.
>> This change adds the cards processed per ms to the deactivation log message.
>> 
>> Testing:
>> mach5 tier1
>> locally ran a test with gc+refine=debug logging enabled and verified the
>> expected change to the deactivation log message.
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineStats.cpp line 38:
> 
>> 36:   // Report 0 when no time recorded because no refinement performed.
>> 37:   double secs = refinement_time().seconds();
>> 38:   return (secs > 0) ? (refined_cards() / (secs * MILLIUNITS)) : 0.0;
> 
> Not sure how this is used, but in similar calculations we only use and return a value if the elapsed time is large enough (something like a microsecond or so) to remove extreme outliers. Not sure if that is needed here too.

This change only uses it for logging.  I could just drop this function and do the equivalent calculation at the point where it's used.  I don't think a made up lower limit really makes that much sense anyway; I remember some places like you describe, but I thought many had been eliminated.  I could only find a couple.  The expectation here is that refined_cards() is probably also zero, unless the time granularity is rather coarse.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6550


From ayang at openjdk.java.net  Mon Nov 29 08:11:03 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 08:11:03 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
Message-ID: <gJ4QxyQI6xErEP2UPXmflaSGjfnmE1dglRbdZDYSQiI=.e108f5ee-27ba-459e-a06f-a2b5eaf1cf67@github.com>

On Sun, 28 Nov 2021 03:30:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes a rare assert failure in
> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
> referencing values from the forwardee, and that isn't safe. When an object is
> copied and forwarded to the copy, the forwarding is performed with a relaxed
> cmpxchg. This means the data being copied into the forwardee might not be
> visible to a different thread that has obtained the forwardee. All uses of a
> forwardee must take care to avoid reading from it without performing
> additional synchronization. The assert in question violates that restriction.
> 
> The incorrect assertion is
> 
> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
> 
> obj is the forwardee of a different object.
> 
> It's okay here to examine the contents of obj when it's in the cset.  In
> that case it's not a copy; it's the original object, self-forwarded due to
> evacuation failure.
> 
> But it's not okay to examine the contents of obj when it's not in the cset,
> e.g. when it's a forwardee copy of the original object.  Doing so violates
> the above restriction.
> 
> So that tells us this code is wrong, but it's still not obvious this is the
> cause of the failure in question.  The failure we're seeing appears to be
> that obj->is_forwarded() returns true, but the assert of the same thing in
> forwardee returns false.  But is_forwarded() should never be true for a
> copied forwardee.  But it turns out a copied forwardee might temporarily
> appear to be forwarded, due to the unordered copy + forward sequence.
> Consider the following scenario:
> 
> A thread is evacuating an object and allocates a candidate forwardee, copies
> into it, and finally discovers the forwarding race was lost even before the
> copy.  The candidate forwardee appears to be marked as forwarded.  That
> candidate is deallocated and the real forwardee is used by the thread.
> 
> That same thread evacuates a second object, reallocating some of the same
> memory as from the previous candidate.  It copies the second object into the
> new forwardee, successfully performs the forwarding, and uses that newly
> created forwardee.
> 
> A second thread attempts to evacuate that same second object, and finds it
> already forwarded.  It goes into write_ref_field_post, reaches the assert,
> and attempts to use values from the forwardee.  Because the copy and the
> forwarding by the first thread were unordered, this second thread might see
> the old copy that appears to be forwarded, rather than the up to date copy.
> So the first call to is_forwarded() returns true.  The forwardee() assert of
> the same thing might instead get the up to date contents, resulting in the
> reported failure.  Alternatively, it might still get old data, in which case
> nothing gets noticed because the self-forward check will fail and the
> write_ref_field_post assert will (accidentally) succeed.
> 
> So there's a very small window in which the reported failure can occur.  But
> it's all caused by the write_ref_field_post assert performing invalid
> accesses.  Stop doing that and the problem should go away.
> 
> I think this failure couldn't have happened before JDK-8271579, but that's
> kind of accidental and doesn't change that the write_ref_field_post assert
> was performing invalid accesses.  (Those accesses were introduced later.)
> 
> Testing:
> mach5 tier1-5.
> 
> Ran applications/jcstress/acqrel.java 100 times without failure.
> Without the change I had a 25-30% failure rate for that test.
> I don't know why that test was such a good canary, when this failure seems to
> otherwise be pretty rare, but glad that it was.

Thank you for the detailed analysis; this makes perfect sense.

-------------

Marked as reviewed by ayang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6582


From shade at openjdk.java.net  Mon Nov 29 08:11:04 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Nov 2021 08:11:04 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
Message-ID: <hXNMQMMNUqOHiNH1h25xhaJkwiRGqopNgn5zpR3tXoc=.d30ec4cf-615e-4b31-ba83-36094f444f39@github.com>

On Sun, 28 Nov 2021 03:30:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes a rare assert failure in
> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
> referencing values from the forwardee, and that isn't safe. When an object is
> copied and forwarded to the copy, the forwarding is performed with a relaxed
> cmpxchg. This means the data being copied into the forwardee might not be
> visible to a different thread that has obtained the forwardee. All uses of a
> forwardee must take care to avoid reading from it without performing
> additional synchronization. The assert in question violates that restriction.
> 
> The incorrect assertion is
> 
> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
> 
> obj is the forwardee of a different object.
> 
> It's okay here to examine the contents of obj when it's in the cset.  In
> that case it's not a copy; it's the original object, self-forwarded due to
> evacuation failure.
> 
> But it's not okay to examine the contents of obj when it's not in the cset,
> e.g. when it's a forwardee copy of the original object.  Doing so violates
> the above restriction.
> 
> So that tells us this code is wrong, but it's still not obvious this is the
> cause of the failure in question.  The failure we're seeing appears to be
> that obj->is_forwarded() returns true, but the assert of the same thing in
> forwardee returns false.  But is_forwarded() should never be true for a
> copied forwardee.  But it turns out a copied forwardee might temporarily
> appear to be forwarded, due to the unordered copy + forward sequence.
> Consider the following scenario:
> 
> A thread is evacuating an object and allocates a candidate forwardee, copies
> into it, and finally discovers the forwarding race was lost even before the
> copy.  The candidate forwardee appears to be marked as forwarded.  That
> candidate is deallocated and the real forwardee is used by the thread.
> 
> That same thread evacuates a second object, reallocating some of the same
> memory as from the previous candidate.  It copies the second object into the
> new forwardee, successfully performs the forwarding, and uses that newly
> created forwardee.
> 
> A second thread attempts to evacuate that same second object, and finds it
> already forwarded.  It goes into write_ref_field_post, reaches the assert,
> and attempts to use values from the forwardee.  Because the copy and the
> forwarding by the first thread were unordered, this second thread might see
> the old copy that appears to be forwarded, rather than the up to date copy.
> So the first call to is_forwarded() returns true.  The forwardee() assert of
> the same thing might instead get the up to date contents, resulting in the
> reported failure.  Alternatively, it might still get old data, in which case
> nothing gets noticed because the self-forward check will fail and the
> write_ref_field_post assert will (accidentally) succeed.
> 
> So there's a very small window in which the reported failure can occur.  But
> it's all caused by the write_ref_field_post assert performing invalid
> accesses.  Stop doing that and the problem should go away.
> 
> I think this failure couldn't have happened before JDK-8271579, but that's
> kind of accidental and doesn't change that the write_ref_field_post assert
> was performing invalid accesses.  (Those accesses were introduced later.)
> 
> Testing:
> mach5 tier1-5.
> 
> Ran applications/jcstress/acqrel.java 100 times without failure.
> Without the change I had a 25-30% failure rate for that test.
> I don't know why that test was such a good canary, when this failure seems to
> otherwise be pretty rare, but glad that it was.

Ooof, so a relaxed forwardee installation comes with an odd invariant like this. I linked JDK-8204524 to this issue, to track where the forwardee installation was relaxed. 

The fix for this particular issue looks fine to me, thanks.

A few follow-up questions about the general issue here. How is it not affecting the other places where G1 accesses `obj->forwardee()`, like in `G1ScanClosureBase::prefetch_and_push` or `G1ParScanThreadState::do_partial_array`? Also, it is not theoretically clear how would "All uses of a forwardee must take care to avoid reading from it without performing additional synchronization", given that the trouble had already happened on writer side, and there is little a reader can do to recover?

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6582


From tschatzl at openjdk.java.net  Mon Nov 29 08:35:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 08:35:07 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
Message-ID: <HaVkkDb7ka9RjHes6gN1U-4Ts_4JQv7BaK1BYat_h_s=.b0274013-40ef-4865-b7df-281a60b6e76b@github.com>

On Sun, 28 Nov 2021 03:30:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes a rare assert failure in
> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
> referencing values from the forwardee, and that isn't safe. When an object is
> copied and forwarded to the copy, the forwarding is performed with a relaxed
> cmpxchg. This means the data being copied into the forwardee might not be
> visible to a different thread that has obtained the forwardee. All uses of a
> forwardee must take care to avoid reading from it without performing
> additional synchronization. The assert in question violates that restriction.
> 
> The incorrect assertion is
> 
> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
> 
> obj is the forwardee of a different object.
> 
> It's okay here to examine the contents of obj when it's in the cset.  In
> that case it's not a copy; it's the original object, self-forwarded due to
> evacuation failure.
> 
> But it's not okay to examine the contents of obj when it's not in the cset,
> e.g. when it's a forwardee copy of the original object.  Doing so violates
> the above restriction.
> 
> So that tells us this code is wrong, but it's still not obvious this is the
> cause of the failure in question.  The failure we're seeing appears to be
> that obj->is_forwarded() returns true, but the assert of the same thing in
> forwardee returns false.  But is_forwarded() should never be true for a
> copied forwardee.  But it turns out a copied forwardee might temporarily
> appear to be forwarded, due to the unordered copy + forward sequence.
> Consider the following scenario:
> 
> A thread is evacuating an object and allocates a candidate forwardee, copies
> into it, and finally discovers the forwarding race was lost even before the
> copy.  The candidate forwardee appears to be marked as forwarded.  That
> candidate is deallocated and the real forwardee is used by the thread.
> 
> That same thread evacuates a second object, reallocating some of the same
> memory as from the previous candidate.  It copies the second object into the
> new forwardee, successfully performs the forwarding, and uses that newly
> created forwardee.
> 
> A second thread attempts to evacuate that same second object, and finds it
> already forwarded.  It goes into write_ref_field_post, reaches the assert,
> and attempts to use values from the forwardee.  Because the copy and the
> forwarding by the first thread were unordered, this second thread might see
> the old copy that appears to be forwarded, rather than the up to date copy.
> So the first call to is_forwarded() returns true.  The forwardee() assert of
> the same thing might instead get the up to date contents, resulting in the
> reported failure.  Alternatively, it might still get old data, in which case
> nothing gets noticed because the self-forward check will fail and the
> write_ref_field_post assert will (accidentally) succeed.
> 
> So there's a very small window in which the reported failure can occur.  But
> it's all caused by the write_ref_field_post assert performing invalid
> accesses.  Stop doing that and the problem should go away.
> 
> I think this failure couldn't have happened before JDK-8271579, but that's
> kind of accidental and doesn't change that the write_ref_field_post assert
> was performing invalid accesses.  (Those accesses were introduced later.)
> 
> Testing:
> mach5 tier1-5.
> 
> Ran applications/jcstress/acqrel.java 100 times without failure.
> Without the change I had a 25-30% failure rate for that test.
> I don't know why that test was such a good canary, when this failure seems to
> otherwise be pretty rare, but glad that it was.

lgtm

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6582


From tschatzl at openjdk.java.net  Mon Nov 29 08:35:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 08:35:07 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <hXNMQMMNUqOHiNH1h25xhaJkwiRGqopNgn5zpR3tXoc=.d30ec4cf-615e-4b31-ba83-36094f444f39@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
 <hXNMQMMNUqOHiNH1h25xhaJkwiRGqopNgn5zpR3tXoc=.d30ec4cf-615e-4b31-ba83-36094f444f39@github.com>
Message-ID: <PpRXOtraFKv6PL6Y1J4vZhXN7XUxckJG5zFqaNGN010=.3bb4e67b-b08e-4d2e-b613-03364519101e@github.com>

On Mon, 29 Nov 2021 08:07:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Ooof, so a relaxed forwardee installation comes with an odd invariant like this. I linked JDK-8204524 to this issue, to track where the forwardee installation was relaxed.
> 
> The fix for this particular issue looks fine to me, thanks.
> 
> A few follow-up questions about the general issue here. How is it not affecting the other places where G1 accesses `obj->forwardee()`, like in `G1ScanClosureBase::prefetch_and_push` or `G1ParScanThreadState::do_partial_array`? Also, it is not theoretically clear how would "All uses of a forwardee must take care to avoid reading from it without performing additional synchronization", given that the trouble had already happened on writer side, and there is little a reader can do to recover?

Both cases examine the original object in the collection set only; for the first example there is an explicit check on `is_in_cset` before the call (`G1ScanEvacuatedObjClosure::do_oop_work` is also only ever called from the thread that copied the object too; but all `G1ScanClosureBase::prefetch_and_push` are guarded by an `is_in_cset` check). `from_obj` in `G1ParScanThreadState::do_partial_array` is always in the collection set, i.e.

    assert(_g1h->is_in_reserved(from_obj), "must be in heap.");

could be rephrased as `g1h->is_in_cset(from_obj)`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6582


From tschatzl at openjdk.java.net  Mon Nov 29 09:00:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 09:00:08 GMT
Subject: RFR: 8277814: ConcurrentRefineThread should report rate when
 deactivating
In-Reply-To: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
References: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
Message-ID: <Bykqp9XyJPfiTCGb0DVQ7p2ogH1wxMJ2dmpXe2jJ9ds=.64750bae-1f2f-48c6-b619-98a930fdad8f@github.com>

On Thu, 25 Nov 2021 04:24:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the logging by concurrent refinement threads.
> This change adds the cards processed per ms to the deactivation log message.
> 
> Testing:
> mach5 tier1
> locally ran a test with gc+refine=debug logging enabled and verified the
> expected change to the deactivation log message.

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6550


From lkorinth at openjdk.java.net  Mon Nov 29 09:10:09 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 29 Nov 2021 09:10:09 GMT
Subject: Integrated: 8277865: G1: Change integer division to floating point
 division
In-Reply-To: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>
References: <LwiSSMOabIHfZI8HfZqRHV8xyfBfYk93eI0QxHX7Ebc=.8ba702b7-c211-4530-aef3-dbf3178fcec2@github.com>
Message-ID: <nXN6SY_7lnFaDzhEpeCnyvu1LOz6aInkRwIBm1-0hxc=.1cae0128-3bca-4a1b-b181-27d3c71116c3@github.com>

On Fri, 26 Nov 2021 14:35:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> In the class G1PreConcurrentStartTask::NoteStartOfMarkTask the method `worker_cost` returns a cost of type double, unfortunately the return value is calculated using an integer division:
> 
> `return _claimer.n_regions() / regions_per_thread;`

This pull request has now been integrated.

Changeset: 9a3a9b13
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9a3a9b139178f2645d51a0f12d95a8b424cd5b9d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8277865: G1: Change integer division to floating point division

Reviewed-by: ayang, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6577


From kim.barrett at oracle.com  Mon Nov 29 09:10:21 2021
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 29 Nov 2021 09:10:21 +0000
Subject: RFR: 8277434: tests fail with "assert(is_forwarded()) failed:
 only decode when actually forwarded"
In-Reply-To: <PpRXOtraFKv6PL6Y1J4vZhXN7XUxckJG5zFqaNGN010=.3bb4e67b-b08e-4d2e-b613-03364519101e@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
 <hXNMQMMNUqOHiNH1h25xhaJkwiRGqopNgn5zpR3tXoc=.d30ec4cf-615e-4b31-ba83-36094f444f39@github.com>
 <PpRXOtraFKv6PL6Y1J4vZhXN7XUxckJG5zFqaNGN010=.3bb4e67b-b08e-4d2e-b613-03364519101e@github.com>
Message-ID: <8E95A40F-8DCA-42C8-98DF-C43ED7962941@oracle.com>

> On Nov 29, 2021, at 3:35 AM, Thomas Schatzl <tschatzl at openjdk.java.net> wrote:
> 
> On Mon, 29 Nov 2021 08:07:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> 
>> Ooof, so a relaxed forwardee installation comes with an odd invariant like this. I linked JDK-8204524 to this issue, to track where the forwardee installation was relaxed.
>> 
>> The fix for this particular issue looks fine to me, thanks.
>> 
>> A few follow-up questions about the general issue here. How is it not affecting the other places where G1 accesses `obj->forwardee()`, like in `G1ScanClosureBase::prefetch_and_push` or `G1ParScanThreadState::do_partial_array`? Also, it is not theoretically clear how would "All uses of a forwardee must take care to avoid reading from it without performing additional synchronization", given that the trouble had already happened on writer side, and there is little a reader can do to recover?
> 
> Both cases examine the original object in the collection set only; for the first example there is an explicit check on `is_in_cset` before the call (`G1ScanEvacuatedObjClosure::do_oop_work` is also only ever called from the thread that copied the object too; but all `G1ScanClosureBase::prefetch_and_push` are guarded by an `is_in_cset` check). `from_obj` in `G1ParScanThreadState::do_partial_array` is always in the collection set, i.e.
> 
>    assert(_g1h->is_in_reserved(from_obj), "must be in heap.");
> 
> could be rephrased as `g1h->is_in_cset(from_obj)`.

The key point in the G1ScanEvacuatedObjClosure::do_oop_work case is that the
thread that copied the object is the thread doing the prefetch_and_push.  It's
buried in the obj->oop_iterate_backwards call in do_copy_to_survivor_space.

For do_partial_array, while the from_obj is in the collection set, its
forwardee is not, and might also not be up to date if not for the additional
synchronization provided by being distributed through the taskqueue.
start_partial_objarray pushes tasks onto the taskqueue, which involves a
release-store. And the thread that obtains the task does a pop-local or
pop-global from the taskqueue, which involves acquire or fence. So the
contents of the forwardee in the object in the partial-array task are
up-to-date when processing the task. That's an example of "additional
synchronization" I was referring to.

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/6582



From shade at openjdk.java.net  Mon Nov 29 09:16:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Nov 2021 09:16:08 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
Message-ID: <I4b1eRn0u9g2gY9DpEawtXagjrRyt8MCLFw-R0ZlFp4=.3b2f976b-72f8-42b3-ad04-80d350748d92@github.com>

On Sun, 28 Nov 2021 03:30:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes a rare assert failure in
> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
> referencing values from the forwardee, and that isn't safe. When an object is
> copied and forwarded to the copy, the forwarding is performed with a relaxed
> cmpxchg. This means the data being copied into the forwardee might not be
> visible to a different thread that has obtained the forwardee. All uses of a
> forwardee must take care to avoid reading from it without performing
> additional synchronization. The assert in question violates that restriction.
> 
> The incorrect assertion is
> 
> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
> 
> obj is the forwardee of a different object.
> 
> It's okay here to examine the contents of obj when it's in the cset.  In
> that case it's not a copy; it's the original object, self-forwarded due to
> evacuation failure.
> 
> But it's not okay to examine the contents of obj when it's not in the cset,
> e.g. when it's a forwardee copy of the original object.  Doing so violates
> the above restriction.
> 
> So that tells us this code is wrong, but it's still not obvious this is the
> cause of the failure in question.  The failure we're seeing appears to be
> that obj->is_forwarded() returns true, but the assert of the same thing in
> forwardee returns false.  But is_forwarded() should never be true for a
> copied forwardee.  But it turns out a copied forwardee might temporarily
> appear to be forwarded, due to the unordered copy + forward sequence.
> Consider the following scenario:
> 
> A thread is evacuating an object and allocates a candidate forwardee, copies
> into it, and finally discovers the forwarding race was lost even before the
> copy.  The candidate forwardee appears to be marked as forwarded.  That
> candidate is deallocated and the real forwardee is used by the thread.
> 
> That same thread evacuates a second object, reallocating some of the same
> memory as from the previous candidate.  It copies the second object into the
> new forwardee, successfully performs the forwarding, and uses that newly
> created forwardee.
> 
> A second thread attempts to evacuate that same second object, and finds it
> already forwarded.  It goes into write_ref_field_post, reaches the assert,
> and attempts to use values from the forwardee.  Because the copy and the
> forwarding by the first thread were unordered, this second thread might see
> the old copy that appears to be forwarded, rather than the up to date copy.
> So the first call to is_forwarded() returns true.  The forwardee() assert of
> the same thing might instead get the up to date contents, resulting in the
> reported failure.  Alternatively, it might still get old data, in which case
> nothing gets noticed because the self-forward check will fail and the
> write_ref_field_post assert will (accidentally) succeed.
> 
> So there's a very small window in which the reported failure can occur.  But
> it's all caused by the write_ref_field_post assert performing invalid
> accesses.  Stop doing that and the problem should go away.
> 
> I think this failure couldn't have happened before JDK-8271579, but that's
> kind of accidental and doesn't change that the write_ref_field_post assert
> was performing invalid accesses.  (Those accesses were introduced later.)
> 
> Testing:
> mach5 tier1-5.
> 
> Ran applications/jcstress/acqrel.java 100 times without failure.
> Without the change I had a 25-30% failure rate for that test.
> I don't know why that test was such a good canary, when this failure seems to
> otherwise be pretty rare, but glad that it was.

All right then, thanks for explanations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6582


From ayang at openjdk.java.net  Mon Nov 29 09:29:33 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 09:29:33 GMT
Subject: RFR: 8277896: Remove unused BOTConstants member methods
Message-ID: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>

Trivial change of removing some dead code.

Test: build

-------------

Commit messages:
 - trivial

Changes: https://git.openjdk.java.net/jdk/pull/6584/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6584&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277896
  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6584.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6584/head:pull/6584

PR: https://git.openjdk.java.net/jdk/pull/6584


From kbarrett at openjdk.java.net  Mon Nov 29 09:36:09 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 29 Nov 2021 09:36:09 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor
In-Reply-To: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
Message-ID: <fQ0LEYGKGFNWUnQg8shJx9SFAUof-CubDe9QBTAnTSI=.1a0a6674-5f6e-4ed5-b791-256c3518fe51@github.com>

On Thu, 25 Nov 2021 09:29:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change removing effectively dead code, and some general cleanup.
> 
> Test: hotspot_gc

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp line 113:

> 111: public:
> 112:   RefProcWorkerTimeTracker(WorkerDataArray<double>* worker_time, uint worker_id);
> 113:   ~RefProcWorkerTimeTracker();

The usual guideline is that the destructor for a baseclass should be either
public and virtual or protected and non-virtual. This prevents destructor
slicing by `delete`. That the base class in question is a StackObj mitigates
against that kind of error.

And indeed, if I recall correctly, because it's now a StackObj its destructor
can't be virtual, because that would run afoul of the induced "deleting
destructor".

There are some relevant warning options that I occasionally look at and
remember why I think they aren't right for us, so we can't ever enable them
(-Wdelete-non-virtual-dtor and -Wnon-virtual-dtor).

But all that is kind of irrelevant.  The real design problem here is that
RefProcSubPhasesWorkerTimeTracker is derived from RefProcWorkerTimeTracker.
It should instead *have* a RefProceWorkerTimeTracker.  That would eliminate
all the discussion about base class destructors, and would also make
RefProcWorkerTimeTracker no longer need to perform double-duty as both a base
class and as a concrete class (which is often problematic).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6555


From kbarrett at openjdk.java.net  Mon Nov 29 09:38:09 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 29 Nov 2021 09:38:09 GMT
Subject: RFR: 8277896: Remove unused BOTConstants member methods
In-Reply-To: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>
References: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>
Message-ID: <j24f3c9MP8_62_jo9PKrQ2Tve4xeHqSwJ5WUdd5ktXo=.b4382f16-be18-4941-89c0-812a47aa5339@github.com>

On Mon, 29 Nov 2021 09:21:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing some dead code.
> 
> Test: build

Looks good, and trivial.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6584


From ayang at openjdk.java.net  Mon Nov 29 09:58:26 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 09:58:26 GMT
Subject: RFR: 8277899: Parallel: Simplify PSVirtualSpace::initialize logic
Message-ID: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>

Simple change of baking the static arg into `PSVirtualSpace::initialize`.

Test: hotspot_gc

-------------

Commit messages:
 - ps-virtual-init

Changes: https://git.openjdk.java.net/jdk/pull/6586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6586&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277899
  Stats: 11 lines in 3 files changed: 0 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6586/head:pull/6586

PR: https://git.openjdk.java.net/jdk/pull/6586


From mli at openjdk.java.net  Mon Nov 29 10:00:40 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 29 Nov 2021 10:00:40 GMT
Subject: RFR: 8277904: G1: Remove G1CardSetArray::max_entries
Message-ID: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>

Trivial change of removing dead code.

-------------

Commit messages:
 - typo
 - typo
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6587/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6587&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277904
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6587.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6587/head:pull/6587

PR: https://git.openjdk.java.net/jdk/pull/6587


From mli at openjdk.java.net  Mon Nov 29 10:05:15 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 29 Nov 2021 10:05:15 GMT
Subject: RFR: 8277736: G1: Allow forced evacuation failure of first N
 regions in collection set
In-Reply-To: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
References: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
Message-ID: <SVgHuVPGEr1vv1nLgtHSe5vrEu8IM5a82JS-ltf4WZ4=.387343ea-737f-439f-bb97-4824302425a1@github.com>

On Thu, 25 Nov 2021 12:54:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, debug options of evacuation failure, like G1EvacuationFailureALotInterval and G1EvacuationFailureALotCount only config the ratio of objects failing evacuation, basically the distribution of objects failing evacuation is even among regions.
> 
> JDK-8256265 is trying to improve parallelism in regions that failed evacuation, it'll be helpful if there is option to config the distribution of objects failing evacuation among regions, so implementation of JDK-8256265 could be profiled more precisely.
> 
> This is to add the support and necessary vm options, and the implementation will be to select regions from start, i.e. not randomly, the motivation is to configure a more stable selection of evacuation failure regions, which will help verify the effect of JDK-8256265 implementation.

kindly reminder ~

-------------

PR: https://git.openjdk.java.net/jdk/pull/6561


From tschatzl at openjdk.java.net  Mon Nov 29 10:24:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 10:24:09 GMT
Subject: RFR: 8277904: G1: Remove G1CardSetArray::max_entries
In-Reply-To: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>
References: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>
Message-ID: <m6fXcfFmzNE5zz75xdNgeE4s2lPN2ozkMcbwbk-zwGM=.40f1e4f3-fde6-4650-bc3d-e34ea0f87bcc@github.com>

On Mon, 29 Nov 2021 09:52:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Trivial change of removing dead code.

Lgtm and trivial

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6587


From ayang at openjdk.java.net  Mon Nov 29 10:31:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 10:31:42 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor [v2]
In-Reply-To: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
Message-ID: <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>

> Simple change removing effectively dead code, and some general cleanup.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6555/files
  - new: https://git.openjdk.java.net/jdk/pull/6555/files/38c66d66..ae0bcf93

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6555&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6555&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6555.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6555/head:pull/6555

PR: https://git.openjdk.java.net/jdk/pull/6555


From ayang at openjdk.java.net  Mon Nov 29 10:31:43 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 10:31:43 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor
In-Reply-To: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
Message-ID: <dR1mWiY6w_ocEOk8QosCqgKsD3F798Ewuv7M4WAZ85w=.11db1b2f-0ba7-48fb-974c-1651bc4098c0@github.com>

On Thu, 25 Nov 2021 09:29:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change removing effectively dead code, and some general cleanup.
> 
> Test: hotspot_gc

Switched to composition from inheritance as suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6555


From tschatzl at openjdk.java.net  Mon Nov 29 10:39:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 10:39:05 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor [v2]
In-Reply-To: <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
 <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>
Message-ID: <L6abbJHV8p-hsINUr9UBbi0IpJs-Upt4iNyJVDlcLkI=.843d79b4-9be5-4d11-b700-c492c46b2203@github.com>

On Mon, 29 Nov 2021 10:31:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change removing effectively dead code, and some general cleanup.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Still good.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6555


From ayang at openjdk.java.net  Mon Nov 29 10:40:33 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 10:40:33 GMT
Subject: RFR: 8277916: Gather non-strong reference count logic in a single
 place
Message-ID: <dCmNf9j42CnsnY7Bu8BjaE0-GopVE4cERJ4R_iS0STE=.254691ba-ee55-4ef9-9412-1bb4371a3176@github.com>

Move the logic of tracking ref-count to `ReferenceProcessorPhaseTimes` so that the provider of getter/setter is consistent inside ref-processing.

Test: hotspot_gc

-------------

Commit messages:
 - ref_count

Changes: https://git.openjdk.java.net/jdk/pull/6588/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6588&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277916
  Stats: 22 lines in 3 files changed: 10 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6588.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6588/head:pull/6588

PR: https://git.openjdk.java.net/jdk/pull/6588


From tschatzl at openjdk.java.net  Mon Nov 29 10:51:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 10:51:02 GMT
Subject: RFR: 8277899: Parallel: Simplify PSVirtualSpace::initialize logic
In-Reply-To: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
References: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
Message-ID: <FjuxiIAplNmwY8t6byCenSLR2yGZqsiaqoIo7lvdY_E=.b9b53118-ffc6-4b14-9631-a174f5c4680b@github.com>

On Mon, 29 Nov 2021 09:52:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of baking the static arg into `PSVirtualSpace::initialize`.
> 
> Test: hotspot_gc

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6586


From iwalulya at openjdk.java.net  Mon Nov 29 11:33:05 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 29 Nov 2021 11:33:05 GMT
Subject: RFR: 8277450: Record number of references into collection set
 during gc
In-Reply-To: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
References: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
Message-ID: <fme29pYugqRk-XzENjOCfz3ZiXN-ZkLf6_uG7qo8xGY=.10fd9df5-fce4-4cf1-b79d-39cfe2d1dcca@github.com>

On Tue, 23 Nov 2021 13:55:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   could I have reviews for this change that adds logging for the number of heap roots found and pushed onto the task queues from the scanned cards? This can help with finding a good card size.
> 
> Thanks,
>   Thomas

lgtm!

-------------

Marked as reviewed by iwalulya (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6519


From tschatzl at openjdk.java.net  Mon Nov 29 12:08:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 12:08:09 GMT
Subject: Integrated: 8277450: Record number of references into collection set
 during gc
In-Reply-To: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
References: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
Message-ID: <4idRaLC_ZFLNhX8hl64cgidWrt0dFxxq06MuIAnLD-k=.7fa30b00-acb8-4914-9e3f-a729774b31a3@github.com>

On Tue, 23 Nov 2021 13:55:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   could I have reviews for this change that adds logging for the number of heap roots found and pushed onto the task queues from the scanned cards? This can help with finding a good card size.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: e5676f8d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e5676f8d0b4f9e97497581e848e8b06fb7e11828
Stats:     19 lines in 6 files changed: 15 ins; 0 del; 4 mod

8277450: Record number of references into collection set during gc

Reviewed-by: kbarrett, iwalulya

-------------

PR: https://git.openjdk.java.net/jdk/pull/6519


From tschatzl at openjdk.java.net  Mon Nov 29 12:08:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 12:08:08 GMT
Subject: RFR: 8277450: Record number of references into collection set
 during gc
In-Reply-To: <fme29pYugqRk-XzENjOCfz3ZiXN-ZkLf6_uG7qo8xGY=.10fd9df5-fce4-4cf1-b79d-39cfe2d1dcca@github.com>
References: <3FTFP8AyrJUWARAcL9pZMgac6aSvLb2I_4X4jR17VLo=.30919f04-c06d-4fcf-b8f5-39da802db4a7@github.com>
 <fme29pYugqRk-XzENjOCfz3ZiXN-ZkLf6_uG7qo8xGY=.10fd9df5-fce4-4cf1-b79d-39cfe2d1dcca@github.com>
Message-ID: <1WcJBNRsN9vHviDO4vGa9XvJuXCgu7QSMQTT1JTVsio=.9597c8bb-e6b8-42aa-8e99-d1f33bfcfb9a@github.com>

On Mon, 29 Nov 2021 11:29:48 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   could I have reviews for this change that adds logging for the number of heap roots found and pushed onto the task queues from the scanned cards? This can help with finding a good card size.
>> 
>> Thanks,
>>   Thomas
>
> lgtm!

Thanks @walulyai @kimbarrett for your reviews

-------------

PR: https://git.openjdk.java.net/jdk/pull/6519


From ayang at openjdk.java.net  Mon Nov 29 12:17:07 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 12:17:07 GMT
Subject: RFR: 8277896: Remove unused BOTConstants member methods
In-Reply-To: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>
References: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>
Message-ID: <GhlJZg0dMn7-tGuoSznkV0gOjsOv1UuudjJ4P8YuBwc=.787a2cf4-e22b-4b90-8eb2-aa3c1c8c685a@github.com>

On Mon, 29 Nov 2021 09:21:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing some dead code.
> 
> Test: build

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6584


From ayang at openjdk.java.net  Mon Nov 29 12:17:08 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 12:17:08 GMT
Subject: Integrated: 8277896: Remove unused BOTConstants member methods
In-Reply-To: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>
References: <V6wgOSlstMiCkWGQZFare4zahsOSdKImtJrptb_RuIA=.0faa5855-c47a-4ec5-b49a-caafec888f6a@github.com>
Message-ID: <GxDwN0JP_HULg-GWd5Ucpyf1Ik0VUu6BuqBsPMq5DfE=.c43274b5-7133-45d6-bc89-7a09dc3a301e@github.com>

On Mon, 29 Nov 2021 09:21:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing some dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: 45e8973a
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45e8973a22424d76d62cd29f6f934116ceb695fb
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8277896: Remove unused BOTConstants member methods

Reviewed-by: kbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/6584


From mli at openjdk.java.net  Mon Nov 29 12:23:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 29 Nov 2021 12:23:08 GMT
Subject: RFR: 8277904: G1: Remove G1CardSetArray::max_entries
In-Reply-To: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>
References: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>
Message-ID: <ccNX4Lqsj5Kj8UUqZ06ecth7phL5qjhIVHCXyFqm_OY=.4d7fd9f9-ae6f-4612-8246-4235bccbfd8b@github.com>

On Mon, 29 Nov 2021 09:52:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Trivial change of removing dead code.

Thanks Thomas for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6587


From mli at openjdk.java.net  Mon Nov 29 12:23:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 29 Nov 2021 12:23:08 GMT
Subject: Integrated: 8277904: G1: Remove G1CardSetArray::max_entries
In-Reply-To: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>
References: <djqM6-qRRGeVNVoLga_NfdhSVw9XQmEmPDsa55Gz6l8=.91cc0f31-ee78-49bc-bf17-277bfde0e291@github.com>
Message-ID: <tjkngxSKzUApKqSbK_kkSjeZPAbpFBoTFYbYNqaQdy8=.9f04fb2f-b905-423a-be04-f0aed2c48444@github.com>

On Mon, 29 Nov 2021 09:52:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Trivial change of removing dead code.

This pull request has now been integrated.

Changeset: 960bdde7
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/960bdde7ebc59cefc5c60fc21b8c8267d7c0b631
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8277904: G1: Remove G1CardSetArray::max_entries

Reviewed-by: tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6587


From ayang at openjdk.java.net  Mon Nov 29 12:44:22 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 29 Nov 2021 12:44:22 GMT
Subject: RFR: 8277931: Parallel: Remove unused PSVirtualSpace::expand_into
Message-ID: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>

Trivial change of removing dead code.

Test: build

-------------

Commit messages:
 - trivial

Changes: https://git.openjdk.java.net/jdk/pull/6593/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6593&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277931
  Stats: 62 lines in 2 files changed: 0 ins; 62 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6593.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6593/head:pull/6593

PR: https://git.openjdk.java.net/jdk/pull/6593


From tschatzl at openjdk.java.net  Mon Nov 29 13:00:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 29 Nov 2021 13:00:06 GMT
Subject: RFR: 8277931: Parallel: Remove unused PSVirtualSpace::expand_into
In-Reply-To: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>
References: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>
Message-ID: <nbAbw7vqWDBqXYhFZSKYYQdKmj_CguX8KPOgIJw_ekc=.e5f8e3c1-f274-4549-b8ed-9d3c62736e4a@github.com>

On Mon, 29 Nov 2021 12:37:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Lgtm and trivial.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6593


From iwalulya at openjdk.java.net  Mon Nov 29 13:13:09 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 29 Nov 2021 13:13:09 GMT
Subject: RFR: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_
 used interchangeably [v2]
In-Reply-To: <0Sf5ZgTuygdT8LTv1Lah-yZPJXKJsM4VlFiW9b94sjw=.30dd6923-f0c8-4a79-8221-24bc0174d59a@github.com>
References: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
 <0Sf5ZgTuygdT8LTv1Lah-yZPJXKJsM4VlFiW9b94sjw=.30dd6923-f0c8-4a79-8221-24bc0174d59a@github.com>
Message-ID: <DaULFoC1ag3lNb4a9cNolS2h9tUjbyKVolE3ULFtQbo=.2da304f2-e458-42ea-a33a-ca926dd8d75c@github.com>

On Fri, 26 Nov 2021 01:07:45 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> Marked as reviewed by mli (Reviewer).

Thanks @Hamlin-Li  and @tschatzl  for the reviews

-------------

PR: https://git.openjdk.java.net/jdk/pull/6567


From iwalulya at openjdk.java.net  Mon Nov 29 13:13:10 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 29 Nov 2021 13:13:10 GMT
Subject: Integrated: 8277789: G1: G1CardSetConfiguration prefixes num_ and max_
 used interchangeably
In-Reply-To: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
References: <mUBzfiyT7D6Y8R5SiO58zMil4n0NHGlGmth7x3pScWg=.3b426a30-099f-45bc-a51f-bc49658bb400@github.com>
Message-ID: <f76pnNWsWxENcSkiOHVupTFqssbM_IkH7FDinuhYhA8=.66a2ac24-7d4c-4667-963c-2455c3dd5d46@github.com>

On Thu, 25 Nov 2021 20:30:51 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this small refactoring to consistently use prefix `max_` for variable names where the variable represents a limit in G1CardSetConfiguration.
> 
> Thanks

This pull request has now been integrated.

Changeset: ad51d069
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ad51d0692534744d04a32959e7e50ee5e87adff5
Stats:     53 lines in 5 files changed: 0 ins; 2 del; 51 mod

8277789: G1: G1CardSetConfiguration prefixes num_ and max_ used interchangeably

Reviewed-by: mli, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6567


From shade at openjdk.java.net  Mon Nov 29 14:31:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Nov 2021 14:31:09 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
 <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
Message-ID: <2uy1V5LOa4NxChUSC3jJ7XHPmG2cOcDUShnE774alPA=.589d3dd4-0a3d-4ec3-b401-5366536ee247@github.com>

On Fri, 26 Nov 2021 09:42:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] specjvm -XX:+UseShenandoahGC
>>  - [x] tier1
>>  - [x] tier2
>>  - [x] tier3
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove verify_raw_mem()

Looks okay. Does it affect performance in any way?

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6526


From rkennke at openjdk.java.net  Mon Nov 29 14:41:12 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 29 Nov 2021 14:41:12 GMT
Subject: RFR: 8277654: Shenandoah: Don't produce new memory state in C2 LRB
 runtime call [v2]
In-Reply-To: <2uy1V5LOa4NxChUSC3jJ7XHPmG2cOcDUShnE774alPA=.589d3dd4-0a3d-4ec3-b401-5366536ee247@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
 <gz_kkLOydVABowx9nkvVBnFDYhcvzrDzWR4qPkTQV8A=.1b279d0c-c236-4e60-aff5-b8a1f6528e22@github.com>
 <2uy1V5LOa4NxChUSC3jJ7XHPmG2cOcDUShnE774alPA=.589d3dd4-0a3d-4ec3-b401-5366536ee247@github.com>
Message-ID: <BdHaTko-_ktvriT9ojNzLJRZdKLL7h8S2HTibgGmaCg=.cb54bcf9-20f8-42c3-9bd2-a52cba2c0f13@github.com>

On Mon, 29 Nov 2021 14:28:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks okay. Does it affect performance in any way?

I couldn't see any benefits or regressions in specjvm.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6526


From rkennke at openjdk.java.net  Mon Nov 29 16:03:11 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 29 Nov 2021 16:03:11 GMT
Subject: Integrated: 8277654: Shenandoah: Don't produce new memory state in C2
 LRB runtime call
In-Reply-To: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
References: <afJCc7SbilPbg5jShGV1M_aQDkpBXDbRC5SErNvCsc4=.309d4716-a8d0-423d-a50d-42724c461f25@github.com>
Message-ID: <tr--15bPZD9R1jxunipOy9brBMsVRFwwP_AFROHiL1U=.369e2174-7702-4d39-8f52-f6aa7ded0e40@github.com>

On Tue, 23 Nov 2021 16:20:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> The runtime call in expanded Shenandoah LRB doesn't need to produce (and consume) raw memory state. I believe this is a left-over from when the LRB (or WB) allocated from TLABs, and would mess with TLAB pointers, when not ordered correctly. (Also, we used to require ordering with RBs back when we had them, but we already removed that memory dependency on -8 offset)
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] specjvm -XX:+UseShenandoahGC
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3

This pull request has now been integrated.

Changeset: 3d39f09c
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d39f09c6cdc875b44147b4e84e496b6abf93996
Stats:     132 lines in 2 files changed: 0 ins; 127 del; 5 mod

8277654: Shenandoah: Don't produce new memory state in C2 LRB runtime call

Reviewed-by: roland, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/6526


From jiefu at openjdk.java.net  Mon Nov 29 23:20:09 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 29 Nov 2021 23:20:09 GMT
Subject: RFR: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <8unjBMzRPNdBaKNyxlsxGg0iywu3w3ITXApatJlmIR4=.dc246ad2-17c8-4847-89bc-a3428d1a61e8@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
 <8unjBMzRPNdBaKNyxlsxGg0iywu3w3ITXApatJlmIR4=.dc246ad2-17c8-4847-89bc-a3428d1a61e8@github.com>
Message-ID: <EVYd1fFzvzH2vqquPl4sl_Io9Alqs-b5IlkOH2vvHoE=.61965da7-6812-4666-b5bf-90bcc958aa32@github.com>

On Fri, 26 Nov 2021 09:18:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
>> 
>> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
>> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
>> 
>> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186
>
> Thanks for spotting this - that slipped past our testing (we do not do much 32 bit testing).
> 
>>>  Does a CSR needed?
>>
>> Maybe not since no VM flags are added or removed and jdk18 hasn't been released yet.
>> But I'm not sure.
> 
> I will talk to the CSR team whether there needs to be an amendment to the CSR for 32 bit platforms. please do not integrate before this has been handled.

> @tschatzl this pull request will not be integrated until the [CSR](https://wiki.openjdk.java.net/display/csr/Main) request [JDK-8277891](https://bugs.openjdk.java.net/browse/JDK-8277891) for issue [JDK-8277854](https://bugs.openjdk.java.net/browse/JDK-8277854) has been approved.

The CSR had been approved.
So integrate it.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From jiefu at openjdk.java.net  Mon Nov 29 23:20:10 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 29 Nov 2021 23:20:10 GMT
Subject: Integrated: 8277854: The upper bound of GCCardSizeInBytes should be
 limited to 512 for 32-bit platforms
In-Reply-To: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
References: <kcpjkzf0Irp49xgWoJ-yl3Io1f9soNNlgK2ilCzYJQ0=.f424098b-c05d-4b94-b913-4deccfb5d186@github.com>
Message-ID: <QlHrmM0MoXwGZ-MOu69swFrLEwJG_kvuFixQE5Kz_yQ=.ac8c9801-b5eb-4c3d-9e0e-64fb09a7e9ff@github.com>

On Fri, 26 Nov 2021 06:29:45 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java crashes on linux/x86_32 with `-XX:GCCardSizeInBytes=1024`.
> 
> This is because if`-XX:GCCardSizeInBytes=1024` then `BOTConstants::N_words` [1] would be 256.
> Then the guarantee [2] always fails due to _bot->offset_array(start_card), which is a u_char value, never equals to 256.
> 
> So for 32-bit platforms, the upper bound of `GCCardSizeInBytes` should be limited to 512.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shared/blockOffsetTable.cpp#L45
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp#L186

This pull request has now been integrated.

Changeset: 3a4a94e5
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3a4a94e5a830c4e88ac12619b868f3d89aa416a5
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8277854: The upper bound of GCCardSizeInBytes should be limited to 512 for 32-bit platforms

Reviewed-by: tschatzl, mli

-------------

PR: https://git.openjdk.java.net/jdk/pull/6569


From mli at openjdk.java.net  Tue Nov 30 02:17:23 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 30 Nov 2021 02:17:23 GMT
Subject: RFR: 8276299: G1: Unify the wording buffer/node/element in
 G1SegmentedArrayXxx, G1CardSetXxx and related classes
Message-ID: <L01e_1Jaqll2kEXkD0sd8tvJ6uXFOjCx_z6ElX8SCPY=.0ec501cb-20c8-4007-b9eb-fe0b42f17736@github.com>

Currently, the words "buffer", "node" and "element" are used together in G1SegmentedArrayXxx, G1CardSetXxx and related classes in an inconsistent way, which is very unfavorable for understanding.

We should not confuse buffer and node together, and not confuse node and element together. The new wording should be based on something like the following rule:

segmented array (1) -- segment (N) -- slot (M)

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/6605/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6605&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276299
  Stats: 367 lines in 14 files changed: 2 ins; 0 del; 365 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6605.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6605/head:pull/6605

PR: https://git.openjdk.java.net/jdk/pull/6605


From kbarrett at openjdk.java.net  Tue Nov 30 06:45:02 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 06:45:02 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor [v2]
In-Reply-To: <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
 <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>
Message-ID: <mw5Ly9y8Vj5MAeX0gp3hRAZfEbi2J7xmyPKhYsSZ_uM=.e2f4e8c4-ef1d-4dbc-9cdf-3e666f8e3994@github.com>

On Mon, 29 Nov 2021 10:31:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change removing effectively dead code, and some general cleanup.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6555


From ayang at openjdk.java.net  Tue Nov 30 07:38:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 07:38:12 GMT
Subject: RFR: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor [v2]
In-Reply-To: <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
 <uawSGj7UisHzpyOMFccQWDz0hwmChuxpVvn4YssCsIM=.f48142a6-61fa-42f0-a126-62cb5be3e537@github.com>
Message-ID: <BbkelyDwy08FLs9XHkIWkoZIgU2xGTH7mp8KMNJetIU=.fa169308-5a08-4c7f-93b4-4df48b9352a3@github.com>

On Mon, 29 Nov 2021 10:31:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change removing effectively dead code, and some general cleanup.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6555


From ayang at openjdk.java.net  Tue Nov 30 07:38:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 07:38:12 GMT
Subject: RFR: 8277931: Parallel: Remove unused PSVirtualSpace::expand_into
In-Reply-To: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>
References: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>
Message-ID: <hNNDuy3cdgaBkuWyPhDaGhnEvxI5oL6I6TtesUq4Pj8=.96d8c414-c2fc-423a-82ab-0e0e7ed4381c@github.com>

On Mon, 29 Nov 2021 12:37:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6593


From ayang at openjdk.java.net  Tue Nov 30 07:38:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 07:38:13 GMT
Subject: Integrated: 8277824: Remove empty RefProcSubPhasesWorkerTimeTracker
 destructor
In-Reply-To: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
References: <OrWH8Fx7WUTHWg1921nJGxFbj-UFd32g1wR-69XVg-8=.e18a376c-2209-4051-afd4-798f8b1dc2ca@github.com>
Message-ID: <LsDya78lqkutalTeL-g7Ffu5NuMBned3Rjem-q_e334=.da6af112-bd8f-4fb7-b727-1cd5bb2a27ca@github.com>

On Thu, 25 Nov 2021 09:29:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change removing effectively dead code, and some general cleanup.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: fde6fe79
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fde6fe7997a889b17af89b3a8fd25456568a1fa6
Stats:     9 lines in 2 files changed: 1 ins; 4 del; 4 mod

8277824: Remove empty RefProcSubPhasesWorkerTimeTracker destructor

Co-authored-by: Kim Barrett <kbarrett at openjdk.org>
Reviewed-by: tschatzl, kbarrett

-------------

PR: https://git.openjdk.java.net/jdk/pull/6555


From ayang at openjdk.java.net  Tue Nov 30 07:38:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 07:38:13 GMT
Subject: Integrated: 8277931: Parallel: Remove unused
 PSVirtualSpace::expand_into
In-Reply-To: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>
References: <AbDxxJFIIEbzi-qQ34pSq6XFEdWVnnzNmaMam9NbKzM=.f6011c15-8832-4621-9384-30c219d91059@github.com>
Message-ID: <XQ5SRDS_iL1HltZIzprHH-ehq1ThKIrp2oKSKGhxwVQ=.5efbd7a3-b6c9-4eb1-ae78-4a27fd879b2c@github.com>

On Mon, 29 Nov 2021 12:37:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: d230feea
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d230feea55379618a875566b9f9e3b01deb70795
Stats:     62 lines in 2 files changed: 0 ins; 62 del; 0 mod

8277931: Parallel: Remove unused PSVirtualSpace::expand_into

Reviewed-by: tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6593


From tschatzl at openjdk.java.net  Tue Nov 30 08:36:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 30 Nov 2021 08:36:05 GMT
Subject: RFR: 8277807: Increase default initial concurrent refinement
 threshold [v2]
In-Reply-To: <8DQHFkgfflb6n1kHxNRuKnjdjtk2ATkeCqCnWfZszLw=.27404d20-5ee0-486f-9a31-899b466e74e4@github.com>
References: <QRADGyYH849nRuOyjCnj47SW3k5Z0HdyNAnyfiIAGio=.179d7023-1e88-425b-b88d-212ba7fb1e4d@github.com>
 <8DQHFkgfflb6n1kHxNRuKnjdjtk2ATkeCqCnWfZszLw=.27404d20-5ee0-486f-9a31-899b466e74e4@github.com>
Message-ID: <Ti0xUxvCgM1hHlKeTJ03VygJmnJtgALxPmjg52lc2wU=.dc0ebad2-8665-4f2b-997a-2fbff6939fe1@github.com>

On Thu, 25 Nov 2021 04:32:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the default initial concurrent refinement
>> threshold.  The new value takes into account options that should provide a
>> starting point that is closer to the long-term range.
>> 
>> Testing:
>> mach5 tier1
>> manually verified logged initial value matched expectations.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Lgtm.

src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 258:

> 256:     // rate_1 is a relatively conservative guess at the rate for pause-time
> 257:     // card refinement by one thread.
> 258:     const double rate_1 = 200.0; // cards/ms/thread

I would prefer if this magic number were placed somewhere more standing out than in some static method in a cpp file. I thought at least put it into the .hpp file as part of the `G1ConcurrentRefine" class. However there are no guidelines for that for g1 code where or how to collect these magic constants I'm kind of good with that too.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6549


From tschatzl at openjdk.java.net  Tue Nov 30 08:52:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 30 Nov 2021 08:52:02 GMT
Subject: RFR: 8277866: gc/epsilon/TestMemoryMXBeans.java failed with wrong
 initial heap size
In-Reply-To: <PIWg71Tn_415RtJdk1EdjN-ygQ8cDZYFHsZ_fh1SHwU=.90412842-c964-41aa-86aa-2be55dd4db50@github.com>
References: <PIWg71Tn_415RtJdk1EdjN-ygQ8cDZYFHsZ_fh1SHwU=.90412842-c964-41aa-86aa-2be55dd4db50@github.com>
Message-ID: <jIAFjD5p6SYRVDLFG28ghnMhIzIQ7VFqBf24VgTqjEg=.67e8c060-980a-4bb7-972f-ccbe3c85c9fa@github.com>

On Fri, 26 Nov 2021 11:47:54 GMT, Takuya Kiriyama <duke at openjdk.java.net> wrote:

> I would like to fix the bug reported in JDK-8277866.  
> There is a typo in test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java as suggested in the issue.  
> The second test case is expected to run with -Xms in addition to -Xmx option. However, -Xmx option appears twice in the test.  
> This typo causes a failure of the test, and after fixing this typo, the test successfully passed.  
> Although ProblemList contains TestMemoryMXBeans.java, this typo should be fixed.

Lgtm. Thanks for spotting this.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6574


From shade at openjdk.java.net  Tue Nov 30 09:47:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 09:47:12 GMT
Subject: RFR: 8277866: gc/epsilon/TestMemoryMXBeans.java failed with wrong
 initial heap size
In-Reply-To: <PIWg71Tn_415RtJdk1EdjN-ygQ8cDZYFHsZ_fh1SHwU=.90412842-c964-41aa-86aa-2be55dd4db50@github.com>
References: <PIWg71Tn_415RtJdk1EdjN-ygQ8cDZYFHsZ_fh1SHwU=.90412842-c964-41aa-86aa-2be55dd4db50@github.com>
Message-ID: <oHKZAX7mMJH2swN3_LO6ysXdfr0ftp2zySOLNiiulcM=.b920e0a0-fe63-4abc-a617-6611b2bf145b@github.com>

On Fri, 26 Nov 2021 11:47:54 GMT, Takuya Kiriyama <duke at openjdk.java.net> wrote:

> I would like to fix the bug reported in JDK-8277866.  
> There is a typo in test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java as suggested in the issue.  
> The second test case is expected to run with -Xms in addition to -Xmx option. However, -Xmx option appears twice in the test.  
> This typo causes a failure of the test, and after fixing this typo, the test successfully passed.  
> Although ProblemList contains TestMemoryMXBeans.java, this typo should be fixed.

Yes, that's a correct fix. Thanks!

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6574


From ayang at openjdk.java.net  Tue Nov 30 10:02:04 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 10:02:04 GMT
Subject: RFR: 8277736: G1: Allow forced evacuation failure of first N
 regions in collection set
In-Reply-To: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
References: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
Message-ID: <jIe0cohpIxSV42zKhuPYXqy324sarIfqcaR7LxbZT1s=.b3439a05-f17f-4bb2-a774-e79635d4cbe0@github.com>

On Thu, 25 Nov 2021 12:54:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, debug options of evacuation failure, like G1EvacuationFailureALotInterval and G1EvacuationFailureALotCount only config the ratio of objects failing evacuation, basically the distribution of objects failing evacuation is even among regions.
> 
> JDK-8256265 is trying to improve parallelism in regions that failed evacuation, it'll be helpful if there is option to config the distribution of objects failing evacuation among regions, so implementation of JDK-8256265 could be profiled more precisely.
> 
> This is to add the support and necessary vm options, and the implementation will be to select regions from start, i.e. not randomly, the motivation is to configure a more stable selection of evacuation failure regions, which will help verify the effect of JDK-8256265 implementation.

Just some minor comments/suggestions.

src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.hpp line 61:

> 59: 
> 60:   // Records the regions that will fail evacuation.
> 61:   CHeapBitMap _regions;

How about calling this field `_evac_fail_regions`?

src/hotspot/share/gc/g1/g1_globals.hpp line 78:

> 76:           "evacuation pauses")                                              \
> 77:                                                                             \
> 78:   product(uintx, G1EvacuationFailureALotCSetPercent, 100,                   \

Why `uintx`? Does `uint` work?

-------------

Marked as reviewed by ayang (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6561


From ayang at openjdk.java.net  Tue Nov 30 10:02:05 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 10:02:05 GMT
Subject: RFR: 8277736: G1: Allow forced evacuation failure of first N
 regions in collection set
In-Reply-To: <rjQSZ2zn8E5MOqiVKdZa419tb7q2mPeeznCrn4NtYR0=.27100d70-a232-483e-9e42-c1adc83e01ab@github.com>
References: <IEmnwRJdl9VmYQ3s0ErbJ3D7cdqCD8L4oS5XI7_Cvkk=.9fe5688c-d1f9-47dc-9918-e5c382630c75@github.com>
 <i7eqM81MoHcyCbFM4rTnRC9GOEzEexzlzTqJc5b_ahs=.2d2d6086-e963-4dbe-a226-1225c40262df@github.com>
 <rjQSZ2zn8E5MOqiVKdZa419tb7q2mPeeznCrn4NtYR0=.27100d70-a232-483e-9e42-c1adc83e01ab@github.com>
Message-ID: <QCcDduAjWhKq8cVqgPWxwR4yO38y-MX5TT-FjRNKnFs=.de485f98-0256-4f1d-b336-30cdbc745bd9@github.com>

On Fri, 26 Nov 2021 02:34:41 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.cpp line 47:
>> 
>>> 45:       _regions.set_bit(r->hrm_index());
>>> 46:       --_evac_failure_regions_num;
>>> 47:       return false;
>> 
>> Just an initial comment to think about and discuss: This would most likely always ever select the same regions (probably eden) that are first in the collection set.
>> I think selecting by probability (with G1EvacuationFailureALotCSetPercent uniform probability) would be more interesting even if it makes the selection more random.
>
> Yes, currently I only make it select regions starting from first.
> The reason I don't add random selection is that, currently we need this functionality to verify the functionality and perf improvement of JDK-8256265 implementation, so a more stable selection of evacuation failure regions will help to verify the effect of JDK-8256265.
> 
> I agree that random selection is an interesting option to supply too, I just file https://bugs.openjdk.java.net/browse/JDK-8277851 to track the issue.

This PR makes the first X% regions in cset evac-fail, but `G1EvacuationFailureALotCSetPercent` doesn't show such bias. (It kind of implies uniform distribution, IMO.) It would be nice if the name and/or the explanation string could be more specific.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6561


From ayang at openjdk.java.net  Tue Nov 30 10:16:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 10:16:14 GMT
Subject: RFR: 8151594: Move concurrent refinement thread activation logging
 out of GC pause
In-Reply-To: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
References: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
Message-ID: <PRfJ6d47qTS9GKfyJbHE-tinQSaI_uQNP0kg11OAQPE=.a8d05476-af86-4c8b-9c45-86ea5a569bf3@github.com>

On Thu, 25 Nov 2021 05:56:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this move of the thread activation logging by concurrent
> refinment threads to be within the suspendible thread set context, rather
> than before it.  This prevents the logging for the thread activation
> sometimes being intermixed with GC pause-time logging.
> 
> Testing:
> mach5 tier1

Marked as reviewed by ayang (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6551


From sjohanss at openjdk.java.net  Tue Nov 30 10:30:12 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 10:30:12 GMT
Subject: RFR: 8277807: Increase default initial concurrent refinement
 threshold [v2]
In-Reply-To: <Ti0xUxvCgM1hHlKeTJ03VygJmnJtgALxPmjg52lc2wU=.dc0ebad2-8665-4f2b-997a-2fbff6939fe1@github.com>
References: <QRADGyYH849nRuOyjCnj47SW3k5Z0HdyNAnyfiIAGio=.179d7023-1e88-425b-b88d-212ba7fb1e4d@github.com>
 <8DQHFkgfflb6n1kHxNRuKnjdjtk2ATkeCqCnWfZszLw=.27404d20-5ee0-486f-9a31-899b466e74e4@github.com>
 <Ti0xUxvCgM1hHlKeTJ03VygJmnJtgALxPmjg52lc2wU=.dc0ebad2-8665-4f2b-997a-2fbff6939fe1@github.com>
Message-ID: <FhcrdXt7YroaCHUrSZq1ArvMXWb4BCBySuAY3H6NDOk=.08df2725-20e8-40c2-ab49-5782af7c6dcc@github.com>

On Tue, 30 Nov 2021 08:32:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyright
>
> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 258:
> 
>> 256:     // rate_1 is a relatively conservative guess at the rate for pause-time
>> 257:     // card refinement by one thread.
>> 258:     const double rate_1 = 200.0; // cards/ms/thread
> 
> I would prefer if this magic number were placed somewhere more standing out than in some static method in a cpp file. I thought at least put it into the .hpp file as part of the `G1ConcurrentRefine" class. However there are no guidelines for that for g1 code where or how to collect these magic constants I'm kind of good with that too.

I agree with Thomas. I think this should live in `G1ConcurrentRefine`, but if you don't agree I'm ok with leaving as is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6549


From sjohanss at openjdk.java.net  Tue Nov 30 10:30:11 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 10:30:11 GMT
Subject: RFR: 8277807: Increase default initial concurrent refinement
 threshold [v2]
In-Reply-To: <8DQHFkgfflb6n1kHxNRuKnjdjtk2ATkeCqCnWfZszLw=.27404d20-5ee0-486f-9a31-899b466e74e4@github.com>
References: <QRADGyYH849nRuOyjCnj47SW3k5Z0HdyNAnyfiIAGio=.179d7023-1e88-425b-b88d-212ba7fb1e4d@github.com>
 <8DQHFkgfflb6n1kHxNRuKnjdjtk2ATkeCqCnWfZszLw=.27404d20-5ee0-486f-9a31-899b466e74e4@github.com>
Message-ID: <ZvwlWftulUoKT02bZ77ks-DN4SViVVjYQs8DOATNxcY=.92bdf037-35c6-4ee9-86f9-2cb9239c5732@github.com>

On Thu, 25 Nov 2021 04:32:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the default initial concurrent refinement
>> threshold.  The new value takes into account options that should provide a
>> starting point that is closer to the long-term range.
>> 
>> Testing:
>> mach5 tier1
>> manually verified logged initial value matched expectations.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright

Marked as reviewed by sjohanss (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6549


From sjohanss at openjdk.java.net  Tue Nov 30 10:32:06 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 10:32:06 GMT
Subject: RFR: 8277899: Parallel: Simplify PSVirtualSpace::initialize logic
In-Reply-To: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
References: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
Message-ID: <eIUIleuEczQSiJHJGFqEGug5KtJFePChjB54Gft4rmA=.f2f24a8f-99ee-43e2-99e2-e87d47b25638@github.com>

On Mon, 29 Nov 2021 09:52:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of baking the static arg into `PSVirtualSpace::initialize`.
> 
> Test: hotspot_gc

Nice cleanup, looks good.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6586


From sjohanss at openjdk.java.net  Tue Nov 30 11:20:12 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 11:20:12 GMT
Subject: RFR: 8277814: ConcurrentRefineThread should report rate when
 deactivating
In-Reply-To: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
References: <2eC2NuQOXmGRHwCja-EtgsXY4v--melTp3xOushoNo4=.88abd0fd-9636-4266-8f23-eefd51b1c335@github.com>
Message-ID: <EEu64mvXGm8V81ATckF189e4qpNkgH-xeIr68-THSW0=.e31febc3-7bd5-40a9-b984-98f59a7dfe53@github.com>

On Thu, 25 Nov 2021 04:24:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the logging by concurrent refinement threads.
> This change adds the cards processed per ms to the deactivation log message.
> 
> Testing:
> mach5 tier1
> locally ran a test with gc+refine=debug logging enabled and verified the
> expected change to the deactivation log message.

Looks good.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6550


From sjohanss at openjdk.java.net  Tue Nov 30 12:15:27 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 12:15:27 GMT
Subject: RFR: 8277757: Parallelize humongous reclaim
Message-ID: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>

Please review this change to use parallel threads for humongous reclaim.

**Summary**
The task doing humongous reclaim is part of "Post Evacuate Cleanup 2", but currently it is executed like a serial task. In many cases this is not a problem, but if the humongous reclaim is the only part in cleanup 2 that has substantial work, it would benefit from using multiple threads. There is no technical problem with this and this change simply enables multiple threads to do the work in parallel. 

**Testing**
- [x] Mach5 tier 1-3
- [x] Local testing verifying JFR tests are unaffected
- [x] Performance testing checking for regressions

-------------

Commit messages:
 - 8277757: Parallelize humongous reclaim

Changes: https://git.openjdk.java.net/jdk/pull/6612/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6612&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277757
  Stats: 27 lines in 2 files changed: 13 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6612.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6612/head:pull/6612

PR: https://git.openjdk.java.net/jdk/pull/6612


From shade at openjdk.java.net  Tue Nov 30 12:38:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 12:38:27 GMT
Subject: RFR: 8277981: String Deduplication table is never cleaned up due to
 bad dead_factor_for_cleanup
Message-ID: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>

See the reproducer and analysis in the bug. 

The root cause for this problem is that `percent_of` returns `0..100` (percent) value of `nominator / denominator`. Which means if we feed `percent` and `100` there, this is an identity operation, returning the same value. And we wanted the conversion from percent to factor instead.

Additional testing:
 - [x] Reproducer stress test does not leak anymore
 - [ ] Linux x86_64 fastdebug tier1

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/6613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6613&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277981
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6613/head:pull/6613

PR: https://git.openjdk.java.net/jdk/pull/6613


From tschatzl at openjdk.java.net  Tue Nov 30 12:51:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 30 Nov 2021 12:51:10 GMT
Subject: RFR: 8277757: Parallelize humongous reclaim
In-Reply-To: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>
References: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>
Message-ID: <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>

On Tue, 30 Nov 2021 12:06:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to use parallel threads for humongous reclaim.
> 
> **Summary**
> The task doing humongous reclaim is part of "Post Evacuate Cleanup 2", but currently it is executed like a serial task. In many cases this is not a problem, but if the humongous reclaim is the only part in cleanup 2 that has substantial work, it would benefit from using multiple threads. There is no technical problem with this and this change simply enables multiple threads to do the work in parallel. 
> 
> **Testing**
> - [x] Mach5 tier 1-3
> - [x] Local testing verifying JFR tests are unaffected
> - [x] Performance testing checking for regressions

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 290:

> 288:   }
> 289: 
> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }

Would it be possible to pack `_humongous_reclaim_candidates` into `should_execute()`? Without candidates, there should be no need to even try this phase. There needs to be some adjustment with the log messages though.

Then `worker_cost` also does not need the `MAX2` then.

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 292:

> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }
> 291: 
> 292:   double worker_cost() const override { return MAX2(1u, _humongous_reclaim_candidates); }

I think equating the number of threads with the number of reclaim candidates is too big a number; there is relatively little work to do per region; I would probably use some (magic) divisor based on the number of regions to look through instead, but I guess you measured that; then again, other parts of `Post Evacuate Cleanup 2` effectively already always spawn the maximum number of threads anyway?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6612


From sjohanss at openjdk.java.net  Tue Nov 30 13:05:11 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 13:05:11 GMT
Subject: RFR: 8277757: Parallelize humongous reclaim
In-Reply-To: <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>
References: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>
 <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>
Message-ID: <PL7oRl326hgOHcZPh1jLbXMhpZ4YySEQ1G4n_oBSBMw=.6195ac8c-6d5a-45c5-8fa5-ac28fd790053@github.com>

On Tue, 30 Nov 2021 12:40:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change to use parallel threads for humongous reclaim.
>> 
>> **Summary**
>> The task doing humongous reclaim is part of "Post Evacuate Cleanup 2", but currently it is executed like a serial task. In many cases this is not a problem, but if the humongous reclaim is the only part in cleanup 2 that has substantial work, it would benefit from using multiple threads. There is no technical problem with this and this change simply enables multiple threads to do the work in parallel. 
>> 
>> **Testing**
>> - [x] Mach5 tier 1-3
>> - [x] Local testing verifying JFR tests are unaffected
>> - [x] Performance testing checking for regressions
>
> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 290:
> 
>> 288:   }
>> 289: 
>> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }
> 
> Would it be possible to pack `_humongous_reclaim_candidates` into `should_execute()`? Without candidates, there should be no need to even try this phase. There needs to be some adjustment with the log messages though.
> 
> Then `worker_cost` also does not need the `MAX2` then.

I was thinking the same, but it looks like we want to execute this phase for logging purposes as well: 

bool G1CollectedHeap::should_do_eager_reclaim() const {
  // As eager reclaim logging also gives information about humongous objects in
  // the heap in general, always do the eager reclaim pass even without known
  // candidates.
  return (G1EagerReclaimHumongousObjects &&
          (has_humongous_reclaim_candidates() || do_humongous_object_logging()));
}

So if `gc+humongous=debug` we will also execute this task.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6612


From sjohanss at openjdk.java.net  Tue Nov 30 13:15:23 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 13:15:23 GMT
Subject: RFR: 8277757: Parallelize humongous reclaim
In-Reply-To: <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>
References: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>
 <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>
Message-ID: <6Rp2iPrXmLXktk3o3rOCyZu568yCtpmhIEsHXyfHmRg=.dc050169-d5ff-4727-ac30-b164bf2decae@github.com>

On Tue, 30 Nov 2021 12:47:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change to use parallel threads for humongous reclaim.
>> 
>> **Summary**
>> The task doing humongous reclaim is part of "Post Evacuate Cleanup 2", but currently it is executed like a serial task. In many cases this is not a problem, but if the humongous reclaim is the only part in cleanup 2 that has substantial work, it would benefit from using multiple threads. There is no technical problem with this and this change simply enables multiple threads to do the work in parallel. 
>> 
>> **Testing**
>> - [x] Mach5 tier 1-3
>> - [x] Local testing verifying JFR tests are unaffected
>> - [x] Performance testing checking for regressions
>
> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 292:
> 
>> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }
>> 291: 
>> 292:   double worker_cost() const override { return MAX2(1u, _humongous_reclaim_candidates); }
> 
> I think equating the number of threads with the number of reclaim candidates is too big a number; there is relatively little work to do per region; I would probably use some (magic) divisor based on the number of regions to look through instead, but I guess you measured that; then again, other parts of `Post Evacuate Cleanup 2` effectively already always spawn the maximum number of threads anyway?

Again, I have had thoughts along the same lines :) But since we, as you say, already spawn the max number of threads, letting them all help out seems ok. 

At least the number of candidates is always lower or equal to the number of regions being taken care of.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6612


From zgu at openjdk.java.net  Tue Nov 30 13:42:14 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 30 Nov 2021 13:42:14 GMT
Subject: RFR: 8277981: String Deduplication table is never cleaned up due
 to bad dead_factor_for_cleanup
In-Reply-To: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
References: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
Message-ID: <7DEWMXGrtXB-Lv6tjFC4YQb_Yl1F4J24-eUgXGOuVPg=.412edb7c-ec9c-4c0c-9aec-6ffef1f3d116@github.com>

On Tue, 30 Nov 2021 12:30:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the reproducer and analysis in the bug. 
> 
> The root cause for this problem is that `percent_of` returns `0..100` (percent) value of `nominator / denominator`. Which means if we feed `percent` and `100` there, this is an identity operation, returning the same value. And we wanted the conversion from percent to factor instead.
> 
> The default value for `StringDeduplicationCleanupDeadPercent` is `5`, which means (assuming `dead_count <= entry_count`) this erroneous conversion makes this condition always `false`:
> 
> 
> bool StringDedup::Config::should_cleanup_table(size_t entry_count, size_t dead_count) {
>   return (dead_count > _minimum_dead_for_cleanup) &&
>          (dead_count > (entry_count * _dead_factor_for_cleanup));
> }
> 
> 
> Additional testing:
>  - [x] Reproducer stress test does not leak anymore
>  - [x] Linux x86_64 fastdebug tier1, `-XX:+UseStringDeduplication`
>  - [ ] Linux x86_64 fastdebug tier2, `-XX:+UseStringDeduplication`

Looks good

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6613


From ayang at openjdk.java.net  Tue Nov 30 13:48:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 13:48:12 GMT
Subject: RFR: 8277899: Parallel: Simplify PSVirtualSpace::initialize logic
In-Reply-To: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
References: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
Message-ID: <PjAvBUmvmiIup5kPOs44BU9EES28QG8TonzYREKBJmc=.014db48f-3515-4d54-a579-3970b45851a5@github.com>

On Mon, 29 Nov 2021 09:52:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of baking the static arg into `PSVirtualSpace::initialize`.
> 
> Test: hotspot_gc

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6586


From ayang at openjdk.java.net  Tue Nov 30 13:48:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 30 Nov 2021 13:48:13 GMT
Subject: Integrated: 8277899: Parallel: Simplify PSVirtualSpace::initialize
 logic
In-Reply-To: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
References: <madUXxpMha5ESPHc1MWrgDaErYK4zNQ9c-xM0yB8m8M=.a932e51e-a715-4056-bdbd-b7dd08a3cde1@github.com>
Message-ID: <L-5sELiAGVRSWWGBQnCF5_M2iN47rBXqkfXzo39zmgY=.5bfc0b3d-d684-4940-a3b3-1ee528d23324@github.com>

On Mon, 29 Nov 2021 09:52:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of baking the static arg into `PSVirtualSpace::initialize`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 91508404
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/915084041f32bf6ffe4d12c031ac5e69adcc07f5
Stats:     11 lines in 3 files changed: 0 ins; 8 del; 3 mod

8277899: Parallel: Simplify PSVirtualSpace::initialize logic

Reviewed-by: tschatzl, sjohanss

-------------

PR: https://git.openjdk.java.net/jdk/pull/6586


From tschatzl at openjdk.java.net  Tue Nov 30 14:15:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 30 Nov 2021 14:15:08 GMT
Subject: RFR: 8277757: Parallelize humongous reclaim
In-Reply-To: <6Rp2iPrXmLXktk3o3rOCyZu568yCtpmhIEsHXyfHmRg=.dc050169-d5ff-4727-ac30-b164bf2decae@github.com>
References: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>
 <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>
 <6Rp2iPrXmLXktk3o3rOCyZu568yCtpmhIEsHXyfHmRg=.dc050169-d5ff-4727-ac30-b164bf2decae@github.com>
Message-ID: <uuc9iSu-ZKyTyljfiU3k02EZCjI0nOjZjM0eiK_evPk=.e4d4cd92-1b94-4119-8cf3-fd7a7fd424ba@github.com>

On Tue, 30 Nov 2021 13:12:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 292:
>> 
>>> 290:   static bool should_execute() { return G1CollectedHeap::heap()->should_do_eager_reclaim(); }
>>> 291: 
>>> 292:   double worker_cost() const override { return MAX2(1u, _humongous_reclaim_candidates); }
>> 
>> I think equating the number of threads with the number of reclaim candidates is too big a number; there is relatively little work to do per region; I would probably use some (magic) divisor based on the number of regions to look through instead, but I guess you measured that; then again, other parts of `Post Evacuate Cleanup 2` effectively already always spawn the maximum number of threads anyway?
>
> Again, I have had thoughts along the same lines :) But since we, as you say, already spawn the max number of threads, letting them all help out seems ok. 
> 
> At least the number of candidates is always lower or equal to the number of regions being taken care of.

I still prefer to scale the number of threads to the (largest) actual work, which is as we seem to agree on actually iterating through the regions, for that particular phase rather than relying on other phases getting things right or this phase "helping" other phases - or at least try to. Otherwise we could probably just always use a maximum amount of threads available in the hope that they'll help out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6612


From lkorinth at openjdk.java.net  Tue Nov 30 15:04:44 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 30 Nov 2021 15:04:44 GMT
Subject: RFR: 8277985: G1: Compare max_parallel_refinement_threads to UINT_MAX
Message-ID: <z1O9t8T1vyF3cCWpInECwyaX9OQTQsMaSoC5rhepSpE=.d0748f12-be0d-49ce-b602-c6173a61f367@github.com>

The max_parallel_refinement_threads comparison will never be larger than UINTPTR_MAX / divisor on platforms where pointers are larger than unsigned,   Use the intended UINT_MAX instead.

-------------

Commit messages:
 - 8277985: G1: Compare max_parallel_refinement_threads to UINT_MAX

Changes: https://git.openjdk.java.net/jdk/pull/6617/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6617&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8277985
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6617.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6617/head:pull/6617

PR: https://git.openjdk.java.net/jdk/pull/6617


From kbarrett at openjdk.java.net  Tue Nov 30 15:11:14 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 15:11:14 GMT
Subject: RFR: 8277981: String Deduplication table is never cleaned up due
 to bad dead_factor_for_cleanup
In-Reply-To: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
References: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
Message-ID: <1Ir-_3szAOYmrQHR04nzq_df0HXy1pTPK2kR7rAsT7I=.827d456a-bc57-439e-969c-56dd60da8646@github.com>

On Tue, 30 Nov 2021 12:30:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the reproducer and analysis in the bug. 
> 
> The root cause for this problem is that `percent_of` returns `0..100` (percent) value of `nominator / denominator`. Which means if we feed `percent` and `100` there, this is an identity operation, returning the same value. And we wanted the conversion from percent to factor instead.
> 
> The default value for `StringDeduplicationCleanupDeadPercent` is `5`, which means (assuming `dead_count <= entry_count`) this erroneous conversion makes this condition always `false`:
> 
> 
> bool StringDedup::Config::should_cleanup_table(size_t entry_count, size_t dead_count) {
>   return (dead_count > _minimum_dead_for_cleanup) &&
>          (dead_count > (entry_count * _dead_factor_for_cleanup));
> }
> 
> 
> Additional testing:
>  - [x] Reproducer stress test does not leak anymore
>  - [x] Linux x86_64 fastdebug tier1, `-XX:+UseStringDeduplication`
>  - [x] Linux x86_64 fastdebug tier2, `-XX:+UseStringDeduplication`
>  - [x] Linux x86_64 fastdebug tier3, `-XX:+UseStringDeduplication`

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6613


From tschatzl at openjdk.java.net  Tue Nov 30 15:39:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 30 Nov 2021 15:39:09 GMT
Subject: RFR: 8277981: String Deduplication table is never cleaned up due
 to bad dead_factor_for_cleanup
In-Reply-To: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
References: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
Message-ID: <4CshCcssjGhDVagoi1wf16pmk8hVXLoMnRsY8H69ay0=.52de842d-e5b5-4c12-9e2a-0194c7fda220@github.com>

On Tue, 30 Nov 2021 12:30:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the reproducer and analysis in the bug. 
> 
> The root cause for this problem is that `percent_of` returns `0..100` (percent) value of `nominator / denominator`. Which means if we feed `percent` and `100` there, this is an identity operation, returning the same value. And we wanted the conversion from percent to factor instead.
> 
> The default value for `StringDeduplicationCleanupDeadPercent` is `5`, which means (assuming `dead_count <= entry_count`) this erroneous conversion makes this condition always `false`:
> 
> 
> bool StringDedup::Config::should_cleanup_table(size_t entry_count, size_t dead_count) {
>   return (dead_count > _minimum_dead_for_cleanup) &&
>          (dead_count > (entry_count * _dead_factor_for_cleanup));
> }
> 
> 
> Additional testing:
>  - [x] Reproducer stress test does not leak anymore
>  - [x] Linux x86_64 fastdebug tier1, `-XX:+UseStringDeduplication`
>  - [x] Linux x86_64 fastdebug tier2, `-XX:+UseStringDeduplication`
>  - [x] Linux x86_64 fastdebug tier3, `-XX:+UseStringDeduplication`

Marked as reviewed by tschatzl (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6613


From kbarrett at openjdk.java.net  Tue Nov 30 15:41:11 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 15:41:11 GMT
Subject: RFR: 8277985: G1: Compare max_parallel_refinement_threads to
 UINT_MAX
In-Reply-To: <z1O9t8T1vyF3cCWpInECwyaX9OQTQsMaSoC5rhepSpE=.d0748f12-be0d-49ce-b602-c6173a61f367@github.com>
References: <z1O9t8T1vyF3cCWpInECwyaX9OQTQsMaSoC5rhepSpE=.d0748f12-be0d-49ce-b602-c6173a61f367@github.com>
Message-ID: <1OpjgRm_MWAdB8JYI1wnFVHd7SiIQNwYZs0GtSXHDMQ=.6b3d26da-08cf-4ce2-a00e-13f0dda729d7@github.com>

On Tue, 30 Nov 2021 14:56:02 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The max_parallel_refinement_threads comparison will never be larger than UINTPTR_MAX / divisor on platforms where pointers are larger than unsigned,   Use the intended UINT_MAX instead.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6617


From tschatzl at openjdk.java.net  Tue Nov 30 15:46:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 30 Nov 2021 15:46:05 GMT
Subject: RFR: 8277985: G1: Compare max_parallel_refinement_threads to
 UINT_MAX
In-Reply-To: <z1O9t8T1vyF3cCWpInECwyaX9OQTQsMaSoC5rhepSpE=.d0748f12-be0d-49ce-b602-c6173a61f367@github.com>
References: <z1O9t8T1vyF3cCWpInECwyaX9OQTQsMaSoC5rhepSpE=.d0748f12-be0d-49ce-b602-c6173a61f367@github.com>
Message-ID: <3KdfbicVENxi9xN2UxKx48LmLMoXcQHasJ_0_xyYMcM=.56986f8f-ab96-4235-821e-5b6e33619338@github.com>

On Tue, 30 Nov 2021 14:56:02 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The max_parallel_refinement_threads comparison will never be larger than UINTPTR_MAX / divisor on platforms where pointers are larger than unsigned,   Use the intended UINT_MAX instead.

Lgtm.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6617


From shade at openjdk.java.net  Tue Nov 30 16:52:04 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 30 Nov 2021 16:52:04 GMT
Subject: RFR: 8277981: String Deduplication table is never cleaned up due
 to bad dead_factor_for_cleanup
In-Reply-To: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
References: <YcCitRc2BHLg2sb1wbUIM1n6Mbs2PblPXVqXQEPwf5U=.da6b2dd3-3eec-4607-bf76-1f65a27542dc@github.com>
Message-ID: <HKKpHvSs8a9hFSmB-BTYE2XFUZXzj2LXRDQLf-ttb5c=.dc135980-e555-4468-b0fc-3ba59809fe48@github.com>

On Tue, 30 Nov 2021 12:30:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the reproducer and analysis in the bug. 
> 
> The root cause for this problem is that `percent_of` returns `0..100` (percent) value of `nominator / denominator`. Which means if we feed `percent` and `100` there, this is an identity operation, returning the same value. And we wanted the conversion from percent to factor instead.
> 
> The default value for `StringDeduplicationCleanupDeadPercent` is `5`, which means (assuming `dead_count <= entry_count`) this erroneous conversion makes this condition always `false`:
> 
> 
> bool StringDedup::Config::should_cleanup_table(size_t entry_count, size_t dead_count) {
>   return (dead_count > _minimum_dead_for_cleanup) &&
>          (dead_count > (entry_count * _dead_factor_for_cleanup));
> }
> 
> 
> Additional testing:
>  - [x] Reproducer stress test does not leak anymore
>  - [x] Linux x86_64 fastdebug tier1, `-XX:+UseStringDeduplication`
>  - [x] Linux x86_64 fastdebug tier2, `-XX:+UseStringDeduplication`
>  - [x] Linux x86_64 fastdebug tier3, `-XX:+UseStringDeduplication`

Thanks for reviews. I'll wait out the 24 hours for Hotspot patches, and then push. Then I'll go plead to Rob about picking it up to 17.0.2.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6613


From kbarrett at openjdk.java.net  Tue Nov 30 20:13:02 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 20:13:02 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <gJ4QxyQI6xErEP2UPXmflaSGjfnmE1dglRbdZDYSQiI=.e108f5ee-27ba-459e-a06f-a2b5eaf1cf67@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
 <gJ4QxyQI6xErEP2UPXmflaSGjfnmE1dglRbdZDYSQiI=.e108f5ee-27ba-459e-a06f-a2b5eaf1cf67@github.com>
Message-ID: <Mm7wNr-_Oowl8CTsW-Vrb1xoivSHb0YSMU31kY71A-0=.55d52d06-52a4-4347-97a2-94256610835f@github.com>

On Mon, 29 Nov 2021 08:06:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review this change which fixes a rare assert failure in
>> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
>> referencing values from the forwardee, and that isn't safe. When an object is
>> copied and forwarded to the copy, the forwarding is performed with a relaxed
>> cmpxchg. This means the data being copied into the forwardee might not be
>> visible to a different thread that has obtained the forwardee. All uses of a
>> forwardee must take care to avoid reading from it without performing
>> additional synchronization. The assert in question violates that restriction.
>> 
>> The incorrect assertion is
>> 
>> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
>> 
>> obj is the forwardee of a different object.
>> 
>> It's okay here to examine the contents of obj when it's in the cset.  In
>> that case it's not a copy; it's the original object, self-forwarded due to
>> evacuation failure.
>> 
>> But it's not okay to examine the contents of obj when it's not in the cset,
>> e.g. when it's a forwardee copy of the original object.  Doing so violates
>> the above restriction.
>> 
>> So that tells us this code is wrong, but it's still not obvious this is the
>> cause of the failure in question.  The failure we're seeing appears to be
>> that obj->is_forwarded() returns true, but the assert of the same thing in
>> forwardee returns false.  But is_forwarded() should never be true for a
>> copied forwardee.  But it turns out a copied forwardee might temporarily
>> appear to be forwarded, due to the unordered copy + forward sequence.
>> Consider the following scenario:
>> 
>> A thread is evacuating an object and allocates a candidate forwardee, copies
>> into it, and finally discovers the forwarding race was lost even before the
>> copy.  The candidate forwardee appears to be marked as forwarded.  That
>> candidate is deallocated and the real forwardee is used by the thread.
>> 
>> That same thread evacuates a second object, reallocating some of the same
>> memory as from the previous candidate.  It copies the second object into the
>> new forwardee, successfully performs the forwarding, and uses that newly
>> created forwardee.
>> 
>> A second thread attempts to evacuate that same second object, and finds it
>> already forwarded.  It goes into write_ref_field_post, reaches the assert,
>> and attempts to use values from the forwardee.  Because the copy and the
>> forwarding by the first thread were unordered, this second thread might see
>> the old copy that appears to be forwarded, rather than the up to date copy.
>> So the first call to is_forwarded() returns true.  The forwardee() assert of
>> the same thing might instead get the up to date contents, resulting in the
>> reported failure.  Alternatively, it might still get old data, in which case
>> nothing gets noticed because the self-forward check will fail and the
>> write_ref_field_post assert will (accidentally) succeed.
>> 
>> So there's a very small window in which the reported failure can occur.  But
>> it's all caused by the write_ref_field_post assert performing invalid
>> accesses.  Stop doing that and the problem should go away.
>> 
>> I think this failure couldn't have happened before JDK-8271579, but that's
>> kind of accidental and doesn't change that the write_ref_field_post assert
>> was performing invalid accesses.  (Those accesses were introduced later.)
>> 
>> Testing:
>> mach5 tier1-5.
>> 
>> Ran applications/jcstress/acqrel.java 100 times without failure.
>> Without the change I had a 25-30% failure rate for that test.
>> I don't know why that test was such a good canary, when this failure seems to
>> otherwise be pretty rare, but glad that it was.
>
> Thank you for the detailed analysis; this makes perfect sense.

Thanks for reviews @albertnetymk , @shipilev , and @tschatzl .

-------------

PR: https://git.openjdk.java.net/jdk/pull/6582


From kbarrett at openjdk.java.net  Tue Nov 30 20:26:44 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 20:26:44 GMT
Subject: RFR: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded" [v2]
In-Reply-To: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
Message-ID: <8paUUeV7aQsDteVJf8ausvwgUBpVWyGOF-cW-I08f78=.75530b40-9d77-4efd-bfd5-95d76c7c41d7@github.com>

> Please review this change which fixes a rare assert failure in
> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
> referencing values from the forwardee, and that isn't safe. When an object is
> copied and forwarded to the copy, the forwarding is performed with a relaxed
> cmpxchg. This means the data being copied into the forwardee might not be
> visible to a different thread that has obtained the forwardee. All uses of a
> forwardee must take care to avoid reading from it without performing
> additional synchronization. The assert in question violates that restriction.
> 
> The incorrect assertion is
> 
> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
> 
> obj is the forwardee of a different object.
> 
> It's okay here to examine the contents of obj when it's in the cset.  In
> that case it's not a copy; it's the original object, self-forwarded due to
> evacuation failure.
> 
> But it's not okay to examine the contents of obj when it's not in the cset,
> e.g. when it's a forwardee copy of the original object.  Doing so violates
> the above restriction.
> 
> So that tells us this code is wrong, but it's still not obvious this is the
> cause of the failure in question.  The failure we're seeing appears to be
> that obj->is_forwarded() returns true, but the assert of the same thing in
> forwardee returns false.  But is_forwarded() should never be true for a
> copied forwardee.  But it turns out a copied forwardee might temporarily
> appear to be forwarded, due to the unordered copy + forward sequence.
> Consider the following scenario:
> 
> A thread is evacuating an object and allocates a candidate forwardee, copies
> into it, and finally discovers the forwarding race was lost even before the
> copy.  The candidate forwardee appears to be marked as forwarded.  That
> candidate is deallocated and the real forwardee is used by the thread.
> 
> That same thread evacuates a second object, reallocating some of the same
> memory as from the previous candidate.  It copies the second object into the
> new forwardee, successfully performs the forwarding, and uses that newly
> created forwardee.
> 
> A second thread attempts to evacuate that same second object, and finds it
> already forwarded.  It goes into write_ref_field_post, reaches the assert,
> and attempts to use values from the forwardee.  Because the copy and the
> forwarding by the first thread were unordered, this second thread might see
> the old copy that appears to be forwarded, rather than the up to date copy.
> So the first call to is_forwarded() returns true.  The forwardee() assert of
> the same thing might instead get the up to date contents, resulting in the
> reported failure.  Alternatively, it might still get old data, in which case
> nothing gets noticed because the self-forward check will fail and the
> write_ref_field_post assert will (accidentally) succeed.
> 
> So there's a very small window in which the reported failure can occur.  But
> it's all caused by the write_ref_field_post assert performing invalid
> accesses.  Stop doing that and the problem should go away.
> 
> I think this failure couldn't have happened before JDK-8271579, but that's
> kind of accidental and doesn't change that the write_ref_field_post assert
> was performing invalid accesses.  (Those accesses were introduced later.)
> 
> Testing:
> mach5 tier1-5.
> 
> Ran applications/jcstress/acqrel.java 100 times without failure.
> Without the change I had a 25-30% failure rate for that test.
> I don't know why that test was such a good canary, when this failure seems to
> otherwise be pretty rare, but glad that it was.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into fix_forwarding_assert
 - remove test from problemlist
 - avoid assert based on possibly bad data

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6582/files
  - new: https://git.openjdk.java.net/jdk/pull/6582/files/25daf289..4b353c4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6582&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6582&range=00-01

  Stats: 1461 lines in 73 files changed: 606 ins; 581 del; 274 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6582/head:pull/6582

PR: https://git.openjdk.java.net/jdk/pull/6582


From kbarrett at openjdk.java.net  Tue Nov 30 20:26:46 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 20:26:46 GMT
Subject: Integrated: 8277434: tests fail with
 "assert(is_forwarded()) failed: only decode when actually forwarded"
In-Reply-To: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
References: <GNzELamnIGkFGChdrxt0OcVCDTXJWc7kRUGCG5H9wd8=.1ff50786-1455-412a-89ff-b5ce37f3ccf9@github.com>
Message-ID: <xIqOMjaPs98mInxBad4lShM1avzDiuGEJ5cojV-UFS4=.122e0983-aa1e-448c-b2f3-de0615fe6d77@github.com>

On Sun, 28 Nov 2021 03:30:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change which fixes a rare assert failure in
> G1ParScanThreadState::write_ref_field_post. The problem is that the assert is
> referencing values from the forwardee, and that isn't safe. When an object is
> copied and forwarded to the copy, the forwarding is performed with a relaxed
> cmpxchg. This means the data being copied into the forwardee might not be
> visible to a different thread that has obtained the forwardee. All uses of a
> forwardee must take care to avoid reading from it without performing
> additional synchronization. The assert in question violates that restriction.
> 
> The incorrect assertion is
> 
> assert(dest_attr.is_in_cset() == (obj->is_forwarded() && obj->forwardee() == obj), "...");
> 
> obj is the forwardee of a different object.
> 
> It's okay here to examine the contents of obj when it's in the cset.  In
> that case it's not a copy; it's the original object, self-forwarded due to
> evacuation failure.
> 
> But it's not okay to examine the contents of obj when it's not in the cset,
> e.g. when it's a forwardee copy of the original object.  Doing so violates
> the above restriction.
> 
> So that tells us this code is wrong, but it's still not obvious this is the
> cause of the failure in question.  The failure we're seeing appears to be
> that obj->is_forwarded() returns true, but the assert of the same thing in
> forwardee returns false.  But is_forwarded() should never be true for a
> copied forwardee.  But it turns out a copied forwardee might temporarily
> appear to be forwarded, due to the unordered copy + forward sequence.
> Consider the following scenario:
> 
> A thread is evacuating an object and allocates a candidate forwardee, copies
> into it, and finally discovers the forwarding race was lost even before the
> copy.  The candidate forwardee appears to be marked as forwarded.  That
> candidate is deallocated and the real forwardee is used by the thread.
> 
> That same thread evacuates a second object, reallocating some of the same
> memory as from the previous candidate.  It copies the second object into the
> new forwardee, successfully performs the forwarding, and uses that newly
> created forwardee.
> 
> A second thread attempts to evacuate that same second object, and finds it
> already forwarded.  It goes into write_ref_field_post, reaches the assert,
> and attempts to use values from the forwardee.  Because the copy and the
> forwarding by the first thread were unordered, this second thread might see
> the old copy that appears to be forwarded, rather than the up to date copy.
> So the first call to is_forwarded() returns true.  The forwardee() assert of
> the same thing might instead get the up to date contents, resulting in the
> reported failure.  Alternatively, it might still get old data, in which case
> nothing gets noticed because the self-forward check will fail and the
> write_ref_field_post assert will (accidentally) succeed.
> 
> So there's a very small window in which the reported failure can occur.  But
> it's all caused by the write_ref_field_post assert performing invalid
> accesses.  Stop doing that and the problem should go away.
> 
> I think this failure couldn't have happened before JDK-8271579, but that's
> kind of accidental and doesn't change that the write_ref_field_post assert
> was performing invalid accesses.  (Those accesses were introduced later.)
> 
> Testing:
> mach5 tier1-5.
> 
> Ran applications/jcstress/acqrel.java 100 times without failure.
> Without the change I had a 25-30% failure rate for that test.
> I don't know why that test was such a good canary, when this failure seems to
> otherwise be pretty rare, but glad that it was.

This pull request has now been integrated.

Changeset: 15a68064
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15a680647c4c5df4538e906960c594da79aebf5c
Stats:     10 lines in 3 files changed: 6 ins; 4 del; 0 mod

8277434: tests fail with "assert(is_forwarded()) failed: only decode when actually forwarded"

Reviewed-by: ayang, shade, tschatzl

-------------

PR: https://git.openjdk.java.net/jdk/pull/6582


From duke at openjdk.java.net  Tue Nov 30 20:43:12 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 30 Nov 2021 20:43:12 GMT
Subject: Withdrawn: 8274178: Occupancy value in logging and JFR event is
 inaccurate in G1IHOPControl
In-Reply-To: <eda1d_YlogGjwELjybLTTJCsKrxGQKOo45RvtM8yHpQ=.0c8d10ca-3e4a-4678-b707-c358fbfd21fb@github.com>
References: <eda1d_YlogGjwELjybLTTJCsKrxGQKOo45RvtM8yHpQ=.0c8d10ca-3e4a-4678-b707-c358fbfd21fb@github.com>
Message-ID: <3V3FBOrvwHSjueCXjhnID_h2DzFotD3B53CNcPesM6o=.863972c0-2e2e-4fa3-97f3-cdc714d8c1dd@github.com>

On Wed, 29 Sep 2021 20:03:03 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could we have reviews for this minor fix for logging and JFR event occupancy number for G1? See https://bugs.openjdk.java.net/browse/JDK-8274178 for more details.
> 
> This fix is contributed by colleague Jonathan Joo <jonathanjoo at google.com>.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5762


From kbarrett at openjdk.java.net  Tue Nov 30 22:17:06 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 22:17:06 GMT
Subject: RFR: 8151594: Move concurrent refinement thread activation logging
 out of GC pause
In-Reply-To: <ctRmmmgRdkDugnLUYf18XaQ9ttsf4s25eNnZ4Kb7TYo=.744ca794-40b8-4dde-a5dc-e1ee38d44696@github.com>
References: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
 <ctRmmmgRdkDugnLUYf18XaQ9ttsf4s25eNnZ4Kb7TYo=.744ca794-40b8-4dde-a5dc-e1ee38d44696@github.com>
Message-ID: <kIZYhpdlCLUtte_FoAyIRm_EN37tdNuyTAUK1qY3FBA=.e93ca758-01f9-45cd-8e8e-2faa795b0491@github.com>

On Thu, 25 Nov 2021 19:24:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this move of the thread activation logging by concurrent
>> refinment threads to be within the suspendible thread set context, rather
>> than before it.  This prevents the logging for the thread activation
>> sometimes being intermixed with GC pause-time logging.
>> 
>> Testing:
>> mach5 tier1
>
> Lgtm.

Thanks @tschatzl and @albertnetymk for reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6551


From kbarrett at openjdk.java.net  Tue Nov 30 22:27:31 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 22:27:31 GMT
Subject: RFR: 8151594: Move concurrent refinement thread activation logging
 out of GC pause [v2]
In-Reply-To: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
References: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
Message-ID: <Y_Ysa_fSuOY7DIkiapVF-X3BPBxsw0-hUTa74JjXITQ=.6949931d-6d32-4496-b92e-f42955b5af98@github.com>

> Please review this move of the thread activation logging by concurrent
> refinment threads to be within the suspendible thread set context, rather
> than before it.  This prevents the logging for the thread activation
> sometimes being intermixed with GC pause-time logging.
> 
> Testing:
> mach5 tier1

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into crt_active0
 - move thread active logging inside sts

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6551/files
  - new: https://git.openjdk.java.net/jdk/pull/6551/files/fb8f29d2..580ebc45

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6551&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6551&range=00-01

  Stats: 3989 lines in 141 files changed: 2467 ins; 1023 del; 499 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6551.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6551/head:pull/6551

PR: https://git.openjdk.java.net/jdk/pull/6551


From kbarrett at openjdk.java.net  Tue Nov 30 22:48:48 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 30 Nov 2021 22:48:48 GMT
Subject: Integrated: 8151594: Move concurrent refinement thread activation
 logging out of GC pause
In-Reply-To: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
References: <muro2FwFBIcAtW3SjCB-dIEvHNdKGFPKLqxM7lY1U1s=.3c0f1707-6a2d-4281-85c3-4f3dd7174959@github.com>
Message-ID: <fdApMjNgCoQsCT9cgjYPbBzbaIe4gfqlrF_81PvEPZ4=.28fa07d5-595e-4960-abc0-11418058154f@github.com>

On Thu, 25 Nov 2021 05:56:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this move of the thread activation logging by concurrent
> refinment threads to be within the suspendible thread set context, rather
> than before it.  This prevents the logging for the thread activation
> sometimes being intermixed with GC pause-time logging.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: 65251f76
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/65251f76937d1844e2235ce64b42b17f4492d20e
Stats:     9 lines in 1 file changed: 4 ins; 4 del; 1 mod

8151594: Move concurrent refinement thread activation logging out of GC pause

Reviewed-by: tschatzl, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/6551


From sjohanss at openjdk.java.net  Tue Nov 30 22:59:28 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 30 Nov 2021 22:59:28 GMT
Subject: RFR: 8277757: Parallelize humongous reclaim
In-Reply-To: <uuc9iSu-ZKyTyljfiU3k02EZCjI0nOjZjM0eiK_evPk=.e4d4cd92-1b94-4119-8cf3-fd7a7fd424ba@github.com>
References: <jztzS_E5xXnLCmtF6loiGVa4sdFlFbep6fp7UiyEzSQ=.fd3536b3-e12c-493e-bbf5-955a490bc594@github.com>
 <eH_Vd9q57QuDvBJrj1w-js4drLMDPw8vHyf_7cd-4AM=.e31a024a-a14f-4e8d-9332-f4c4ef424fa1@github.com>
 <6Rp2iPrXmLXktk3o3rOCyZu568yCtpmhIEsHXyfHmRg=.dc050169-d5ff-4727-ac30-b164bf2decae@github.com>
 <uuc9iSu-ZKyTyljfiU3k02EZCjI0nOjZjM0eiK_evPk=.e4d4cd92-1b94-4119-8cf3-fd7a7fd424ba@github.com>
Message-ID: <vPGF2iZG62a6LGvRvYr-7TqPVBOGkuy43KuElwR7-QA=.ee6a1130-9e6e-491c-bb88-3e61dadddb6b@github.com>

On Tue, 30 Nov 2021 14:12:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Again, I have had thoughts along the same lines :) But since we, as you say, already spawn the max number of threads, letting them all help out seems ok. 
>> 
>> At least the number of candidates is always lower or equal to the number of regions being taken care of.
>
> I still prefer to scale the number of threads to the (largest) actual work, which is as we seem to agree on actually iterating through the regions, for that particular phase rather than relying on other phases getting things right or this phase "helping" other phases - or at least try to. Otherwise we could probably just always use a maximum amount of threads available in the hope that they'll help out.

That's a fair point. We should avoid adding more "bad" estimates. 

>From my tests it looks like the cost is both depending on the number of humongous objects reclaimed and the number of regions reclaimed. Reclaiming 600 regions used by 1 objects is cheaper than reclaiming 600 objects using 1 region (using a single worker). So a good estimate should take both the number of objects and the number of regions into consideration. And somehow scale it down by some "magic number" similar to what is done for some other tasks. 

I'll take another look at this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6612