From ayang at openjdk.java.net  Mon Jan  3 15:58:26 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 3 Jan 2022 15:58:26 GMT
Subject: RFR: 8279386: Remove duplicate RefProcPhaseTimeTracker
Message-ID: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>

Simple change of removing duplicate code.

Test: hotspot_gc

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

Commit messages:
 - RefProcPhaseTimeTracker

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

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


From ayang at openjdk.java.net  Mon Jan  3 20:37:18 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 3 Jan 2022 20:37:18 GMT
Subject: RFR: 8278282: G1: Log basic statistics for evacuation failure [v3]
In-Reply-To: <fIhuk1PqK0Ye_rJSg1EULmA9t1txcsWxz6vmah0i_GA=.991a83c2-99c3-4840-adfb-c32b95ecddec@github.com>
References: <F0ZWqFns7ysitfbB2uIf8YcaPZmL0zpwSF9imHhORUc=.dd499014-6bd1-4980-b064-0c1f79b1361a@github.com>
 <fIhuk1PqK0Ye_rJSg1EULmA9t1txcsWxz6vmah0i_GA=.991a83c2-99c3-4840-adfb-c32b95ecddec@github.com>
Message-ID: <I5VvO0UccLB4ebNo-i6d3wLVOJGHqUEHIBeeCBRl7OI=.5e49b7e9-257a-4b32-a63e-a57ddf8d1ad0@github.com>

On Wed, 22 Dec 2021 02:33:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> The original pr is at #6763 , which should be retired as we have decided to adjust part of optimization solution for evacuation failure (see #6627 for details), so the log will be adjusted accordiingly.
>> The basic log related to evacuation failed will looks like below based on this patch.
>> 
>> 
>> [13.126s][debug][gc,phases] GC(0)       Restore Retained Regions (ms): Min:  0.0, Avg: 197.4, Max: 1579.1, Diff: 1579.1, Sum: 1579.1, Workers: 8
>> [13.126s][debug][gc,phases] GC(0)         Evacuation Failure Regions:    Min: 1, Avg:  1.0, Max: 1, Diff: 0, Sum: 1, Workers: 1
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into log-evac-failure-region-num
>  - Fix test
>  - Initial commit

Just a minor comment.

src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 135:

> 133:   _gc_par_phases[MergePSS]->create_thread_work_items("LAB Undo Waste", MergePSSLABUndoWasteBytes);
> 134: 
> 135:   _gc_par_phases[RestoreRetainedRegions]->create_thread_work_items("Evacuation Failure Regions:", RestoreRetainedRegionsNum);

Based on the surrounding naming conventions, `RestoreRetainedRegionsNum` should probably be sth like `RestoreRetainedRegionsNumEvacFailRegions` or just the suffix `NumEvacFailRegions`.

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

Marked as reviewed by ayang (Reviewer).

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


From iwalulya at openjdk.java.net  Tue Jan  4 05:03:15 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 4 Jan 2022 05:03:15 GMT
Subject: RFR: 8278282: G1: Log basic statistics for evacuation failure [v3]
In-Reply-To: <fIhuk1PqK0Ye_rJSg1EULmA9t1txcsWxz6vmah0i_GA=.991a83c2-99c3-4840-adfb-c32b95ecddec@github.com>
References: <F0ZWqFns7ysitfbB2uIf8YcaPZmL0zpwSF9imHhORUc=.dd499014-6bd1-4980-b064-0c1f79b1361a@github.com>
 <fIhuk1PqK0Ye_rJSg1EULmA9t1txcsWxz6vmah0i_GA=.991a83c2-99c3-4840-adfb-c32b95ecddec@github.com>
Message-ID: <LUO3iFJsIV7_rSiAf9J9W1I-ll7UXquCSG7JiigGwEs=.a0491b38-eb9c-408e-9b6a-bf64888d2f1c@github.com>

On Wed, 22 Dec 2021 02:33:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> The original pr is at #6763 , which should be retired as we have decided to adjust part of optimization solution for evacuation failure (see #6627 for details), so the log will be adjusted accordiingly.
>> The basic log related to evacuation failed will looks like below based on this patch.
>> 
>> 
>> [13.126s][debug][gc,phases] GC(0)       Restore Retained Regions (ms): Min:  0.0, Avg: 197.4, Max: 1579.1, Diff: 1579.1, Sum: 1579.1, Workers: 8
>> [13.126s][debug][gc,phases] GC(0)         Evacuation Failure Regions:    Min: 1, Avg:  1.0, Max: 1, Diff: 0, Sum: 1, Workers: 1
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into log-evac-failure-region-num
>  - Fix test
>  - Initial commit

Marked as reviewed by iwalulya (Reviewer).

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

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


From iwalulya at openjdk.java.net  Tue Jan  4 05:26:12 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 4 Jan 2022 05:26:12 GMT
Subject: RFR: 8279386: Remove duplicate RefProcPhaseTimeTracker
In-Reply-To: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
References: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
Message-ID: <y_mmBF17miv0SVp-ZVpa7PKR9fcgS88RXeNz2dPqx98=.b08e0cd1-b273-4aeb-a81b-6bfe17cae2ac@github.com>

On Mon, 3 Jan 2022 15:50:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate code.
> 
> Test: hotspot_gc

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From mli at openjdk.java.net  Tue Jan  4 11:59:21 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 4 Jan 2022 11:59:21 GMT
Subject: RFR: 8278282: G1: Log basic statistics for evacuation failure [v3]
In-Reply-To: <useQQUp-O0ReCQLJPQ9hnd5yLFKvFL3kDp62Q9F5nMs=.b487042a-3f18-4f6d-b490-7b2de6766c3a@github.com>
References: <F0ZWqFns7ysitfbB2uIf8YcaPZmL0zpwSF9imHhORUc=.dd499014-6bd1-4980-b064-0c1f79b1361a@github.com>
 <useQQUp-O0ReCQLJPQ9hnd5yLFKvFL3kDp62Q9F5nMs=.b487042a-3f18-4f6d-b490-7b2de6766c3a@github.com>
Message-ID: <hlKs1IHQ6bCNf-2-0rqPbKaQPK7GSkMFwY0IKCW-mzE=.d7722f5b-efa9-43d1-add8-f54eddd95510@github.com>

On Fri, 17 Dec 2021 12:04:38 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 three commits:
>> 
>>  - Merge branch 'master' into log-evac-failure-region-num
>>  - Fix test
>>  - Initial commit
>
> Lgtm apart from the omission of that log message check.
> 
> I assume that it's just not worth adding log messages for the sub phases (sorting, ...) of the evacuation failure handling since we decided on the other option using the prev bitmap already. That's fine.
> In any case we can always improve these messages.

Thanks @tschatzl @albertnetymk @walulyai for your reviews.

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

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


From mli at openjdk.java.net  Tue Jan  4 11:59:22 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 4 Jan 2022 11:59:22 GMT
Subject: RFR: 8278282: G1: Log basic statistics for evacuation failure [v3]
In-Reply-To: <I5VvO0UccLB4ebNo-i6d3wLVOJGHqUEHIBeeCBRl7OI=.5e49b7e9-257a-4b32-a63e-a57ddf8d1ad0@github.com>
References: <F0ZWqFns7ysitfbB2uIf8YcaPZmL0zpwSF9imHhORUc=.dd499014-6bd1-4980-b064-0c1f79b1361a@github.com>
 <fIhuk1PqK0Ye_rJSg1EULmA9t1txcsWxz6vmah0i_GA=.991a83c2-99c3-4840-adfb-c32b95ecddec@github.com>
 <I5VvO0UccLB4ebNo-i6d3wLVOJGHqUEHIBeeCBRl7OI=.5e49b7e9-257a-4b32-a63e-a57ddf8d1ad0@github.com>
Message-ID: <UezQXZwTpCh1gJAjRoGLM7B9Shj2McFc3immzHwWfsE=.93eeeaed-bfa6-4937-95c4-bf1725189b05@github.com>

On Mon, 3 Jan 2022 20:34:03 GMT, Albert Mingkun Yang <ayang 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 three commits:
>> 
>>  - Merge branch 'master' into log-evac-failure-region-num
>>  - Fix test
>>  - Initial commit
>
> src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 135:
> 
>> 133:   _gc_par_phases[MergePSS]->create_thread_work_items("LAB Undo Waste", MergePSSLABUndoWasteBytes);
>> 134: 
>> 135:   _gc_par_phases[RestoreRetainedRegions]->create_thread_work_items("Evacuation Failure Regions:", RestoreRetainedRegionsNum);
> 
> Based on the surrounding naming conventions, `RestoreRetainedRegionsNum` should probably be sth like `RestoreRetainedRegionsNumEvacFailRegions` or just the suffix `NumEvacFailRegions`.

Thanks Albert, I see your point.
But seems the surrounding naming convention is not that strict, and there is no uniform convention here. And to me, `RestoreRetainedRegionsNum` is more friendly to read and easily related to `RestoreRetainedRegions`, so I prefer to keep it as `RestoreRetainedRegionsNum`.

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

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


From mli at openjdk.java.net  Tue Jan  4 11:59:23 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 4 Jan 2022 11:59:23 GMT
Subject: Integrated: 8278282: G1: Log basic statistics for evacuation failure
In-Reply-To: <F0ZWqFns7ysitfbB2uIf8YcaPZmL0zpwSF9imHhORUc=.dd499014-6bd1-4980-b064-0c1f79b1361a@github.com>
References: <F0ZWqFns7ysitfbB2uIf8YcaPZmL0zpwSF9imHhORUc=.dd499014-6bd1-4980-b064-0c1f79b1361a@github.com>
Message-ID: <zkmAvxp4Zpn4DjDPN2g-9TsGtTUguXanTgBcZueJJ6A=.605d1d58-85f8-4829-a994-badc91fb905f@github.com>

On Thu, 16 Dec 2021 09:29:09 GMT, Hamlin Li <mli at openjdk.org> wrote:

> The original pr is at #6763 , which should be retired as we have decided to adjust part of optimization solution for evacuation failure (see #6627 for details), so the log will be adjusted accordiingly.
> The basic log related to evacuation failed will looks like below based on this patch.
> 
> 
> [13.126s][debug][gc,phases] GC(0)       Restore Retained Regions (ms): Min:  0.0, Avg: 197.4, Max: 1579.1, Diff: 1579.1, Sum: 1579.1, Workers: 8
> [13.126s][debug][gc,phases] GC(0)         Evacuation Failure Regions:    Min: 1, Avg:  1.0, Max: 1, Diff: 0, Sum: 1, Workers: 1

This pull request has now been integrated.

Changeset: 93c7d90c
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/93c7d90c55034ba8dbcd612366c891ad08c9c54e
Stats:     23 lines in 6 files changed: 16 ins; 0 del; 7 mod

8278282: G1: Log basic statistics for evacuation failure

Reviewed-by: tschatzl, ayang, iwalulya

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

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


From mli at openjdk.java.net  Tue Jan  4 12:10:09 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 4 Jan 2022 12:10:09 GMT
Subject: RFR: 8279386: Remove duplicate RefProcPhaseTimeTracker
In-Reply-To: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
References: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
Message-ID: <W3eJ3K3XDryCnsd1jFFeKH4Dj4xePi2Ok40BrE78obY=.80b9a41a-0b6b-4fbb-ba12-b17234c76c5f@github.com>

On Mon, 3 Jan 2022 15:50:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate code.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by mli (Reviewer).

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


From ayang at openjdk.java.net  Tue Jan  4 16:10:19 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 4 Jan 2022 16:10:19 GMT
Subject: RFR: 8279386: Remove duplicate RefProcPhaseTimeTracker
In-Reply-To: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
References: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
Message-ID: <ITmYqyLBCtElfM1cKT4qllLwHNHp2Zvtk2NW6FAUMdc=.d6e88df1-d549-427f-83b4-1a4be293856a@github.com>

On Mon, 3 Jan 2022 15:50:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate code.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Jan  4 16:10:19 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 4 Jan 2022 16:10:19 GMT
Subject: Integrated: 8279386: Remove duplicate RefProcPhaseTimeTracker
In-Reply-To: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
References: <qT52ox9PF9EOc7NWZr6YT7Lqvbr093EPXzJZBgsFA_M=.0df6fdbf-2ed6-4bcc-a413-47ede5e1d62d@github.com>
Message-ID: <NfT_M9F8WIGKwdqfxfDJ_jKMQInbQguPK5oi5uMqmHc=.c41c6201-7e8b-4a55-baa1-1cf90c766173@github.com>

On Mon, 3 Jan 2022 15:50:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate code.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 99a8351b
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99a8351bc913a94f8aebef54fe7b147545edd258
Stats:     24 lines in 3 files changed: 0 ins; 24 del; 0 mod

8279386: Remove duplicate RefProcPhaseTimeTracker

Reviewed-by: iwalulya, mli

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

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


From ayang at openjdk.java.net  Wed Jan  5 09:53:39 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 5 Jan 2022 09:53:39 GMT
Subject: RFR: 8279510: Parallel: Remove unused
 PSScavenge::_consecutive_skipped_scavenges
Message-ID: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>

Simple change of removing effectively unused code.

Test: hotspot_gc

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

Commit messages:
 - consecutive_skipped_scavenges

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

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


From kbarrett at openjdk.java.net  Wed Jan  5 13:41:16 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 5 Jan 2022 13:41:16 GMT
Subject: RFR: 8279510: Parallel: Remove unused
 PSScavenge::_consecutive_skipped_scavenges
In-Reply-To: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>
References: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>
Message-ID: <r6fl9wuy-zC1Zxvy1DuYs0cemQRZeVjGmIseHHvIiYI=.87b6a25b-4f56-4e3c-b8d4-8c75e5595157@github.com>

On Wed, 5 Jan 2022 09:44:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively unused code.
> 
> Test: hotspot_gc

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Wed Jan  5 15:41:15 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 5 Jan 2022 15:41:15 GMT
Subject: RFR: 8279510: Parallel: Remove unused
 PSScavenge::_consecutive_skipped_scavenges
In-Reply-To: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>
References: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>
Message-ID: <9ICjr1mkfO1XmVkR1cgCnLkStXqv45T1zvRnCwEyDVA=.79884cd9-54eb-47c8-8f02-9d6c45c6d417@github.com>

On Wed, 5 Jan 2022 09:44:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively unused code.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Jan  5 15:41:15 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 5 Jan 2022 15:41:15 GMT
Subject: Integrated: 8279510: Parallel: Remove unused
 PSScavenge::_consecutive_skipped_scavenges
In-Reply-To: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>
References: <cI6GN4-kOdvNwQDgZ_G5sSTdfESBLF19uTLivoQUU0w=.def9c0ff-7483-46f0-84ee-7e50e8c45552@github.com>
Message-ID: <Wqt4DW2NbGPtw1t4u8f1XwGl-86o6i1kzdzn7SQt_EA=.b609b892-9821-42d5-bb85-0ecf06dd6345@github.com>

On Wed, 5 Jan 2022 09:44:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively unused code.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: b6ec39cc
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6ec39cc84cfc845b09c0f851a24751c4abf6e1c
Stats:     12 lines in 2 files changed: 0 ins; 11 del; 1 mod

8279510: Parallel: Remove unused PSScavenge::_consecutive_skipped_scavenges

Reviewed-by: kbarrett

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

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


From ayang at openjdk.java.net  Wed Jan  5 15:56:35 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 5 Jan 2022 15:56:35 GMT
Subject: RFR: 8279522: Serial: Remove unused Generation::clear_remembered_set
Message-ID: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>

Trivial change of removing unused code.

Test: hotspot_gc

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

Commit messages:
 - trivial

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

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


From ayang at openjdk.java.net  Wed Jan  5 16:15:30 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 5 Jan 2022 16:15:30 GMT
Subject: RFR: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
Message-ID: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>

Simple change of removing an unnecessary field.

Test: hotspot_gc

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

Commit messages:
 - save_to_space_top_before_gc

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

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


From iwalulya at openjdk.java.net  Wed Jan  5 18:24:18 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 5 Jan 2022 18:24:18 GMT
Subject: RFR: 8279522: Serial: Remove unused
 Generation::clear_remembered_set
In-Reply-To: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
References: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
Message-ID: <Jhg52tsEyTvhOp6THz_7YKsXs-r-FHH87jD8GGt20ik=.38c09421-edb7-4e3e-ad9a-6d28d30d7643@github.com>

On Wed, 5 Jan 2022 15:47:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing unused code.
> 
> Test: hotspot_gc

Marked as reviewed by iwalulya (Reviewer).

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

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


From zgu at openjdk.java.net  Wed Jan  5 18:53:28 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 5 Jan 2022 18:53:28 GMT
Subject: RFR: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
Message-ID: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>

A trivial patch to remove unused always_true variable.

Test:
- [x] Built on Linux x86_64

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

Commit messages:
 - Merge branch 'master' into JDK-8279168-unused-always_true
 - 8279168: Shenandoah: Remove unused always_true in ShenandoahRootAdjuster::roots_do()

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

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


From shade at openjdk.java.net  Wed Jan  5 18:53:28 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 18:53:28 GMT
Subject: RFR: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
In-Reply-To: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
References: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
Message-ID: <xQdF8XhpdtGOyFNv5OEFiSj51DiaYHTH09f3CbNy8_A=.fb7b0f35-ea06-4d46-b3ce-7661dd7b2898@github.com>

On Wed, 22 Dec 2021 15:12:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> A trivial patch to remove unused always_true variable.
> 
> Test:
> - [x] Built on Linux x86_64

This PR is still "draft", intended?

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

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


From shade at openjdk.java.net  Wed Jan  5 19:01:16 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 5 Jan 2022 19:01:16 GMT
Subject: RFR: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
In-Reply-To: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
References: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
Message-ID: <cojt5G9PeeUSxOKQdPFmioOJHmLycE4V3clBniMNOBI=.c6264082-9b27-4c55-9735-90ec2d46b5a0@github.com>

On Wed, 22 Dec 2021 15:12:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> A trivial patch to remove unused always_true variable.
> 
> Test:
> - [x] Built on Linux x86_64

Looks fine.

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

Marked as reviewed by shade (Reviewer).

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


From zgu at openjdk.java.net  Wed Jan  5 19:16:14 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 5 Jan 2022 19:16:14 GMT
Subject: Integrated: 8279168: Shenandoah: Remove unused always_true in
 ShenandoahRootAdjuster::roots_do()
In-Reply-To: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
References: <mKWQU8KDeuDgtMHs-LjTl53aNz87CEpdG5qrqSlHd2M=.fec984af-cf4c-4ebb-9f37-b67f41037310@github.com>
Message-ID: <edvt3rToVK8WEW_XqJfTj0EV5-1E-I6d8oR6tf41nY4=.0f8b1ec4-6211-427f-9489-79a28fb2588b@github.com>

On Wed, 22 Dec 2021 15:12:55 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> A trivial patch to remove unused always_true variable.
> 
> Test:
> - [x] Built on Linux x86_64

This pull request has now been integrated.

Changeset: 7b429a64
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b429a64ce7def84833de9e95217f303d9a7629d
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8279168: Shenandoah: Remove unused always_true in ShenandoahRootAdjuster::roots_do()

Reviewed-by: shade

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

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


From mli at openjdk.java.net  Thu Jan  6 06:56:16 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 6 Jan 2022 06:56:16 GMT
Subject: RFR: 8279522: Serial: Remove unused
 Generation::clear_remembered_set
In-Reply-To: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
References: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
Message-ID: <xGS7UHabDwrD21pw2dvpIn_uCpP67ZR-ANS8rLQ19b0=.608ee14e-8051-4773-83d3-6240bcdb878e@github.com>

On Wed, 5 Jan 2022 15:47:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing unused code.
> 
> Test: hotspot_gc

Marked as reviewed by mli (Reviewer).

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

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


From mli at openjdk.java.net  Thu Jan  6 08:50:16 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 6 Jan 2022 08:50:16 GMT
Subject: RFR: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
In-Reply-To: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
References: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
Message-ID: <ZapPUvrXIUsHyEqzE6a_2KoLC9tpoFFssUmN64VRF8I=.dff457fb-8b89-4f37-9726-58d81fb106d9@github.com>

On Wed, 5 Jan 2022 16:09:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary field.
> 
> Test: hotspot_gc

src/hotspot/share/gc/parallel/psScavenge.inline.hpp line 49:

> 47:     // Skip objects copied to to_space since the scavenge started.
> 48:     HeapWord* const addr = cast_from_oop<HeapWord*>(obj);
> 49:     return addr < to_space->bottom() || addr >= to_space->end();

Not sure if I understand this correctly, is this a typo or intended from top to bottom?

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

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


From ayang at openjdk.java.net  Thu Jan  6 10:50:11 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 6 Jan 2022 10:50:11 GMT
Subject: RFR: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
In-Reply-To: <ZapPUvrXIUsHyEqzE6a_2KoLC9tpoFFssUmN64VRF8I=.dff457fb-8b89-4f37-9726-58d81fb106d9@github.com>
References: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
 <ZapPUvrXIUsHyEqzE6a_2KoLC9tpoFFssUmN64VRF8I=.dff457fb-8b89-4f37-9726-58d81fb106d9@github.com>
Message-ID: <fUWfEC7UkEadatyswZuN1RM9Zo2bOz6C9726Yd5-Nxc=.d169a98e-e256-4ba5-97dd-869f89821c91@github.com>

On Thu, 6 Jan 2022 07:12:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Simple change of removing an unnecessary field.
>> 
>> Test: hotspot_gc
>
> src/hotspot/share/gc/parallel/psScavenge.inline.hpp line 49:
> 
>> 47:     // Skip objects copied to to_space since the scavenge started.
>> 48:     HeapWord* const addr = cast_from_oop<HeapWord*>(obj);
>> 49:     return addr < to_space->bottom() || addr >= to_space->end();
> 
> Not sure if I understand this correctly, is this a typo or intended from top to bottom?

It's intended because `to_space_top_before_gc() == to_space->bottom()`.

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

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


From zgu at openjdk.java.net  Thu Jan  6 13:34:31 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 6 Jan 2022 13:34:31 GMT
Subject: RFR: 8279540: Shenandoah: Should only clear CLD::_claim_strong mark
 for strong CLD iterations
Message-ID: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>

JDK-8273559 started to use CLD::_claim_other for heap iteration in supporting multi-threaded heap walk. For regular CLD, it still uses CLD::_claim_strong, but for those walks, it clears all claim bits, instead of just _claim_strong bit.

I don't think it is a fatal bug, it just means heap iteration may walk a CLD by multiple workers, which impacts performance.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - 8279540: Shenandoah: Should only clear CLD::_claim_strong mark for strong CLD iterations

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

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


From shade at openjdk.java.net  Fri Jan  7 10:49:15 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 7 Jan 2022 10:49:15 GMT
Subject: RFR: 8279540: Shenandoah: Should only clear CLD::_claim_strong
 mark for strong CLD iterations
In-Reply-To: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
References: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
Message-ID: <rkhEZiK1n3shwzCMud71ialKQbxHjBqzOzvF_k5MHbo=.5ba310f5-ea84-4ba5-bad9-1d5686a2c559@github.com>

On Thu, 6 Jan 2022 13:27:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8273559 started to use CLD::_claim_other for heap iteration in supporting multi-threaded heap walk. For regular CLD, it still uses CLD::_claim_strong, but for those walks, it clears all claim bits, instead of just _claim_strong bit.
> 
> I don't think it is a fatal bug, it just means heap iteration may walk a CLD by multiple workers, which impacts performance.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks reasonable.

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

Marked as reviewed by shade (Reviewer).

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


From zgu at openjdk.java.net  Fri Jan  7 13:37:14 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 7 Jan 2022 13:37:14 GMT
Subject: Integrated: 8279540: Shenandoah: Should only clear CLD::_claim_strong
 mark for strong CLD iterations
In-Reply-To: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
References: <zKCyCTIdNzsWDmX8-R675qOKvSEt-0QCPXhVuq6xxDg=.d6148fb4-c834-4785-a5c0-d73da6635987@github.com>
Message-ID: <6A8D44rBe8lB5hQHUauIwm7c1G3NZdUIqrI0X84FxeM=.8d281597-2171-46b3-85da-5cf53a3fa484@github.com>

On Thu, 6 Jan 2022 13:27:16 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> JDK-8273559 started to use CLD::_claim_other for heap iteration in supporting multi-threaded heap walk. For regular CLD, it still uses CLD::_claim_strong, but for those walks, it clears all claim bits, instead of just _claim_strong bit.
> 
> I don't think it is a fatal bug, it just means heap iteration may walk a CLD by multiple workers, which impacts performance.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 4243f4c9
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4243f4c998344e77dccd4d5605e56e869bc8af89
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8279540: Shenandoah: Should only clear CLD::_claim_strong mark for strong CLD iterations

Reviewed-by: shade

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

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


From ayang at openjdk.java.net  Fri Jan  7 17:29:36 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 7 Jan 2022 17:29:36 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: <cIkEbhFgfLYRjjMSi-IoFnZNNGNHyB8pisTi0hxOW-g=.5c70e99a-5b89-4a80-b7f7-6c12793c7200@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

In the scenario where discovery is sequential && parallel ref-processing is disabled (e.g. `ParallelRefProcEnabled == false`) && `ParallelGCThreads > 1`, all iterations except the first one in `for (uint j = 0; j < _num_queues; ++j) {` are no-op. Will be fixed by 
https://bugs.openjdk.java.net/browse/JDK-8279456

Therefore, I will keep this PR open until then.

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

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


From kbarrett at openjdk.java.net  Sun Jan  9 13:55:28 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 9 Jan 2022 13:55:28 GMT
Subject: RFR: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
In-Reply-To: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
References: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
Message-ID: <9LVv93mHe4M2_SdMpDm82WAlmlsPcNQ5LYV0V6dvHnE=.92cf72c6-3f2e-4459-8912-06655839dc42@github.com>

On Wed, 5 Jan 2022 16:09:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary field.
> 
> Test: hotspot_gc

Looks good.  I wonder if this is a leftover from something since discarded, like UseAdaptiveGCBoundary.

As further evidence that this change is okay, `save_to_space_top_before_gc()` was called immediately after `young_gen->to_space()->clear()`.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Mon Jan 10 01:11:29 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 10 Jan 2022 01:11:29 GMT
Subject: RFR: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
In-Reply-To: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
References: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
Message-ID: <H2JQtIiMNMy4Z6MpYcLh9RDyTwNumuG0JXvH1rtaqvI=.34599ff8-bd52-42c4-a360-a07a21cf6961@github.com>

On Wed, 5 Jan 2022 16:09:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary field.
> 
> Test: hotspot_gc

Thanks for clarification. Looks good.
( Sorry for the delayed response, I haven't access to the code for the last few days. )

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

Marked as reviewed by mli (Reviewer).

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


From ayang at openjdk.java.net  Mon Jan 10 08:59:35 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 08:59:35 GMT
Subject: RFR: 8279522: Serial: Remove unused
 Generation::clear_remembered_set
In-Reply-To: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
References: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
Message-ID: <kUI7iYuqjQ0aRa2W2QT-CEjo3z46N0iLbg22ErRgrkc=.afeb351e-6522-46c3-b606-ba3ca429be5f@github.com>

On Wed, 5 Jan 2022 15:47:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing unused code.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Jan 10 08:59:35 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 08:59:35 GMT
Subject: Integrated: 8279522: Serial: Remove unused
 Generation::clear_remembered_set
In-Reply-To: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
References: <UtVUu-YsxXd0kox6vKeXuDqwJFGb_AzK6b2BK-805Fo=.c0ed09e9-1591-4b8e-99c6-2aa0df67e6b7@github.com>
Message-ID: <CAsV2smMGZ363Fi4SFRU-DcoJtOJMT-A7t0j9pTtb4s=.03e8e71c-5919-43ed-97a6-584c05483aa9@github.com>

On Wed, 5 Jan 2022 15:47:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing unused code.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 5fa13bb4
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5fa13bb4a39225c4345ee129b30fb08ad5fdff6d
Stats:     12 lines in 3 files changed: 0 ins; 12 del; 0 mod

8279522: Serial: Remove unused Generation::clear_remembered_set

Reviewed-by: iwalulya, mli

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

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


From ayang at openjdk.java.net  Mon Jan 10 09:01:33 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 09:01:33 GMT
Subject: RFR: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
In-Reply-To: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
References: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
Message-ID: <qsj9yxiQIB68rrz0o-IZfIit41JQGzUy6jObVd4im3g=.17b1b073-d38e-4021-abcc-5da9eab62cac@github.com>

On Wed, 5 Jan 2022 16:09:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary field.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Jan 10 09:01:33 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 09:01:33 GMT
Subject: Integrated: 8279523: Parallel: Remove unnecessary
 PSScavenge::_to_space_top_before_gc
In-Reply-To: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
References: <U8Nv1p-1avP3iJOVYs2QG9D8wdHBxILyGnL9u3lVBoo=.87ef6f29-7abd-4c41-abbd-387a723b8e40@github.com>
Message-ID: <XC0gdM4QGROiZpipL6UTDwTKXdwiQGPPX9NDbPHM61c=.c55cbd99-c2d0-4ea1-bc98-492227043119@github.com>

On Wed, 5 Jan 2022 16:09:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary field.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 79b614cc
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79b614cc19454765eba17acd27d9772e7eaae1ee
Stats:     16 lines in 3 files changed: 0 ins; 15 del; 1 mod

8279523: Parallel: Remove unnecessary PSScavenge::_to_space_top_before_gc

Reviewed-by: kbarrett, mli

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

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


From tschatzl at openjdk.java.net  Mon Jan 10 10:33:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 10 Jan 2022 10:33:34 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase
In-Reply-To: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
Message-ID: <yFufe2Rd1RftO2skhRNVMmelQ9SJLjckPFa_JUFM15Q=.757a696c-c8f4-44a6-844d-a511be9d4094@github.com>

On Wed, 22 Dec 2021 12:48:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
> 
> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015

Marked as reviewed by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 34:

> 32: #include "runtime/atomic.hpp"
> 33: 
> 34: inline HeapWord* G1BlockOffsetTablePart::align_up_by_card_size(HeapWord* const addr) const{

Suggestion:

inline HeapWord* G1BlockOffsetTablePart::align_up_by_card_size(HeapWord* const addr) const {

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

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


From ayang at openjdk.java.net  Mon Jan 10 10:56:56 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 10:56:56 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase [v2]
In-Reply-To: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
Message-ID: <nlyoQ1jiBzeunDVcvEGJX5UO-h1uHH-05RGwYJObimI=.7e454a31-687a-48a2-a37a-c193783b0d75@github.com>

> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
> 
> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015

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

  Update src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6916/files
  - new: https://git.openjdk.java.net/jdk/pull/6916/files/962d3398..1242f947

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

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

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


From ayang at openjdk.java.net  Mon Jan 10 15:34:39 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 15:34:39 GMT
Subject: RFR: 8279700: Parallel: Simplify ScavengeRootsTask constructor API
Message-ID: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>

Simple cleanup around `ScavengeRootsTask`.

Test: hotspot_gc

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

Commit messages:
 - scavenge-old-gen-top

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

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


From ayang at openjdk.java.net  Mon Jan 10 15:59:43 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 15:59:43 GMT
Subject: RFR: 8279699: Parallel: More precious boundary in
 ObjectStartArray::object_starts_in_range
Message-ID: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>

Simple change in boundary condition checking and updating the API doc.

Test: hotspot_gc

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

Commit messages:
 - object_starts_in_range-exclusive-end

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

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


From tschatzl at openjdk.java.net  Mon Jan 10 16:40:54 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 10 Jan 2022 16:40:54 GMT
Subject: RFR: 8279703: G1: Remove unused force_not_compacted local in
 G1CalculatePointersClosure::do_heap_region
Message-ID: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>

Hi all,

  please review this trivial removal of an unused local I came across when looking through that code for another purpose.

Testing: local compilation

Thanks,
  Thomas

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

Commit messages:
 - Remove unused local

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

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


From ayang at openjdk.java.net  Mon Jan 10 16:45:29 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 10 Jan 2022 16:45:29 GMT
Subject: RFR: 8279703: G1: Remove unused force_not_compacted local in
 G1CalculatePointersClosure::do_heap_region
In-Reply-To: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
References: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
Message-ID: <2DCr25LpMP1jephecf7RpuXfuYJiX8FcWAnycUkRV4s=.a8743e47-a7db-4745-80d6-81de9979add2@github.com>

On Mon, 10 Jan 2022 16:33:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of an unused local I came across when looking through that code for another purpose.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Good and trivial.

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

Marked as reviewed by ayang (Reviewer).

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


From mli at openjdk.java.net  Tue Jan 11 08:02:28 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 11 Jan 2022 08:02:28 GMT
Subject: RFR: 8279703: G1: Remove unused force_not_compacted local in
 G1CalculatePointersClosure::do_heap_region
In-Reply-To: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
References: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
Message-ID: <5zuBxtyIcqDPo5GXuCIW_Tzf_Tw8t07e9hKXm2SCXyM=.dde98e78-03b5-44d1-87f9-d2cbcee671ec@github.com>

On Mon, 10 Jan 2022 16:33:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of an unused local I came across when looking through that code for another purpose.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by mli (Reviewer).

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

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


From tschatzl at openjdk.java.net  Tue Jan 11 08:43:29 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 11 Jan 2022 08:43:29 GMT
Subject: RFR: 8279703: G1: Remove unused force_not_compacted local in
 G1CalculatePointersClosure::do_heap_region
In-Reply-To: <2DCr25LpMP1jephecf7RpuXfuYJiX8FcWAnycUkRV4s=.a8743e47-a7db-4745-80d6-81de9979add2@github.com>
References: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
 <2DCr25LpMP1jephecf7RpuXfuYJiX8FcWAnycUkRV4s=.a8743e47-a7db-4745-80d6-81de9979add2@github.com>
Message-ID: <qYy-psJSJ0CcD50dweC2vNTDHAzOIU_CJxfbqWx5uNg=.db1beec7-f38a-43f3-90b1-644bc247e37f@github.com>

On Mon, 10 Jan 2022 16:42:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of an unused local I came across when looking through that code for another purpose.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Good and trivial.

Thanks @albertnetymk @Hamlin-Li  for your reviews.

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

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


From tschatzl at openjdk.java.net  Tue Jan 11 08:43:29 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 11 Jan 2022 08:43:29 GMT
Subject: Integrated: 8279703: G1: Remove unused force_not_compacted local in
 G1CalculatePointersClosure::do_heap_region
In-Reply-To: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
References: <HcDrnom29R5oc-jPU9RRnX_y6L4G1Re6NBHNufFUws8=.3812d76d-6adc-4974-8522-05b67a1f6cbb@github.com>
Message-ID: <C5RbWxStpEE62eDhxUeD-y0KLeOWqnD8_pSnwXSy84Y=.60e4a4b2-2b3e-49bf-9ab2-b58ce3cb590d@github.com>

On Mon, 10 Jan 2022 16:33:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of an unused local I came across when looking through that code for another purpose.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8279703: G1: Remove unused force_not_compacted local in G1CalculatePointersClosure::do_heap_region

Reviewed-by: ayang, mli

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

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


From tschatzl at openjdk.java.net  Tue Jan 11 08:46:27 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 11 Jan 2022 08:46:27 GMT
Subject: RFR: 8279700: Parallel: Simplify ScavengeRootsTask constructor API
In-Reply-To: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
References: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
Message-ID: <Ogb_1LAwOOGoIiGWh7tl0WHxqxfNxoyWNW6FHie1bWY=.f723932e-fadb-4370-9b70-e88037735aa2@github.com>

On Mon, 10 Jan 2022 15:25:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup around `ScavengeRootsTask`.
> 
> Test: hotspot_gc

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Jan 11 11:53:23 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 11 Jan 2022 11:53:23 GMT
Subject: RFR: 8279700: Parallel: Simplify ScavengeRootsTask constructor API
In-Reply-To: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
References: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
Message-ID: <b-Z5l8uc51Q5HYTufH-5ID0G-Vgav4qpxmEQ1jP8oZY=.e3342f3f-d573-423b-b55f-1e56336b9888@github.com>

On Mon, 10 Jan 2022 15:25:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup around `ScavengeRootsTask`.
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Jan 11 12:59:27 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 11 Jan 2022 12:59:27 GMT
Subject: RFR: 8279699: Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
References: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
Message-ID: <kWzO3K6jmwiy8Sq21L401HtNKk6us8pTPnoNJ056r-A=.21ca32d0-ba49-4246-b6cd-475e72607163@github.com>

On Mon, 10 Jan 2022 15:50:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change in boundary condition checking and updating the API doc.
> 
> Test: hotspot_gc

src/hotspot/share/gc/parallel/objectStartArray.hpp line 172:

> 170:   // where
> 171:   //   start_addr_aligned_down = align_down(start_addr, _card_size)
> 172:   //   end_addr_aligned_up = align_up(end_addr, _card_size)

The code doesn't do align_down on start, but looking at the callers it looks like start_addr will always be card size aligned. Would it make sense to assert this?

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

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


From sjohanss at openjdk.java.net  Tue Jan 11 13:02:30 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 11 Jan 2022 13:02:30 GMT
Subject: RFR: 8278207: G1: Tighten verification in
 G1ResetSkipCompactingClosure [v2]
In-Reply-To: <0ucRQIVb1t4iexl-FVc3D6rwgkskj9YYbgl--f5DiE4=.c1c6ef9c-4454-4ced-9079-3587997d371d@github.com>
References: <50Xr3nsoFXn_kpZeLw9NUvkQRzwK3VkrhuHwj6bdT0Q=.acd78a51-9205-4013-953d-3886873037f4@github.com>
 <0ucRQIVb1t4iexl-FVc3D6rwgkskj9YYbgl--f5DiE4=.c1c6ef9c-4454-4ced-9079-3587997d371d@github.com>
Message-ID: <b4Km82UIZsgDt7t-oP8k7yLloslYh5KqBlnYscz_oTo=.24f0dfff-dc87-48c4-b0ea-a737f0e3091b@github.com>

On Wed, 8 Dec 2021 08:52:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of expanding the verification logic to mirror its source.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   closed archive

I'm ok with leaving this as is as well.

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

Marked as reviewed by sjohanss (Reviewer).

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


From ayang at openjdk.java.net  Tue Jan 11 14:07:49 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 Jan 2022 14:07:49 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record promotion-failed
 objects
Message-ID: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>

Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.

Test: tier1-6

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

Commit messages:
 - parallel-promotion-failure

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

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


From ayang at openjdk.java.net  Tue Jan 11 14:08:33 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 Jan 2022 14:08:33 GMT
Subject: RFR: 8278207: G1: Tighten verification in
 G1ResetSkipCompactingClosure [v2]
In-Reply-To: <0ucRQIVb1t4iexl-FVc3D6rwgkskj9YYbgl--f5DiE4=.c1c6ef9c-4454-4ced-9079-3587997d371d@github.com>
References: <50Xr3nsoFXn_kpZeLw9NUvkQRzwK3VkrhuHwj6bdT0Q=.acd78a51-9205-4013-953d-3886873037f4@github.com>
 <0ucRQIVb1t4iexl-FVc3D6rwgkskj9YYbgl--f5DiE4=.c1c6ef9c-4454-4ced-9079-3587997d371d@github.com>
Message-ID: <AYY_pCqKI96VZ-C0uk6RUi2Z-D4U_TMPF-ux1E0oHHs=.9a348da8-4854-4212-88c0-96a44e8ab446@github.com>

On Wed, 8 Dec 2021 08:52:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of expanding the verification logic to mirror its source.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   closed archive

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Jan 11 14:08:34 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 Jan 2022 14:08:34 GMT
Subject: Integrated: 8278207: G1: Tighten verification in
 G1ResetSkipCompactingClosure
In-Reply-To: <50Xr3nsoFXn_kpZeLw9NUvkQRzwK3VkrhuHwj6bdT0Q=.acd78a51-9205-4013-953d-3886873037f4@github.com>
References: <50Xr3nsoFXn_kpZeLw9NUvkQRzwK3VkrhuHwj6bdT0Q=.acd78a51-9205-4013-953d-3886873037f4@github.com>
Message-ID: <kNTV0-mWjHM9oTVUJilL4buS0gS8eZ4Exuj_RxJpwmg=.fedd7c55-cbff-4d28-b1ae-8a2eee086cc7@github.com>

On Fri, 3 Dec 2021 10:35:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of expanding the verification logic to mirror its source.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 08e14c60
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08e14c605e7ecf555feddda59ae842e2af2035ba
Stats:     16 lines in 1 file changed: 11 ins; 1 del; 4 mod

8278207: G1: Tighten verification in G1ResetSkipCompactingClosure

Reviewed-by: tschatzl, sjohanss

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

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


From ayang at openjdk.java.net  Tue Jan 11 16:21:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 Jan 2022 16:21:32 GMT
Subject: RFR: 8279700: Parallel: Simplify ScavengeRootsTask constructor API
In-Reply-To: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
References: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
Message-ID: <LKlzL4PvkxNcd_25FtI1yMhFo0lRzkP8vytouo518m0=.a089808b-6f61-4346-abd1-aaed796c4c6e@github.com>

On Mon, 10 Jan 2022 15:25:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup around `ScavengeRootsTask`.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Jan 11 16:21:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 Jan 2022 16:21:32 GMT
Subject: Integrated: 8279700: Parallel: Simplify ScavengeRootsTask constructor
 API
In-Reply-To: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
References: <npc_Ja5ONV-Y8NqwQwqdG_KaT-wpaqeHC3Z0Z_6xfkM=.88467702-8c65-4249-9281-9bfad25b1481@github.com>
Message-ID: <TRtIYHe86SuT0F7AT1PXBoW6nJ60DwxywaChIja-2mo=.d9992184-930e-4af0-a31c-c8d782132ca8@github.com>

On Mon, 10 Jan 2022 15:25:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup around `ScavengeRootsTask`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 67141849
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67141849d922a3899fcb4429a520b874b7d91b4c
Stats:     23 lines in 1 file changed: 2 ins; 15 del; 6 mod

8279700: Parallel: Simplify ScavengeRootsTask constructor API

Reviewed-by: tschatzl, sjohanss

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

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


From ayang at openjdk.java.net  Tue Jan 11 16:23:23 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 11 Jan 2022 16:23:23 GMT
Subject: RFR: 8279699: Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <kWzO3K6jmwiy8Sq21L401HtNKk6us8pTPnoNJ056r-A=.21ca32d0-ba49-4246-b6cd-475e72607163@github.com>
References: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
 <kWzO3K6jmwiy8Sq21L401HtNKk6us8pTPnoNJ056r-A=.21ca32d0-ba49-4246-b6cd-475e72607163@github.com>
Message-ID: <KQ1FPFKOuv9-1yKZ49pkj5JCXKnevhzJoG0JqJzKIj8=.dcc104bd-3ecc-409a-8409-6bb20c076650@github.com>

On Tue, 11 Jan 2022 12:56:39 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Simple change in boundary condition checking and updating the API doc.
>> 
>> Test: hotspot_gc
>
> src/hotspot/share/gc/parallel/objectStartArray.hpp line 172:
> 
>> 170:   // where
>> 171:   //   start_addr_aligned_down = align_down(start_addr, _card_size)
>> 172:   //   end_addr_aligned_up = align_up(end_addr, _card_size)
> 
> The code doesn't do align_down on start, but looking at the callers it looks like start_addr will always be card size aligned. Would it make sense to assert this?

`block_for_addr` does `align_down` implicitly. It's true that all callers provide aligned `start_addr`, but it feels odd that only one end is asserted aligned. Besides, this method doesn't really rely (or depend) on args being aligned.

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

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


From kbarrett at openjdk.java.net  Tue Jan 11 17:13:27 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 11 Jan 2022 17:13:27 GMT
Subject: RFR: 8278581: Improve reference processing statistics log output
In-Reply-To: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
Message-ID: <Rl2pwONZv-3HLQ_N8dkKgdBs2PHjFIGiQ-YwpFt3Mv4=.8c6b55ac-70d0-4ea3-b2b9-e727cd39a3a9@github.com>

On Sat, 11 Dec 2021 15:04:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The first commit renames `Cleared` to `Dropped` and added `Processed` in the log output.
> 
> The second commit compressed the log output into one line per ref-type. The final log format looks like:
> 
> 
> [11.803s][debug][gc,phases,ref  ] GC(0)   SoftReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   WeakReference Discovered: 1147, Dropped: 752, Processed: 395
> [11.803s][debug][gc,phases,ref  ] GC(0)   FinalReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   PhantomReference Discovered: 242, Dropped: 2, Processed: 240
> 
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From sjohanss at openjdk.java.net  Wed Jan 12 08:12:28 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 12 Jan 2022 08:12:28 GMT
Subject: RFR: 8278581: Improve reference processing statistics log output
In-Reply-To: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
Message-ID: <mZds19Gw4ztwqOdALhLfkvSrk1H9rTIyk8Wet6uBJ_o=.35d9acda-0228-4424-a141-b56c94e42d7c@github.com>

On Sat, 11 Dec 2021 15:04:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The first commit renames `Cleared` to `Dropped` and added `Processed` in the log output.
> 
> The second commit compressed the log output into one line per ref-type. The final log format looks like:
> 
> 
> [11.803s][debug][gc,phases,ref  ] GC(0)   SoftReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   WeakReference Discovered: 1147, Dropped: 752, Processed: 395
> [11.803s][debug][gc,phases,ref  ] GC(0)   FinalReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   PhantomReference Discovered: 242, Dropped: 2, Processed: 240
> 
> 
> Test: hotspot_gc

Marked as reviewed by sjohanss (Reviewer).

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

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


From ayang at openjdk.java.net  Wed Jan 12 08:32:27 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 12 Jan 2022 08:32:27 GMT
Subject: RFR: 8278581: Improve reference processing statistics log output
In-Reply-To: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
Message-ID: <xHAcWYALzJvE_2E8CCr1K4QsyRyvphwK_ZAHagBtEQw=.317c8e77-20f5-4308-b26e-756b1b8d217e@github.com>

On Sat, 11 Dec 2021 15:04:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The first commit renames `Cleared` to `Dropped` and added `Processed` in the log output.
> 
> The second commit compressed the log output into one line per ref-type. The final log format looks like:
> 
> 
> [11.803s][debug][gc,phases,ref  ] GC(0)   SoftReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   WeakReference Discovered: 1147, Dropped: 752, Processed: 395
> [11.803s][debug][gc,phases,ref  ] GC(0)   FinalReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   PhantomReference Discovered: 242, Dropped: 2, Processed: 240
> 
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Jan 12 08:32:27 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 12 Jan 2022 08:32:27 GMT
Subject: Integrated: 8278581: Improve reference processing statistics log
 output
In-Reply-To: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
Message-ID: <yxPaaSxRfAEKiUT-cXW6xDh_AQoXx1mSWhZxA1qfczA=.0f39f2da-84b4-4fbe-a29f-fc53eec7e3c6@github.com>

On Sat, 11 Dec 2021 15:04:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The first commit renames `Cleared` to `Dropped` and added `Processed` in the log output.
> 
> The second commit compressed the log output into one line per ref-type. The final log format looks like:
> 
> 
> [11.803s][debug][gc,phases,ref  ] GC(0)   SoftReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   WeakReference Discovered: 1147, Dropped: 752, Processed: 395
> [11.803s][debug][gc,phases,ref  ] GC(0)   FinalReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   PhantomReference Discovered: 242, Dropped: 2, Processed: 240
> 
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 4f0b6502
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4f0b65023f8f37ba59a6397d8caf6b4b86ab18b7
Stats:     22 lines in 4 files changed: 8 ins; 3 del; 11 mod

8278581: Improve reference processing statistics log output

Reviewed-by: tschatzl, kbarrett, sjohanss

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

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


From mli at openjdk.java.net  Wed Jan 12 08:36:44 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 12 Jan 2022 08:36:44 GMT
Subject: RFR: 8279910: G1: Simplify HeapRegionRemSet::add_reference
Message-ID: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>

HeapRegionRemSet::add_reference checks "state == Untracked" and return if true; it's called at G1RebuildRemSetClosure::do_oop_work and G1ConcurrentRefineOopClosure::do_oop_work respectively.

The check in HeapRegionRemSet::add_reference could be replaced with an assert, and move the check up to one of the caller G1RebuildRemSetClosure::do_oop_work.

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

Commit messages:
 - Initial commit

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

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


From pliden at openjdk.java.net  Wed Jan 12 08:53:27 2022
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 12 Jan 2022 08:53:27 GMT
Subject: RFR: 8278581: Improve reference processing statistics log output
In-Reply-To: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
Message-ID: <tWpl3rQerlHCyqT-SwOM0EG4rbApOPHg8dGn5n3cIXc=.edfd5d88-1e48-4091-9951-bdb677a9459b@github.com>

On Sat, 11 Dec 2021 15:04:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The first commit renames `Cleared` to `Dropped` and added `Processed` in the log output.
> 
> The second commit compressed the log output into one line per ref-type. The final log format looks like:
> 
> 
> [11.803s][debug][gc,phases,ref  ] GC(0)   SoftReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   WeakReference Discovered: 1147, Dropped: 752, Processed: 395
> [11.803s][debug][gc,phases,ref  ] GC(0)   FinalReference Discovered: 0, Dropped: 0, Processed: 0
> [11.803s][debug][gc,phases,ref  ] GC(0)   PhantomReference Discovered: 242, Dropped: 2, Processed: 240
> 
> 
> Test: hotspot_gc

A bit late to the party, and maybe not directly related to your change, but I just thought I should mention that the output in ZGC looks like this:

[1.813s][info][gc,ref         ] GC(0) Soft: 87 encountered, 0 discovered, 0 enqueued
[1.813s][info][gc,ref         ] GC(0) Weak: 246 encountered, 83 discovered, 82 enqueued
[1.813s][info][gc,ref         ] GC(0) Final: 2 encountered, 0 discovered, 0 enqueued
[1.813s][info][gc,ref         ] GC(0) Phantom: 53 encountered, 48 discovered, 36 enqueued

IMHO, "enqueued" is a better name than "Processed" in this context (you could argue that all references goes through some level of processing, not just the ones that are eventually enqueued). Having "dropped" seems superfluous to me. Also, having "encountered" is useful to see how many there are in total.

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

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


From ayang at openjdk.java.net  Wed Jan 12 11:18:31 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 12 Jan 2022 11:18:31 GMT
Subject: RFR: 8278581: Improve reference processing statistics log output
In-Reply-To: <tWpl3rQerlHCyqT-SwOM0EG4rbApOPHg8dGn5n3cIXc=.edfd5d88-1e48-4091-9951-bdb677a9459b@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
 <tWpl3rQerlHCyqT-SwOM0EG4rbApOPHg8dGn5n3cIXc=.edfd5d88-1e48-4091-9951-bdb677a9459b@github.com>
Message-ID: <-mb7x-j29xH89WxuD5LMHUEp53ybZ5HAU5cOYlLIcDY=.a2347697-554f-4058-b93b-8ac6e6bfe910@github.com>

On Wed, 12 Jan 2022 08:49:32 GMT, Per Liden <pliden at openjdk.org> wrote:

> "enqueued" is a better name than "Processed" in this context

"enqueued" could be misleading due to its similarity with `Reference::enqueue()/ReferenceQueue` though.

> Having "dropped" seems superfluous to me.

Kim prefers having all three metrics, so I went for the current approach. (I agree there's some redundancy here.)

"Having all 3 of Discovered, Dropped (though with a better name?), and Processed would be nice since it avoids needing to calculate one from the other two."

> having "encountered" is useful to see how many there are in total.

True, but I am not sure how useful "knowing the total #refs" is. After all, only discovered-ref affects the duration of ref-processing. Ref-encountering happens along with marking, but #encountered doesn't directly affect marking phase duration.

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

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


From iwalulya at openjdk.java.net  Wed Jan 12 13:24:34 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 12 Jan 2022 13:24:34 GMT
Subject: [jdk18] RFR: 8274007: [REDO] VM Exit does not abort concurrent
 mark [v2]
In-Reply-To: <DBbSWPIg4Qgoya2hBmAJ2f31U4FH6Fj9IU5JqOdJtnc=.9c27db79-b3f1-448b-975d-ab9bac2edcc7@github.com>
References: <zVfEOttCwDSit--DdPt2B1vIDS0GuW9oXXTLtLphJnw=.3b61125e-7f25-41a1-aa94-b61dd6700220@github.com>
 <DBbSWPIg4Qgoya2hBmAJ2f31U4FH6Fj9IU5JqOdJtnc=.9c27db79-b3f1-448b-975d-ab9bac2edcc7@github.com>
Message-ID: <beQQJXuTv27fjJnFwQ92yF79nQGpLktcHV2HT-mne-U=.adeb8869-170d-4ed8-a36f-347f7a497f75@github.com>

On Thu, 16 Dec 2021 10:21:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that redos JDK-8273605 that implemented faster abort of concurrent marking when the VM is about to shutdown?
>> 
>> In the earlier change (first commit in this change) had the following issues:
>>   * it tried to abort (set the abort flag) marking even when root region scanning was active; this is something G1 does not support. In this change we cancel and wait for completion of that phase instead.
>>   * the second problem has been in `G1ConcurrentMark::concurrent_cycle_abort`: if a full gc were triggered during VM shutdown, the next bitmap would not be cleared. I.e. the condition to skip the rest of the mark abort handling (in `concurrent_cycle_abort`) in the full gc pause has been wrong.
>>  The first part `!cm_thread()->in_progress()` is correct, but the `|| _has_aborted` part is bad: aborting the marking (as in aborting during shutdown, what this change wants to achieve) does not clear the (next) mark bitmap at all with that condition. This is actually a long standing issue: however since nobody aborted the marking early except full gc (where we are in the moment), this path has never been taken, so afaict no harm done. (Global mark stack overflow causes abort of the *mark task*, and overflow of the *mark state*). Another issue with using `_has_aborted` here is that `_has_aborted` might have already been cleared when the full gc occurs: i.e. we abort the marking, it finishes its marking cycle (clearing `_has_aborted`) and only then that full gc happens.
>> The correct way is to keep on clearing the next bitmap (for the full gc(s)) if we aborted the marking due to shutdown (`_g1h->concurrent_mark_is_terminating()`).
>> This has the disadvantage that not only the first full gc during shutdown clears the next bitmap, but also any subsequent full gcs (concurrent marking is already prohibited to start during shutdown), and they do that unnecessarily.
>> However any change here (like keeping a flag whether the next bitmap is dirty) seemed to be an unnecessary complication unsuitable for such a change, and any full gc will be much longer than clearing the bitmap once anyway).
>> Another alternative that has been considered has been making an explicit shutdown state in `G1ConcurrentMarkThread`; however that would mirror functionality provided in `ConcurrentGCThread`, which does not improve the code, or at least at this time I would prefer not to change something there.
>>  
>> Testing: hs-tier1-5,  vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java a few thousand times without issue (both on jdk18 and jdk19)
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sjohanss review

Marked as reviewed by iwalulya (Reviewer).

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

PR: https://git.openjdk.java.net/jdk18/pull/22


From pliden at openjdk.java.net  Wed Jan 12 14:09:25 2022
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 12 Jan 2022 14:09:25 GMT
Subject: RFR: 8278581: Improve reference processing statistics log output
In-Reply-To: <-mb7x-j29xH89WxuD5LMHUEp53ybZ5HAU5cOYlLIcDY=.a2347697-554f-4058-b93b-8ac6e6bfe910@github.com>
References: <z746d28vWoSuPcr4OeYv6eYt1qFMX28gGuU7L8cLWvM=.fd95b0f0-7ef6-4cfd-9813-d8fb2f9cf614@github.com>
 <tWpl3rQerlHCyqT-SwOM0EG4rbApOPHg8dGn5n3cIXc=.edfd5d88-1e48-4091-9951-bdb677a9459b@github.com>
 <-mb7x-j29xH89WxuD5LMHUEp53ybZ5HAU5cOYlLIcDY=.a2347697-554f-4058-b93b-8ac6e6bfe910@github.com>
Message-ID: <1utCCWdqblKYKPQa-3Eaw-o3TaDeTge0Xdm7em_ybGo=.03dc0af8-d8aa-46a8-bd68-2682390af091@github.com>

On Wed, 12 Jan 2022 11:15:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> "enqueued" could be misleading due to its similarity with Reference::enqueue()/ReferenceQueue though.

I actually think it's a good that it eludes to Reference::enqueue(). Even if the enqueuing onto the ReferenceQueue happens in the next step, the enqueuing onto the pending list is the precursor.

> True, but I am not sure how useful "knowing the total #refs" is. After all, only discovered-ref affects the duration of ref-processing. Ref-encountering happens along with marking, but #encountered doesn't directly affect marking phase duration.

I've found "encountered" to be very useful when debugging.

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

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


From duke at openjdk.java.net  Thu Jan 13 00:30:51 2022
From: duke at openjdk.java.net (aamarsh)
Date: Thu, 13 Jan 2022 00:30:51 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
Message-ID: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>

Please review this small change to revert a previous workaround that avoided an MSVC issue. 

This issue has now been fixed in VS 16.8 and higher. 

I also updated some documentation to reflect this change.

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

Commit messages:
 - reverted windows/aarch64 workaround and added to documentation

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

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


From tschatzl at openjdk.java.net  Thu Jan 13 08:46:35 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 Jan 2022 08:46:35 GMT
Subject: [jdk18] RFR: 8274007: [REDO] VM Exit does not abort concurrent
 mark [v2]
In-Reply-To: <rA8lNqSNCI3Fx8oD-3mveAsKB5pM7I2CT6PZxAJNIxU=.dc4cbfc3-cde6-443a-a95c-769d61483813@github.com>
References: <zVfEOttCwDSit--DdPt2B1vIDS0GuW9oXXTLtLphJnw=.3b61125e-7f25-41a1-aa94-b61dd6700220@github.com>
 <rA8lNqSNCI3Fx8oD-3mveAsKB5pM7I2CT6PZxAJNIxU=.dc4cbfc3-cde6-443a-a95c-769d61483813@github.com>
Message-ID: <q6AfN-rtkqTgCOr_Qhehut8dVPyKgY5hZ_xx71syX7A=.5dfb0b1c-51be-45d5-9d8c-c7dd5593c367@github.com>

On Thu, 16 Dec 2021 09:04:05 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   sjohanss review
>
> Looks good, just a comment about maybe improving a comment even more.

Thanks @kstefanj @walulyai for your reviews.

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

PR: https://git.openjdk.java.net/jdk18/pull/22


From tschatzl at openjdk.java.net  Thu Jan 13 08:46:36 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 Jan 2022 08:46:36 GMT
Subject: [jdk18] Integrated: 8274007: [REDO] VM Exit does not abort concurrent
 mark
In-Reply-To: <zVfEOttCwDSit--DdPt2B1vIDS0GuW9oXXTLtLphJnw=.3b61125e-7f25-41a1-aa94-b61dd6700220@github.com>
References: <zVfEOttCwDSit--DdPt2B1vIDS0GuW9oXXTLtLphJnw=.3b61125e-7f25-41a1-aa94-b61dd6700220@github.com>
Message-ID: <fbwcWuYRDcksMKBqo9Wh0w5hkEapLp_caLlAP2YqMiM=.afaab4d2-5eb5-4357-b1fd-3797ce1698c8@github.com>

On Tue, 14 Dec 2021 12:37:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that redos JDK-8273605 that implemented faster abort of concurrent marking when the VM is about to shutdown?
> 
> In the earlier change (first commit in this change) had the following issues:
>   * it tried to abort (set the abort flag) marking even when root region scanning was active; this is something G1 does not support. In this change we cancel and wait for completion of that phase instead.
>   * the second problem has been in `G1ConcurrentMark::concurrent_cycle_abort`: if a full gc were triggered during VM shutdown, the next bitmap would not be cleared. I.e. the condition to skip the rest of the mark abort handling (in `concurrent_cycle_abort`) in the full gc pause has been wrong.
>  The first part `!cm_thread()->in_progress()` is correct, but the `|| _has_aborted` part is bad: aborting the marking (as in aborting during shutdown, what this change wants to achieve) does not clear the (next) mark bitmap at all with that condition. This is actually a long standing issue: however since nobody aborted the marking early except full gc (where we are in the moment), this path has never been taken, so afaict no harm done. (Global mark stack overflow causes abort of the *mark task*, and overflow of the *mark state*). Another issue with using `_has_aborted` here is that `_has_aborted` might have already been cleared when the full gc occurs: i.e. we abort the marking, it finishes its marking cycle (clearing `_has_aborted`) and only then that full gc happens.
> The correct way is to keep on clearing the next bitmap (for the full gc(s)) if we aborted the marking due to shutdown (`_g1h->concurrent_mark_is_terminating()`).
> This has the disadvantage that not only the first full gc during shutdown clears the next bitmap, but also any subsequent full gcs (concurrent marking is already prohibited to start during shutdown), and they do that unnecessarily.
> However any change here (like keeping a flag whether the next bitmap is dirty) seemed to be an unnecessary complication unsuitable for such a change, and any full gc will be much longer than clearing the bitmap once anyway).
> Another alternative that has been considered has been making an explicit shutdown state in `G1ConcurrentMarkThread`; however that would mirror functionality provided in `ConcurrentGCThread`, which does not improve the code, or at least at this time I would prefer not to change something there.
>  
> Testing: hs-tier1-5,  vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java a few thousand times without issue (both on jdk18 and jdk19)

This pull request has now been integrated.

Changeset: 33814791
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/33814791d917b0c09909bf19b432dd8dfc6cd9db
Stats:     36 lines in 3 files changed: 29 ins; 1 del; 6 mod

8274007: [REDO] VM Exit does not abort concurrent mark

Reviewed-by: sjohanss, iwalulya

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

PR: https://git.openjdk.java.net/jdk18/pull/22


From erikj at openjdk.java.net  Thu Jan 13 14:13:26 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 13 Jan 2022 14:13:26 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <k8aVa43-O1advLWV3TpXYKYH3Q1CIEcegKgNIt3fBmg=.4e26dd0c-9315-462a-8c86-b7434a739950@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

Marked as reviewed by erikj (Reviewer).

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

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


From sjohanss at openjdk.java.net  Thu Jan 13 15:28:29 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 13 Jan 2022 15:28:29 GMT
Subject: RFR: 8279699: Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
References: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
Message-ID: <GaQ0wA3vr9x8Of-nNPhvCkFTMaxyCTltKSM81km79sU=.f84dd22e-cfc6-4780-85af-c4aff33708f2@github.com>

On Mon, 10 Jan 2022 15:50:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change in boundary condition checking and updating the API doc.
> 
> Test: hotspot_gc

Marked as reviewed by sjohanss (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Jan 13 17:24:40 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 13 Jan 2022 17:24:40 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <s4cHNM85u-0zpCbevYdM_wsyQvOXbRS-GyLci3i96Dw=.ceedaac2-fc2a-44d2-bc83-f1949a999db5@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

GC changes look good.

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

Marked as reviewed by tschatzl (Reviewer).

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


From mli at openjdk.java.net  Fri Jan 14 01:46:28 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 14 Jan 2022 01:46:28 GMT
Subject: RFR: 8279699: Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
References: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
Message-ID: <jAvksjmdjaTmdjchFvF2NGOi1hEdwwe2Y950fAXgSVA=.3ffd1fe6-eef2-401d-86fa-e1828fe80b08@github.com>

On Mon, 10 Jan 2022 15:50:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change in boundary condition checking and updating the API doc.
> 
> Test: hotspot_gc

looks good

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

Marked as reviewed by mli (Reviewer).

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


From mli at openjdk.java.net  Fri Jan 14 01:51:21 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 14 Jan 2022 01:51:21 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <_nHW8kORImeQlf40ntU2l73jfaEQvUwsAQhBpD3LznI=.a16be953-1f13-46e0-93ca-43de15465ec1@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

looks good

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

Marked as reviewed by mli (Reviewer).

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


From ayang at openjdk.java.net  Fri Jan 14 07:51:30 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 07:51:30 GMT
Subject: RFR: 8279699: Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
References: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
Message-ID: <g2j1dZP9vHcCEf7KfGTiyTnw9WVdDD-Gs9qMn1jQLfo=.feb345a5-a7b9-45fd-b57b-60c4a2417a29@github.com>

On Mon, 10 Jan 2022 15:50:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change in boundary condition checking and updating the API doc.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Fri Jan 14 07:51:30 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 07:51:30 GMT
Subject: Integrated: 8279699: Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
References: <r4xrIZ9pxYDagNURr8PK4raR9wnQP4_veeSFy9YGNII=.0434b8d6-9570-4ccf-970c-b3f12b12b9f5@github.com>
Message-ID: <ZqRAYnyYnWWqMWS0KbE18EGZZvU8xieMN2nyFpDOzZU=.4a222668-9281-4106-a451-b3fa1f472f3e@github.com>

On Mon, 10 Jan 2022 15:50:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change in boundary condition checking and updating the API doc.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 965c64bc
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/965c64bca713446e7e513170aa9138a8a5eec5de
Stats:     7 lines in 2 files changed: 2 ins; 0 del; 5 mod

8279699: Parallel: More precise boundary in ObjectStartArray::object_starts_in_range

Reviewed-by: sjohanss, mli

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

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


From ayang at openjdk.java.net  Fri Jan 14 08:12:05 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 08:12:05 GMT
Subject: RFR: 8280000: Remove unused CardTable::find_covering_region_containing
Message-ID: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>

Trivial change of removing dead code.

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

Commit messages:
 - trivial

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

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


From tschatzl at openjdk.java.net  Fri Jan 14 08:23:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 14 Jan 2022 08:23:42 GMT
Subject: RFR: 8280000: Remove unused
 CardTable::find_covering_region_containing
In-Reply-To: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
References: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
Message-ID: <LwQKsaT2WxbglvXFdfZishnW9-KFUf1CzgB9DJP_Q9M=.a756e683-05e8-4063-868d-d90dc0b1226f@github.com>

On Fri, 14 Jan 2022 08:05:07 GMT, Albert Mingkun Yang <ayang 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/7074


From mli at openjdk.java.net  Fri Jan 14 08:30:45 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 14 Jan 2022 08:30:45 GMT
Subject: RFR: 8256265 G1: Improve parallelism in regions that failed
 evacuation [v2]
In-Reply-To: <DzKhshoSHzxlETsGW26sxmI1ZNmqq4o7Z1dNEoUFAuw=.8f7d04eb-a047-493c-803d-e3ee61515dae@github.com>
References: <pgOskFPQeIhWfIqQJYz1YnJXeoEgWpOQI9dYr1jdN9Y=.af95d8b5-d9ef-4ddc-80ec-dc361d33ba33@github.com>
 <DzKhshoSHzxlETsGW26sxmI1ZNmqq4o7Z1dNEoUFAuw=.8f7d04eb-a047-493c-803d-e3ee61515dae@github.com>
Message-ID: <I5i4GU19MnUHaa47R_Sy4zwxODneBN5jAQmMaegzwx8=.69eab8c7-5cae-4dd8-916b-a4c8f47daf65@github.com>

On Thu, 2 Dec 2021 01:51:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Summary
>> -------
>> 
>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> Try to improve the parallelsim when walking over the regions by 
>> 
>>  - first, split a region into tasks;
>>  - then, process these task in parallel and load balance among GC threads;
>>  - last, necessary cleanup
>> 
>> NOTE: load balance part of code is almost same as G1ParScanThreadState, if necessary and feasible, consider to refactor this part into a shared code base.
>> 
>> Performance Test
>> -------
>> 
>> The perf test based on lastest implementation + JDK-8277736 shows that:
>> 
>>  - when `ParallelGCThreads`=32, when `G1EvacuationFailureALotCSetPercent` <= 50, the parallelism bring more benefit than regression;
>> - when `ParallelGCThreads`=128, whatever `G1EvacuationFailureALotCSetPercent` is, the parallelism bring more benefit than regression;
>> 
>> other related evac failure vm options:
>>  - `G1EvacuationFailureALotInterval`=1
>>  - `G1EvacuationFailureALotCount`=1
>> 
>> For detailed perf test result, please check:
>> 
>>  - https://bugs.openjdk.java.net/secure/attachment/97227/parallel.evac.failure-threads.32.png
>>  - https://bugs.openjdk.java.net/secure/attachment/97228/parallel.evac.failure-threads.128.png
>>  
>> For the situation like G1EvacuationFailureALotCSetPercent > 50 and ParallelGCThreads=32 , we could fall back to current implmentation, or further optimize the thread sizing at this phase if necessary.
>> 
>> NOTE: I don't include perf data for `Remove Self Forwards`, because the comparison of pause time in this phase does not well show the improvement of this implementation, I think the reason is that the original implementation is not load balanced, and the new implementation is. But as `Remove Self Forwards` is part of `Post Evacuate Cleanup 1`, so only `Post Evacuate Cleanup 1` well show the improvement of the new implementation.
>> It could be a potential improvement to refine the Pause time data in `Remove Self Forwards` phase.
>
> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into parallelize-evac-failure
>  - Adjust worker cost by a factor; initialize task queues set and terminator threads by active workers
>  - Fix wrong merge
>  - Merge with master
>  - Remove and merge code of G1ParRemoveSelfForwardPtrsTask into RemoveSelfForwardPtrsTask
>  - Fix crashes in ~G1GCParPhaseTimesTracker(), G1PreRemoveSelfForwardClosure::do_heap_region, G1CollectedHeap::par_iterate_regions_array()=>~StubRoutines::atomic entry points; Refine comments
>  - Fix inconsistent length between task queues and terminator
>  - Fix crash when heap verification; Fix compilation error; Refine comments
>  - Initial commit

I've created a draft PR at #7047, this one will be closed.

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

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


From ayang at openjdk.java.net  Fri Jan 14 08:32:41 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 08:32:41 GMT
Subject: RFR: 8280001: Serial: Add documentation to heap memory layout
Message-ID: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>

Comments-only change of adding some documentation.

Test: build

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

Commit messages:
 - serial-heap-layout

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

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


From mli at openjdk.java.net  Fri Jan 14 08:54:26 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 14 Jan 2022 08:54:26 GMT
Subject: RFR: 8280001: Serial: Add documentation to heap memory layout
In-Reply-To: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
References: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
Message-ID: <THf1IBWO2tfie7tKLU5chzJoKIReyVFwYx-OJkgW73c=.cd61fcd2-1f82-4ae4-9042-13171fb8ea59@github.com>

On Fri, 14 Jan 2022 08:26:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Comments-only change of adding some documentation.
> 
> Test: build

I like it, thanks!

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

Marked as reviewed by mli (Reviewer).

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


From sjohanss at openjdk.java.net  Fri Jan 14 11:12:35 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 14 Jan 2022 11:12:35 GMT
Subject: RFR: 8280001: Serial: Add documentation to heap memory layout
In-Reply-To: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
References: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
Message-ID: <Miydu50-MpBtvGvqNIocQs9-FhNaYu4_dAyWH_k6L0s=.10a5a784-96a2-4481-beec-bc35daf8f893@github.com>

On Fri, 14 Jan 2022 08:26:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Comments-only change of adding some documentation.
> 
> Test: build

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Fri Jan 14 11:15:26 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 14 Jan 2022 11:15:26 GMT
Subject: RFR: 8280000: Remove unused
 CardTable::find_covering_region_containing
In-Reply-To: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
References: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
Message-ID: <VVMkE40cMeda-jq6Blx3t6GNTIUpkxY91o8paCQLHG8=.70ca9b97-ced4-4ce9-acd1-9df5663f0073@github.com>

On Fri, 14 Jan 2022 08:05:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.

Marked as reviewed by sjohanss (Reviewer).

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

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


From ayang at openjdk.java.net  Fri Jan 14 12:39:42 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 12:39:42 GMT
Subject: RFR: 8280000: Remove unused
 CardTable::find_covering_region_containing
In-Reply-To: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
References: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
Message-ID: <-jM-n-0iujJPNgVaed7tDR1mCrGP5YzQve-CCRI380c=.f295f5ce-3180-40af-b1f0-eb91109f645c@github.com>

On Fri, 14 Jan 2022 08:05:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.

Thanks for the review.

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

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


From ayang at openjdk.java.net  Fri Jan 14 12:39:42 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 12:39:42 GMT
Subject: Integrated: 8280000: Remove unused
 CardTable::find_covering_region_containing
In-Reply-To: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
References: <Yk0QvHWcLbeMB3Q_XTZohgCRq3TBGOtcqL5QDl0j_Bc=.e38b8800-30f1-49b0-ae64-8ac03f43fc7e@github.com>
Message-ID: <a81Q0LADhUSe_4SQbW3VvAt-1Zl2CqC8R3Ok08JGJ6U=.e9605e21-aa0d-4dc0-b140-aca5fe95031a@github.com>

On Fri, 14 Jan 2022 08:05:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.

This pull request has now been integrated.

Changeset: dd76a28d
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dd76a28d441e01b1993a71de67ace58bcb67acc8
Stats:     14 lines in 2 files changed: 0 ins; 14 del; 0 mod

8280000: Remove unused CardTable::find_covering_region_containing

Reviewed-by: tschatzl, sjohanss

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

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


From tschatzl at openjdk.java.net  Fri Jan 14 12:49:27 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 14 Jan 2022 12:49:27 GMT
Subject: RFR: 8280001: Serial: Add documentation to heap memory layout
In-Reply-To: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
References: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
Message-ID: <_9Pb4bLlJ99kbxUxp_wDZ-biUrHOL4uJkj_gub_GW8k=.e456f519-568a-45e8-a486-68f7ffdae029@github.com>

On Fri, 14 Jan 2022 08:26:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Comments-only change of adding some documentation.
> 
> Test: build

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/serial/serialHeap.hpp line 55:

> 53: // |       eden      |  from  |   to   |        |      old      |                   |
> 54: // |                 |  (to)  | (from) |        |               |                   |
> 55: // +-----------------+--------+--------+--------+---------------+-------------------+

Unfortunately, the young gen contents are shown wrongly: from/to space are of fixed size and adjacent to the generation boundary.
There is no space between to-space and old gen.
Eden, from and to-space are committed separately within their space and never move.

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

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


From tschatzl at openjdk.java.net  Fri Jan 14 13:13:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 14 Jan 2022 13:13:34 GMT
Subject: RFR: 8279910: G1: Simplify HeapRegionRemSet::add_reference
In-Reply-To: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
References: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
Message-ID: <JzOVwe5z1hwrxGOz2WBgn2WY_JGKCFqLhC0chKrIT6I=.65df1eae-a35a-48f0-b3d7-a64265c5fdf6@github.com>

On Wed, 12 Jan 2022 08:29:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

> HeapRegionRemSet::add_reference checks "state == Untracked" and return if true; it's called at G1RebuildRemSetClosure::do_oop_work and G1ConcurrentRefineOopClosure::do_oop_work respectively.
> 
> The check in HeapRegionRemSet::add_reference could be replaced with an assert, and move the check up to one of the caller G1RebuildRemSetClosure::do_oop_work.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From shade at openjdk.java.net  Fri Jan 14 13:32:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 14 Jan 2022 13:32:47 GMT
Subject: RFR: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large
 machines
Message-ID: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>

See the bug for more details. I would prefer to test the upper boundary for current `G1ConcRSLogCacheSize`.

Additional testing: 
  - [x] Affected/amended test starts to pass

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

Commit messages:
 - Fix

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

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


From tschatzl at openjdk.java.net  Fri Jan 14 13:46:25 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 14 Jan 2022 13:46:25 GMT
Subject: RFR: 8280001: Serial: Add documentation to heap memory layout
In-Reply-To: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
References: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
Message-ID: <jSmOCJittjNpsnhq2FI9QoxmLjcwUJDR4Yu2AgfU1pU=.0592b9a2-3765-467b-a95f-14e8fbded353@github.com>

On Fri, 14 Jan 2022 08:26:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Comments-only change of adding some documentation.
> 
> Test: build

Having had another look at the code, lgtm. Sorry for the confusion.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Jan 14 14:04:28 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 14 Jan 2022 14:04:28 GMT
Subject: RFR: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large
 machines
In-Reply-To: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
References: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
Message-ID: <ak5YnRYZw3FdtTCaBNN21KESwPSRHDb-hZmHGiDuqHg=.2fb5786b-e5b7-494a-b14e-0a95d24c31c0@github.com>

On Fri, 14 Jan 2022 13:24:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more details. I would prefer to test the upper boundary for current `G1ConcRSLogCacheSize`.
> 
> Additional testing: 
>   - [x] Affected/amended test starts to pass

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Fri Jan 14 14:47:28 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 14:47:28 GMT
Subject: RFR: 8279910: G1: Simplify HeapRegionRemSet::add_reference
In-Reply-To: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
References: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
Message-ID: <3quQbH6LjWr6U53v-hFMng8-D9h3RkDgY8RsHYqn-qg=.06bc0413-46c7-4740-b152-5bfa4cdf52ec@github.com>

On Wed, 12 Jan 2022 08:29:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

> HeapRegionRemSet::add_reference checks "state == Untracked" and return if true; it's called at G1RebuildRemSetClosure::do_oop_work and G1ConcurrentRefineOopClosure::do_oop_work respectively.
> 
> The check in HeapRegionRemSet::add_reference could be replaced with an assert, and move the check up to one of the caller G1RebuildRemSetClosure::do_oop_work.

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 126:

> 124: 
> 125: void HeapRegionRemSet::add_reference(OopOrNarrowOopStar from, uint tid) {
> 126:   assert(_state != Untracked, "must be");

I would prefer "precondition" in the assert msg.

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

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


From ayang at openjdk.java.net  Fri Jan 14 14:47:51 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 14:47:51 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary
 PSCardTable::resize_covered_region_by_end
Message-ID: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>

Simple change of removing effectively dead code.

Test: tier1-6

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

Commit messages:
 - resize_covered_region_by_end

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

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


From ayang at openjdk.java.net  Fri Jan 14 14:49:23 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 14:49:23 GMT
Subject: RFR: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large
 machines
In-Reply-To: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
References: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
Message-ID: <SyYy9WcjJrxmbu_Mk40Lz6BKiZDvT7mdSXbKbgSu99E=.06388f6e-e65f-489a-ae47-f9d5ff93d3bc@github.com>

On Fri, 14 Jan 2022 13:24:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more details. I would prefer to test the upper boundary for current `G1ConcRSLogCacheSize`.
> 
> Additional testing: 
>   - [x] Affected/amended test starts to pass

Marked as reviewed by ayang (Reviewer).

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

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


From ayang at openjdk.java.net  Fri Jan 14 15:58:47 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 15:58:47 GMT
Subject: Integrated: 8280028: [BACKOUT] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
Message-ID: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>

Reverting a commit to solve failures on tier3.

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

Commit messages:
 - Revert "8279699: Parallel: More precise boundary in ObjectStartArray::object_starts_in_range"

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

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


From sjohanss at openjdk.java.net  Fri Jan 14 15:58:48 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 14 Jan 2022 15:58:48 GMT
Subject: Integrated: 8280028: [BACKOUT] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>
References: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>
Message-ID: <8rhITPUK4jfEizbfIcMmzB0yLYovVlISty7jjy9w4Xg=.2bbf2440-87e0-44fb-bd78-6ebeab366427@github.com>

On Fri, 14 Jan 2022 15:44:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Reverting a commit to solve failures on tier3.

Backout looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From ayang at openjdk.java.net  Fri Jan 14 15:58:49 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 15:58:49 GMT
Subject: Integrated: 8280028: [BACKOUT] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>
References: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>
Message-ID: <ZOrmMwGDpbhKxVLLXl5gFnQeBY-_e1Mw1Mcl1bEeK4Y=.bf639cfc-3818-405f-b9a9-0f12722cfb65@github.com>

On Fri, 14 Jan 2022 15:44:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Reverting a commit to solve failures on tier3.

Thank you for the quick review. Merging it right away to solve tier3 failures.

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

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


From ayang at openjdk.java.net  Fri Jan 14 15:58:50 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 14 Jan 2022 15:58:50 GMT
Subject: Integrated: 8280028: [BACKOUT] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>
References: <ZTsWTDW6DGpKtNhUthN7Ph64o6n9lgVwyW1z8vpyYYo=.2646ba66-c959-438e-ae33-b651fecae3ec@github.com>
Message-ID: <mB6kPHSE2aCKyGGviZh-LFs7-Iw2gcLH6mcgytnhRrs=.6858c03c-2322-410b-8b71-3312f8b95a18@github.com>

On Fri, 14 Jan 2022 15:44:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Reverting a commit to solve failures on tier3.

This pull request has now been integrated.

Changeset: ac98b220
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac98b22040f854de79813a1c2a97fc399d3bcc42
Stats:     7 lines in 2 files changed: 0 ins; 2 del; 5 mod

8280028: [BACKOUT] Parallel: More precise boundary in ObjectStartArray::object_starts_in_range

Reviewed-by: sjohanss

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

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


From kbarrett at openjdk.java.net  Sun Jan 16 18:25:57 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 16 Jan 2022 18:25:57 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
Message-ID: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>

Please review this fix of an ABA problem in G1DirtyCardQueueSet's use of
NonblockingQueue. 

Consider queue q contains one entry, `X`.

Thread1 begins a push/append operation. WOLG, assume a push of `Y`. It
atomically exchanges `q._tail` with `Y`, retaining the old value of `q._tail`,
which is `X`. Pause Thread1 here.

Thread2 pops `X` from the queue. It successfully changes `X._next` from
end-marker to null and `q._head` from `X` to null. Thread2 fails to change
`q._tail` from `X` to null, as Thread1 already changed it to `Y`.

Various threads add entries to the queue after `Y`, and various threads try to
pop entries and find the queue "empty" because `q._head` will remain null
until Thread1 proceeds.

In parallel with entries being added, Thread2 processes `X` and releases it
for reuse. Some thread reallocates it, fills it, and pushes it onto the
queue. We now have a chain from `Y` => `X` in `q._tail` with `q._head` still
null.

If Thread1 resumes at that point, it finds `X._next` == end-marker,
successfully changes it to `Y`, and "completes". We now have `q._head` == null
and `q._tail` == `X`, with `X` => `Y` => `X`. The next push/append will
observe `q._tail` of `X` having a non-end-marker `_next` and change both
`q._head` and `q._tail`, dropping the list containing `X`, `Y`, &etc on the
floor.

There may be other similarly bad scenarios, depending on exactly what is going
on when Thread1 resumes.

All of these are fixed by performing the push operation in a critical section,
so that `X` cannot be reused until the push that is observing it
completes. That is, in `DirtyCardQueueSet::enqueue_completed_buffer`, put
`_completed.push(*cbn);` in a GlobalCounter critical section.

Testing:
mach5 tier1

Running the failing test with -XX:G1UpdateBufferSize=3 was failing at a rate
of about 1/1K runs of the test.  With this change, there were no failures in
more than 60K runs.

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

Commit messages:
 - DCQS push buffers inside CS

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From shade at openjdk.java.net  Mon Jan 17 08:20:30 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 17 Jan 2022 08:20:30 GMT
Subject: RFR: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large
 machines
In-Reply-To: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
References: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
Message-ID: <kw1dMuapII2jMBx7GpKpMecvEPhT84poEM4kqUoLbfA=.7444eee5-7359-43f0-8d2a-051aa8c5f875@github.com>

On Fri, 14 Jan 2022 13:24:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more details. I would prefer to test the upper boundary for current `G1ConcRSLogCacheSize`.
> 
> Additional testing: 
>   - [x] Affected/amended test starts to pass

Thanks! The test failure on x86_32 is unrelated.

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

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


From shade at openjdk.java.net  Mon Jan 17 08:20:31 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 17 Jan 2022 08:20:31 GMT
Subject: Integrated: 8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on
 large machines
In-Reply-To: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
References: <zgI2tNqwGdtXZyiCKmY0lpy3bmr82_5fPm1Y1-Hxou4=.dfc02f4d-ef43-451c-aa9d-ee3e69c56f3c@github.com>
Message-ID: <Cn2DoLe6HdGae3Vvo83m__C5EKLE2dX8Zvw6TSQboyU=.5f0045a9-02db-4341-8ada-ffc2b1cb8754@github.com>

On Fri, 14 Jan 2022 13:24:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more details. I would prefer to test the upper boundary for current `G1ConcRSLogCacheSize`.
> 
> Additional testing: 
>   - [x] Affected/amended test starts to pass

This pull request has now been integrated.

Changeset: 590eb860
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/590eb86033d5445018cd0e961e8721a20de4bb0c
Stats:     92 lines in 2 files changed: 46 ins; 46 del; 0 mod

8280016: gc/g1/TestShrinkAuxiliaryData30 test fails on large machines

Reviewed-by: tschatzl, ayang

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 08:24:29 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 08:24:29 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
Message-ID: <Ce9ZSCDFCXfBJ43EVxP4VkvTf1clUC2ynxVxUYAsQaQ=.e04957d4-76e8-40cd-8e55-20f63077ade1@github.com>

On Sun, 16 Jan 2022 18:20:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of an ABA problem in G1DirtyCardQueueSet's use of
> NonblockingQueue. 
> 
> Consider queue q contains one entry, `X`.
> 
> Thread1 begins a push/append operation. WOLG, assume a push of `Y`. It
> atomically exchanges `q._tail` with `Y`, retaining the old value of `q._tail`,
> which is `X`. Pause Thread1 here.
> 
> Thread2 pops `X` from the queue. It successfully changes `X._next` from
> end-marker to null and `q._head` from `X` to null. Thread2 fails to change
> `q._tail` from `X` to null, as Thread1 already changed it to `Y`.
> 
> Various threads add entries to the queue after `Y`, and various threads try to
> pop entries and find the queue "empty" because `q._head` will remain null
> until Thread1 proceeds.
> 
> In parallel with entries being added, Thread2 processes `X` and releases it
> for reuse. Some thread reallocates it, fills it, and pushes it onto the
> queue. We now have a chain from `Y` => `X` in `q._tail` with `q._head` still
> null.
> 
> If Thread1 resumes at that point, it finds `X._next` == end-marker,
> successfully changes it to `Y`, and "completes". We now have `q._head` == null
> and `q._tail` == `X`, with `X` => `Y` => `X`. The next push/append will
> observe `q._tail` of `X` having a non-end-marker `_next` and change both
> `q._head` and `q._tail`, dropping the list containing `X`, `Y`, &etc on the
> floor.
> 
> There may be other similarly bad scenarios, depending on exactly what is going
> on when Thread1 resumes.
> 
> All of these are fixed by performing the push operation in a critical section,
> so that `X` cannot be reused until the push that is observing it
> completes. That is, in `DirtyCardQueueSet::enqueue_completed_buffer`, put
> `_completed.push(*cbn);` in a GlobalCounter critical section.
> 
> Testing:
> mach5 tier1
> 
> Running the failing test with -XX:G1UpdateBufferSize=3 was failing at a rate
> of about 1/1K runs of the test.  With this change, there were no failures in
> more than 60K runs.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/104


From sjohanss at openjdk.java.net  Mon Jan 17 08:48:22 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 17 Jan 2022 08:48:22 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
Message-ID: <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>

On Sun, 16 Jan 2022 18:20:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of an ABA problem in G1DirtyCardQueueSet's use of
> NonblockingQueue. 
> 
> Consider queue q contains one entry, `X`.
> 
> Thread1 begins a push/append operation. WOLG, assume a push of `Y`. It
> atomically exchanges `q._tail` with `Y`, retaining the old value of `q._tail`,
> which is `X`. Pause Thread1 here.
> 
> Thread2 pops `X` from the queue. It successfully changes `X._next` from
> end-marker to null and `q._head` from `X` to null. Thread2 fails to change
> `q._tail` from `X` to null, as Thread1 already changed it to `Y`.
> 
> Various threads add entries to the queue after `Y`, and various threads try to
> pop entries and find the queue "empty" because `q._head` will remain null
> until Thread1 proceeds.
> 
> In parallel with entries being added, Thread2 processes `X` and releases it
> for reuse. Some thread reallocates it, fills it, and pushes it onto the
> queue. We now have a chain from `Y` => `X` in `q._tail` with `q._head` still
> null.
> 
> If Thread1 resumes at that point, it finds `X._next` == end-marker,
> successfully changes it to `Y`, and "completes". We now have `q._head` == null
> and `q._tail` == `X`, with `X` => `Y` => `X`. The next push/append will
> observe `q._tail` of `X` having a non-end-marker `_next` and change both
> `q._head` and `q._tail`, dropping the list containing `X`, `Y`, &etc on the
> floor.
> 
> There may be other similarly bad scenarios, depending on exactly what is going
> on when Thread1 resumes.
> 
> All of these are fixed by performing the push operation in a critical section,
> so that `X` cannot be reused until the push that is observing it
> completes. That is, in `DirtyCardQueueSet::enqueue_completed_buffer`, put
> `_completed.push(*cbn);` in a GlobalCounter critical section.
> 
> Testing:
> mach5 tier1
> 
> Running the failing test with -XX:G1UpdateBufferSize=3 was failing at a rate
> of about 1/1K runs of the test.  With this change, there were no failures in
> more than 60K runs.

Fix looks good. 

In addition I think we should update the docs in the `nonblockingQueue.hpp` to say that `append(...)`/`push(...)` are also subject to ABA behavior, like we do for `try_pop(...)`.

Also spent some time thinking about the `append(...)` done in `enqueue_paused_buffers_aux(...)`, can we guarantee that an element can't re-enter the queue this way under the special circumstances just after a safepoint where buffers are paused "wrongly" (if this can happen). I guess this might be prevented by, the fact that no other thread could process the element in the first place making it impossible for something to be "re-used" at this point.

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

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk18/pull/104


From ayang at openjdk.java.net  Mon Jan 17 09:00:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 09:00:32 GMT
Subject: RFR: 8280001: Serial: Add documentation to heap memory layout
In-Reply-To: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
References: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
Message-ID: <NQfL972a46pCJATyMzujel18oOhth6dmjkTiJ6NshAY=.01be5ae4-246d-4761-87c0-a87dd3071a40@github.com>

On Fri, 14 Jan 2022 08:26:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Comments-only change of adding some documentation.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Jan 17 09:00:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 09:00:32 GMT
Subject: Integrated: 8280001: Serial: Add documentation to heap memory layout
In-Reply-To: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
References: <9bP4egHHzI7cdVNr8cwrmfmTrDou_bEWU3-d9qqY404=.85d3279c-8fac-4180-a02b-56eb96cd131b@github.com>
Message-ID: <f1xxbhc2AkBBI4uhxG6T2RvRh6ioeGlE_fFXHjbk_kc=.5c47cc91-c371-45ac-b5de-89621b564326@github.com>

On Fri, 14 Jan 2022 08:26:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Comments-only change of adding some documentation.
> 
> Test: build

This pull request has now been integrated.

Changeset: 431bd9a6
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/431bd9a66d759fcd014e9bfc15a0e12976802f06
Stats:     20 lines in 1 file changed: 20 ins; 0 del; 0 mod

8280001: Serial: Add documentation to heap memory layout

Reviewed-by: mli, sjohanss, tschatzl

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

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


From sjohanss at openjdk.java.net  Mon Jan 17 10:24:26 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 17 Jan 2022 10:24:26 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects
In-Reply-To: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
Message-ID: <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>

On Tue, 11 Jan 2022 14:02:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.
> 
> Test: tier1-6

Looks good. 

One think that would be interesting would be to do some measurements on the additional memory usage for the `PreservedMarks` stack with this change. To better understand what kind of memory trade-off we do for the quicker processing.

src/hotspot/share/gc/parallel/psPromotionManager.cpp line 363:

> 361:     push_contents(obj);
> 362: 
> 363:     _preserved_marks->push_always(obj, obj_mark);

I think a comment here explaining that we use the preserved marks no only to preserved "special" marks but also to restore and clear the forwardning pointer in "normal" marks.

src/hotspot/share/gc/shared/preservedMarks.hpp line 60:

> 58:   size_t size() const { return _stack.size(); }
> 59:   inline void push_if_necessary(oop obj, markWord m);
> 60:   inline void push_always(oop obj, markWord m);

Any reason not to just call this `push()` like we had in the past and maybe also re-use it in `push_if_necessary()`?

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

Changes requested by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Jan 17 11:22:27 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 17 Jan 2022 11:22:27 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects
In-Reply-To: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
Message-ID: <4yKm3j18Fdq4bNoIDKmqSEb7WsKR1Zl8mMl4RiqzALk=.30e7d3f4-edcc-415c-90b0-95d334e95648@github.com>

On Tue, 11 Jan 2022 14:02:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.
> 
> Test: tier1-6

src/hotspot/share/gc/parallel/psScavenge.cpp line 708:

> 706:   RemoveForwardedPointerClosure remove_fwd_ptr_closure;
> 707:   young_gen->object_iterate(&remove_fwd_ptr_closure);
> 708: 

Since these are removed, there is no longer any need to get `heap` and `young_gen` above either. I think the cleanest would be do directly use `ParallelScavengeHeap::heap()` in: 

NOT_PRODUCT(heap->reset_promotion_should_fail();)

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 11:30:22 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 11:30:22 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects
In-Reply-To: <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>
Message-ID: <3nWJcfEWn-2cVZp_uS55mCMAVZpC4SrW6C7fb4rfjG0=.9e39ea7b-87e9-430f-a6e1-c5d989213dc9@github.com>

On Mon, 17 Jan 2022 10:20:49 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> One think that would be interesting would be to do some measurements on the additional memory usage for the `PreservedMarks` stack with this change. To better understand what kind of memory trade-off we do for the quicker processing.

It might actually be nice to have some log message for that memory usage somewhere; while I know there is no "framework" for that in Parallel/Serial, it would still be nice to have.

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 12:10:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 12:10:50 GMT
Subject: RFR: 8280072: Remove unnecessary use of ParGCRareEvent_lock in Serial
 GC
Message-ID: <DCiMu9Fw23YyqQXOQxFxgxtLvcnEcBYbrBrgJf3Sj2o=.5cdd0087-6187-4c04-93a8-fe6d6c78998d@github.com>

Hi all,

  can I have reviews for this change that removes an always-false clause in an assert? In more detail, that clause refers to `ParGCRareEvent_lock` that is never held in this code that is only called by serial gc.

Testing: gha, tier1-3

Thanks,
  Thomas

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

Commit messages:
 - Initial version

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 12:22:29 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 12:22:29 GMT
Subject: RFR: 8280072: Remove unnecessary use of ParGCRareEvent_lock in
 Serial GC
In-Reply-To: <DCiMu9Fw23YyqQXOQxFxgxtLvcnEcBYbrBrgJf3Sj2o=.5cdd0087-6187-4c04-93a8-fe6d6c78998d@github.com>
References: <DCiMu9Fw23YyqQXOQxFxgxtLvcnEcBYbrBrgJf3Sj2o=.5cdd0087-6187-4c04-93a8-fe6d6c78998d@github.com>
Message-ID: <G5gwOh7U2bWeUnp5FM7nXmSHWwF6EeJlYOM-V6qfjVs=.f73a438d-6882-4a85-ab60-a6c23f8fda4f@github.com>

On Mon, 17 Jan 2022 12:04:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that removes an always-false clause in an assert? In more detail, that clause refers to `ParGCRareEvent_lock` that is never held in this code that is only called by serial gc.
> 
> Testing: gha, tier1-3
> 
> Thanks,
>   Thomas

G1 also uses `BlockOffsetTable` after all. Closing.

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 12:22:29 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 12:22:29 GMT
Subject: Withdrawn: 8280072: Remove unnecessary use of ParGCRareEvent_lock in
 Serial GC
In-Reply-To: <DCiMu9Fw23YyqQXOQxFxgxtLvcnEcBYbrBrgJf3Sj2o=.5cdd0087-6187-4c04-93a8-fe6d6c78998d@github.com>
References: <DCiMu9Fw23YyqQXOQxFxgxtLvcnEcBYbrBrgJf3Sj2o=.5cdd0087-6187-4c04-93a8-fe6d6c78998d@github.com>
Message-ID: <51cy-9PCygQL4SE2muoqbW120krO1GFfgqy8NpeWDKY=.146f63db-9571-4a21-bc77-ba26c402f6ee@github.com>

On Mon, 17 Jan 2022 12:04:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that removes an always-false clause in an assert? In more detail, that clause refers to `ParGCRareEvent_lock` that is never held in this code that is only called by serial gc.
> 
> Testing: gha, tier1-3
> 
> Thanks,
>   Thomas

This pull request has been closed without being integrated.

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

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


From shade at openjdk.java.net  Mon Jan 17 12:57:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 17 Jan 2022 12:57:45 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
Message-ID: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>

This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.

Additional testing:
  - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
  - [x] Linux x86_32 fastdebug `tier1`
  - [ ] Linux x86_32 fastdebug `tier2`
  - [ ] Linux x86_32 fastdebug `tier3`

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

Commit messages:
 - Touch-up warning
 - Fix

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

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


From ayang at openjdk.java.net  Mon Jan 17 13:28:53 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 13:28:53 GMT
Subject: RFR: 8280030: [REDO] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
Message-ID: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>

Second try in refining the range calculation in `ObjectStartArray::object_starts_in_range`.

Test: tier1-6

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

Commit messages:
 - 8279699: Parallel: More precise boundary in ObjectStartArray::object_starts_in_range

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 13:56:25 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 13:56:25 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
Message-ID: <sc6K0woV-6SUadStI-oG5OJbZTEa1a3W-_6qlmAJjec=.77b66b19-b03f-4eb9-8041-29121ecdc3ed@github.com>

On Mon, 17 Jan 2022 12:24:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.
> 
> Additional testing:
>   - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
>   - [x] Linux x86_32 fastdebug `tier1`
>   - [x] Linux x86_32 fastdebug `tier2`
>   - [ ] Linux x86_32 fastdebug `tier3`

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Jan 17 14:13:23 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 14:13:23 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
Message-ID: <inyCyXvxI3bqWHYtnzAK66COZviMC4oyLIx1Bb5GkWI=.1e60fe40-497d-44cf-9833-9475a829a1ba@github.com>

On Mon, 17 Jan 2022 12:24:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.
> 
> Additional testing:
>   - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
>   - [x] Linux x86_32 fastdebug `tier1`
>   - [x] Linux x86_32 fastdebug `tier2`
>   - [ ] Linux x86_32 fastdebug `tier3`

The fix looks good. However, bailing out with markstack overflow while the used mark stack size is still way below `MarkStackSizeMax` is still quite counterintuitive.

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

Marked as reviewed by ayang (Reviewer).

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


From ayang at openjdk.java.net  Mon Jan 17 14:21:43 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 14:21:43 GMT
Subject: RFR: 8280079: Serial: Remove empty Generation::prepare_for_verify
Message-ID: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>

Simple change of removing some empty methods.

Test: hotspot_gc

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

Commit messages:
 - prepare_for_verify

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 14:26:22 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 14:26:22 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <inyCyXvxI3bqWHYtnzAK66COZviMC4oyLIx1Bb5GkWI=.1e60fe40-497d-44cf-9833-9475a829a1ba@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
 <inyCyXvxI3bqWHYtnzAK66COZviMC4oyLIx1Bb5GkWI=.1e60fe40-497d-44cf-9833-9475a829a1ba@github.com>
Message-ID: <6ZDTQxg3gGVCTjHtPCZhjo-LSRVOCSdz_ZTOQnihAFM=.3da719b8-0c0b-4888-bb57-f4c7f47c1bc8@github.com>

On Mon, 17 Jan 2022 14:10:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> The fix looks good. However, bailing out with markstack overflow while the used mark stack size is still way below `MarkStackSizeMax` is still quite counterintuitive.

That's true, and I was looking through the code a bit why we need to do that (bailing out before `MarkStackSizeMax`), but could not find a reason actually; but I probably didn't look for too long. It looks like that that case is simply not implemented :(

I will file an issue, referencing this CR for a test case.

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

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


From mli at openjdk.java.net  Mon Jan 17 14:36:27 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 17 Jan 2022 14:36:27 GMT
Subject: RFR: 8279910: G1: Simplify HeapRegionRemSet::add_reference
In-Reply-To: <3quQbH6LjWr6U53v-hFMng8-D9h3RkDgY8RsHYqn-qg=.06bc0413-46c7-4740-b152-5bfa4cdf52ec@github.com>
References: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
 <3quQbH6LjWr6U53v-hFMng8-D9h3RkDgY8RsHYqn-qg=.06bc0413-46c7-4740-b152-5bfa4cdf52ec@github.com>
Message-ID: <hEEiY0It4m_NQ0fU0nRpy5LgJdM2uKWUZkNNgWeqE3A=.8ca70cd7-895e-48a8-9559-6de98bc13bdc@github.com>

On Fri, 14 Jan 2022 14:43:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> HeapRegionRemSet::add_reference checks "state == Untracked" and return if true; it's called at G1RebuildRemSetClosure::do_oop_work and G1ConcurrentRefineOopClosure::do_oop_work respectively.
>> 
>> The check in HeapRegionRemSet::add_reference could be replaced with an assert, and move the check up to one of the caller G1RebuildRemSetClosure::do_oop_work.
>
> src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 126:
> 
>> 124: 
>> 125: void HeapRegionRemSet::add_reference(OopOrNarrowOopStar from, uint tid) {
>> 126:   assert(_state != Untracked, "must be");
> 
> I would prefer "precondition" in the assert msg.

Thanks Albert for the suggestion, I kinda agree.
But as the nearby code at line 122 uses "must be", so I will keep it for this case.

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

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


From mli at openjdk.java.net  Mon Jan 17 14:36:27 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 17 Jan 2022 14:36:27 GMT
Subject: Integrated: 8279910: G1: Simplify HeapRegionRemSet::add_reference
In-Reply-To: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
References: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
Message-ID: <hlY9QuJxJEpfTXAykPIKUH7z56oxSpnMStLMaoj-WLM=.2554ffdb-c6f5-47a0-9a5a-a456d3caa9af@github.com>

On Wed, 12 Jan 2022 08:29:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

> HeapRegionRemSet::add_reference checks "state == Untracked" and return if true; it's called at G1RebuildRemSetClosure::do_oop_work and G1ConcurrentRefineOopClosure::do_oop_work respectively.
> 
> The check in HeapRegionRemSet::add_reference could be replaced with an assert, and move the check up to one of the caller G1RebuildRemSetClosure::do_oop_work.

This pull request has now been integrated.

Changeset: 5d52bf99
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d52bf9987445b3a6033d66e8644ed77c4d761bd
Stats:     7 lines in 2 files changed: 2 ins; 3 del; 2 mod

8279910: G1: Simplify HeapRegionRemSet::add_reference

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Mon Jan 17 14:40:45 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 17 Jan 2022 14:40:45 GMT
Subject: RFR: 8280070: G1: Fix template parameters in G1SegmentedArraySegment
Message-ID: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>

This is a simple fix of template parameters in G1SegmentedArraySegment.

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

Commit messages:
 - Initial commit

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

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


From ayang at openjdk.java.net  Mon Jan 17 14:50:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 14:50:32 GMT
Subject: RFR: 8279910: G1: Simplify HeapRegionRemSet::add_reference
In-Reply-To: <hEEiY0It4m_NQ0fU0nRpy5LgJdM2uKWUZkNNgWeqE3A=.8ca70cd7-895e-48a8-9559-6de98bc13bdc@github.com>
References: <ohoJwpHyRgdC5_R1KoMze_VZChfyW3pQZnKn_f-Fw4Y=.ce32a070-f9e8-40e6-8d7e-8ab47b705d9c@github.com>
 <3quQbH6LjWr6U53v-hFMng8-D9h3RkDgY8RsHYqn-qg=.06bc0413-46c7-4740-b152-5bfa4cdf52ec@github.com>
 <hEEiY0It4m_NQ0fU0nRpy5LgJdM2uKWUZkNNgWeqE3A=.8ca70cd7-895e-48a8-9559-6de98bc13bdc@github.com>
Message-ID: <lNiWYwAgA7BKNZrQthoTVAlLKgEKk0uuCXgXaqxO9dQ=.2b07493e-c5f5-45d5-a3aa-82b8536d0267@github.com>

On Mon, 17 Jan 2022 14:31:41 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 126:
>> 
>>> 124: 
>>> 125: void HeapRegionRemSet::add_reference(OopOrNarrowOopStar from, uint tid) {
>>> 126:   assert(_state != Untracked, "must be");
>> 
>> I would prefer "precondition" in the assert msg.
>
> Thanks Albert for the suggestion, I kinda agree.
> But as the nearby code at line 122 uses "must be", so I will keep it for this case.

L122 is a general invariant while here is a precondition literally.

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

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


From duke at openjdk.java.net  Mon Jan 17 15:58:27 2022
From: duke at openjdk.java.net (Martijn Verburg)
Date: Mon, 17 Jan 2022 15:58:27 GMT
Subject: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <jzBbECe4aS99h4M2FzEWKCJb1hlCroX24H6Qpzkpycc=.5dd50165-b652-4122-9ae0-636204bb491b@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

> /sponser

I think it's _sponsor_

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 16:36:28 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 16:36:28 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
Message-ID: <2ZVOhGkcVZZ3eNEwYYLIN0mn8jU_p-XcgE5RCXc3biU=.bbfe3ed3-11a3-4e6c-95bd-f2d1bc19b4b1@github.com>

On Mon, 17 Jan 2022 12:24:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.
> 
> Additional testing:
>   - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
>   - [x] Linux x86_32 fastdebug `tier1`
>   - [x] Linux x86_32 fastdebug `tier2`
>   - [ ] Linux x86_32 fastdebug `tier3`

I filed [JDK-8280087](https://bugs.openjdk.java.net/browse/JDK-8280087); apparently this has actually been a known issue with the same idea to fix this since the change to just exit the VM has been added...

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

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


From duke at openjdk.java.net  Mon Jan 17 16:40:29 2022
From: duke at openjdk.java.net (aamarsh)
Date: Mon, 17 Jan 2022 16:40:29 GMT
Subject: Integrated: 8278885: Remove Windows ARM64 int8_t workaround in G1
In-Reply-To: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
References: <epnuUosvIybjWh0HzbGH8ELBA8-pofiagEBXQWNAjsY=.160a5a0c-b6aa-4112-8879-858b47ce5b8f@github.com>
Message-ID: <6NLR7ux4HkRAsuNRZ1P9iubDBK7sQ2Wf1tCNP2V3C7o=.0c3c82a5-6508-413c-83dc-7c947a6dc6ed@github.com>

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh <duke at openjdk.java.net> wrote:

> Please review this small change to revert a previous workaround that avoided an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

This pull request has now been integrated.

Changeset: 7b6738fa
Author:    Ana Marsh <anamarsh at microsoft.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b6738fa02023825ed9e602555bd5ed2b87a6ca6
Stats:     12 lines in 4 files changed: 2 ins; 6 del; 4 mod

8278885: Remove Windows ARM64 int8_t workaround in G1

Reviewed-by: erikj, tschatzl, mli

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

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


From shade at openjdk.java.net  Mon Jan 17 16:47:22 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 17 Jan 2022 16:47:22 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
Message-ID: <QfktggYZSlSDFkMjysRncm8SywUBOc7tjYcBMSrPO10=.326e618c-1d8e-4124-90de-40c122763f02@github.com>

On Mon, 17 Jan 2022 12:24:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.
> 
> Additional testing:
>   - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
>   - [x] Linux x86_32 fastdebug `tier1`
>   - [x] Linux x86_32 fastdebug `tier2`
>   - [x] Linux x86_32 fastdebug `tier3`

Yeah, I was looking through that code and decided that "resizing" the mark stack is only doable through concurrent mark abort, resize and restart. This overflow happens at Remark pause, which is too late. The "overflowed" bit records failed push to mark stack, so marking looks already borked. Bailout seems to be the only simple recourse. For current failures, this is avoidable if we "just" start with a bit larger mark stack on 32-bit platforms.

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

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


From ayang at openjdk.java.net  Mon Jan 17 16:47:24 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 17 Jan 2022 16:47:24 GMT
Subject: RFR: 8280070: G1: Fix template parameters in
 G1SegmentedArraySegment
In-Reply-To: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
References: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
Message-ID: <jITsd6ksqlIqJ_2tP2kjrO7NOhv6c59-Ex65-Tj_XSk=.f342c2a1-b69e-4391-aa23-320db13929cf@github.com>

On Mon, 17 Jan 2022 14:34:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a simple fix of template parameters in G1SegmentedArraySegment.

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Jan 17 16:57:28 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 17 Jan 2022 16:57:28 GMT
Subject: RFR: 8280070: G1: Fix template parameters in
 G1SegmentedArraySegment
In-Reply-To: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
References: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
Message-ID: <ohF9W4LA2c_ZqLhJ9DGxmjM6OHYlWwUcnfY9dubk-Ik=.47972cb7-a5e5-4ff5-bbc3-35b4d91a90b3@github.com>

On Mon, 17 Jan 2022 14:34:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a simple fix of template parameters in G1SegmentedArraySegment.

Marked as reviewed by tschatzl (Reviewer).

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

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


From dholmes at openjdk.java.net  Tue Jan 18 01:15:26 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 Jan 2022 01:15:26 GMT
Subject: RFR: 8280088: NMT: Make mtGCCardSet the subcategory of mtGC
In-Reply-To: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
References: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
Message-ID: <1tgVFMpKkqez4AsT0BW01jtVaWBSeBX_pSGo2PWiQZc=.3eab7f21-97c3-4bf3-a98b-30b6da766b34@github.com>

On Mon, 17 Jan 2022 18:11:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163) introduced a new category, `mtGCCardSet` in NMT tracking. This makes logging look rather weird, and technically miscounts the space taken by GC-specific data structures, if you are accustomed to look at "GC" only:
> 
> 
> - GC (reserved=142426KB, committed=142426KB)
>                             (malloc=89554KB #3658)
>                             (mmap: reserved=52872KB, committed=52872KB)
>  
> - GCCardSet (reserved=128KB, committed=128KB)
>                             (malloc=128KB #1539)
> 
> 
> We can instead recast it as the subcategory of `mtGC`. It would be similar to `mtThreadStacks` that are accounted separately, but reported as part of `mtThread`.
> 
> 
> - GC (reserved=142584KB, committed=142584KB)
>                             (card sets: 128KB)
>                             (malloc=89583KB #3780)
>                             (mmap: reserved=52872KB, committed=52872KB) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `runtime/NMT`
>  - [ ] Linux x86_64 fastdebug `tier1`

I think the GC folk need to be looking at this one.

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

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


From kbarrett at openjdk.java.net  Tue Jan 18 03:25:23 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 18 Jan 2022 03:25:23 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
 <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>
Message-ID: <gCDUxfvjObve8jOic5VzfGMPUQwLLPUIX888Yt44-EA=.04f5a6bd-b3f1-4290-98e6-0dbd58c8b0f7@github.com>

On Mon, 17 Jan 2022 08:45:29 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Fix looks good.
> 
> In addition I think we should update the docs in the `nonblockingQueue.hpp` to say that `append(...)`/`push(...)` are also subject to ABA behavior, like we do for `try_pop(...)`.

I was planning to do that as one of several planned JDK 19 RFEs, while keeping
the bug fix change minimal.  If you prefer, I can bring forward the comment
changes.

> Also spent some time thinking about the `append(...)` done in `enqueue_paused_buffers_aux(...)`, can we guarantee that an element can't re-enter the queue this way under the special circumstances just after a safepoint where buffers are paused "wrongly" (if this can happen). I guess this might be prevented by, the fact that no other thread could process the element in the first place making it impossible for something to be "re-used" at this point.

The buffers that get pushed by enqueue_previous_paused_buffers were taken from
the queue and paused before the previous safepoint. No thread can be in
push/append or try_pop (via DCQS) across a safepoint boundary. So no ABA.

enqueue_all_paused_buffers is called by the VMThread during a safepoint, with
no concurrent push/append or try_pop operations.  So again, no ABA.

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From mli at openjdk.java.net  Tue Jan 18 04:38:43 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 18 Jan 2022 04:38:43 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more general in
 G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
Message-ID: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>

We have planned to make memory reclaimation more general, and reuse it in evacuation failure processing after JDK-8254739.
Some of the work has already been done in JDK-8276670 and JDK-8277542.
But after JDK-8278917, there is no need to return the memory used by G1SegmentedArray in evacuation failure processing, as it uses another way to do it.
Currently, G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask is half-bound to card set, and half-general, it should be made more general for the readability of the code and future possible reuse of this functionality returning memory (used by G1SegmentedArray) to OS.

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

Commit messages:
 - Make G1SegmentedArrayFreePool public for tests
 - Move G1SegmentedArrayMemoryStats nested in G1SegmentedArrayFreePool
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/7121/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7121&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280106
  Stats: 178 lines in 14 files changed: 56 ins; 39 del; 83 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7121.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7121/head:pull/7121

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


From stuefe at openjdk.java.net  Tue Jan 18 05:47:24 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 18 Jan 2022 05:47:24 GMT
Subject: RFR: 8280088: NMT: Make mtGCCardSet the subcategory of mtGC
In-Reply-To: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
References: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
Message-ID: <f33HMlm8EhArkkQw3Rp0eU_HF5sl37p5uD2RAp-S00Q=.037c8435-636a-4646-9714-d13b4a4398d2@github.com>

On Mon, 17 Jan 2022 18:11:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8017163](https://bugs.openjdk.java.net/browse/JDK-8017163) introduced a new category, `mtGCCardSet` in NMT tracking. This makes logging look rather weird, and technically miscounts the space taken by GC-specific data structures, if you are accustomed to look at "GC" only:
> 
> 
> - GC (reserved=142426KB, committed=142426KB)
>                             (malloc=89554KB #3658)
>                             (mmap: reserved=52872KB, committed=52872KB)
>  
> - GCCardSet (reserved=128KB, committed=128KB)
>                             (malloc=128KB #1539)
> 
> 
> We can instead recast it as the subcategory of `mtGC`. It would be similar to `mtThreadStacks` that are accounted separately, but reported as part of `mtThread`.
> 
> 
> - GC (reserved=142584KB, committed=142584KB)
>                             (card sets: 128KB)
>                             (malloc=89583KB #3780)
>                             (mmap: reserved=52872KB, committed=52872KB) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `runtime/NMT`
>  - [ ] Linux x86_64 fastdebug `tier1`

Hi Aleksey,

I'm not too thrilled by this since it breaks up the strict accounting of allocated memory by allocation API (malloc or mmap). Semantic subcategory is orthogonal to that, and now it gets confusing since card sets are malloced too. So the malloced memory reported under mtGC now excludes malloced memory for card sets? That we do a similar thing for thread stacks does not count; those are different anyway and handling them separately feels okay.

A clean way to do this would be to introduce a generic concept of a category tree. Then reporting it as a tree, not a flat list, with higher up nodes reporting both total and node-only sums for both malloc and mmap.

A watered-down, pragmatic version could be to introduce "compound categories" which do no accounting themselves but are reported as a sum of other categories. Then you have a two-level hierarchy and could have things like mtGCCardSet, mtGCWhatever, and mtGC being the sum of all these other mtGC* categories.

Both approaches would be less hacky, the latter is not really invasive but just a reporting issue.

Just my 5c,

..Thomas

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

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


From sjohanss at openjdk.java.net  Tue Jan 18 08:28:32 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 18 Jan 2022 08:28:32 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <gCDUxfvjObve8jOic5VzfGMPUQwLLPUIX888Yt44-EA=.04f5a6bd-b3f1-4290-98e6-0dbd58c8b0f7@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
 <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>
 <gCDUxfvjObve8jOic5VzfGMPUQwLLPUIX888Yt44-EA=.04f5a6bd-b3f1-4290-98e6-0dbd58c8b0f7@github.com>
Message-ID: <nkS5U5JTalq0HUwQuz-jZ7tbu4I5LXMgfSAWcg2sIOY=.250fe1ae-4d70-486b-864f-cf63dc7b9e06@github.com>

On Tue, 18 Jan 2022 03:22:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I was planning to do that as one of several planned JDK 19 RFEs, while keeping the bug fix change minimal. If you prefer, I can bring forward the comment changes.
> 
I would prefer but if you plan bigger changes to the comments I'm fine with leaving it to 19.

> 
> The buffers that get pushed by enqueue_previous_paused_buffers were taken from the queue and paused before the previous safepoint. No thread can be in push/append or try_pop (via DCQS) across a safepoint boundary. So no ABA.
> 
I was mostly thinking about this case, that you mentioned. That for a short period of time after a safepoint some threads might still think they should yield. In that case it is not clear to me when such paused buffers would be re-added.

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From kbarrett at openjdk.java.net  Tue Jan 18 09:14:24 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 18 Jan 2022 09:14:24 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <nkS5U5JTalq0HUwQuz-jZ7tbu4I5LXMgfSAWcg2sIOY=.250fe1ae-4d70-486b-864f-cf63dc7b9e06@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
 <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>
 <gCDUxfvjObve8jOic5VzfGMPUQwLLPUIX888Yt44-EA=.04f5a6bd-b3f1-4290-98e6-0dbd58c8b0f7@github.com>
 <nkS5U5JTalq0HUwQuz-jZ7tbu4I5LXMgfSAWcg2sIOY=.250fe1ae-4d70-486b-864f-cf63dc7b9e06@github.com>
Message-ID: <ERG11pg76MRumSmIL_lm7rexAdumHhIFLRXd--XplOc=.ea898113-cbbc-43e7-bf3c-6243eba6bc72@github.com>

On Tue, 18 Jan 2022 08:25:15 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > I was planning to do that as one of several planned JDK 19 RFEs, while keeping the bug fix change minimal. If you prefer, I can bring forward the comment changes.
> 
> I would prefer but if you plan bigger changes to the comments I'm fine with leaving it to 19.

I'm not sure; I haven't written the comment updates yet.  There might not be much that needs to be changed.  I'll look through all the changes and see which other ones (if any) need such updates.

> > The buffers that get pushed by enqueue_previous_paused_buffers were taken from the queue and paused before the previous safepoint. No thread can be in push/append or try_pop (via DCQS) across a safepoint boundary. So no ABA.
> 
> I was mostly thinking about this case, that you mentioned. That for a short period of time after a safepoint some threads might still think they should yield. In that case it is not clear to me when such paused buffers would be re-added.

That case you describe is https://bugs.openjdk.java.net/browse/JDK-8278475.  The buffers that get paused then won't be re-enqueued until after the next safepoint.

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From mli at openjdk.java.net  Tue Jan 18 09:20:33 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 18 Jan 2022 09:20:33 GMT
Subject: RFR: 8280070: G1: Fix template parameters in
 G1SegmentedArraySegment
In-Reply-To: <ohF9W4LA2c_ZqLhJ9DGxmjM6OHYlWwUcnfY9dubk-Ik=.47972cb7-a5e5-4ff5-bbc3-35b4d91a90b3@github.com>
References: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
 <ohF9W4LA2c_ZqLhJ9DGxmjM6OHYlWwUcnfY9dubk-Ik=.47972cb7-a5e5-4ff5-bbc3-35b4d91a90b3@github.com>
Message-ID: <aYE_WsH66xWiF_ECHgIk2zPRA23MXQabiYDaf2Kcq3o=.7bf4cb04-f8a9-4f33-a098-42f2c9410f8d@github.com>

On Mon, 17 Jan 2022 16:54:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This is a simple fix of template parameters in G1SegmentedArraySegment.
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Tue Jan 18 09:20:34 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 18 Jan 2022 09:20:34 GMT
Subject: Integrated: 8280070: G1: Fix template parameters in
 G1SegmentedArraySegment
In-Reply-To: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
References: <tZFwOvdLOF9-RX8iaZSL9lf_nn6MeeN_Ni8JEcmcUCs=.f7f9a419-a377-482a-87b7-5db9d8cd19e5@github.com>
Message-ID: <wkcWeJ1eaYveBqYLTa-JNnfeCcRXAq4Hovo0ivcbBRU=.2d57102e-11ae-4cb3-86df-63715f87ba70@github.com>

On Mon, 17 Jan 2022 14:34:16 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a simple fix of template parameters in G1SegmentedArraySegment.

This pull request has now been integrated.

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

8280070: G1: Fix template parameters in G1SegmentedArraySegment

Reviewed-by: ayang, tschatzl

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

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


From sjohanss at openjdk.java.net  Tue Jan 18 09:30:38 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 18 Jan 2022 09:30:38 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <ERG11pg76MRumSmIL_lm7rexAdumHhIFLRXd--XplOc=.ea898113-cbbc-43e7-bf3c-6243eba6bc72@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
 <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>
 <gCDUxfvjObve8jOic5VzfGMPUQwLLPUIX888Yt44-EA=.04f5a6bd-b3f1-4290-98e6-0dbd58c8b0f7@github.com>
 <nkS5U5JTalq0HUwQuz-jZ7tbu4I5LXMgfSAWcg2sIOY=.250fe1ae-4d70-486b-864f-cf63dc7b9e06@github.com>
 <ERG11pg76MRumSmIL_lm7rexAdumHhIFLRXd--XplOc=.ea898113-cbbc-43e7-bf3c-6243eba6bc72@github.com>
Message-ID: <K9HSc848oN99QE8Mwja4IEiSiPeyC_0gILPE5X0ZUug=.ad38107d-932a-49be-99db-119a12947ca7@github.com>

On Tue, 18 Jan 2022 09:10:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> That case you describe is https://bugs.openjdk.java.net/browse/JDK-8278475. The buffers that get paused then won't be re-enqueued until after the next safepoint.

Thanks for clarifying this. Then I'm all good with the change ?

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From tschatzl at openjdk.java.net  Tue Jan 18 11:13:27 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 18 Jan 2022 11:13:27 GMT
Subject: RFR: 8280079: Serial: Remove empty Generation::prepare_for_verify
In-Reply-To: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
References: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
Message-ID: <_5Wttvg_mbEOfrPYIs6mSfqh-lBEdi5SuHiv2FG8mcI=.f8b3f27c-26a5-4fe0-a7d7-f236e04cfc56@github.com>

On Mon, 17 Jan 2022 14:15:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing some empty methods.
> 
> Test: hotspot_gc

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Jan 18 11:44:27 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 18 Jan 2022 11:44:27 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary
 PSCardTable::resize_covered_region_by_end
In-Reply-To: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
Message-ID: <kSZgM8ohGb_LgscgoWksfphRHHlt_EJA0_SuG7mDSWA=.ce06da07-bfe0-4b69-9599-01402f1dacdd@github.com>

On Fri, 14 Jan 2022 14:40:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: tier1-6

src/hotspot/share/gc/parallel/psCardTable.cpp line 417:

> 415: // allows identification of the region that is being resized.
> 416: void PSCardTable::resize_covered_region(MemRegion new_region) {
> 417:   for (int i = 0; i < _cur_covered_regions; i++) {

This method seems to be completely superfluous now and a call to the parent method achieves exactly the same.

I mean, this code in all cases calls `resize_covered_region_by_start()` in any case, which calls the super class method.

`CardTable::resize_covered_region` performs that `_cur_covered_regions < _max_covered_regions` assert too anyway (in `CardTable::find_covered_region_by_base()`).

So I think this entire method (and `resize_covered_region_by_start`) should be removed too.

I think this is a leftover from removal of the (ever broken, see [here](https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22useadaptivegcboundary%22)) functionality to move the generation boundary (`UseAdaptiveGCBoundary`).

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

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


From iwalulya at openjdk.java.net  Tue Jan 18 12:05:21 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 18 Jan 2022 12:05:21 GMT
Subject: RFR: 8280079: Serial: Remove empty Generation::prepare_for_verify
In-Reply-To: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
References: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
Message-ID: <aPOvj6bP2v9YBYs7XEgoTw7ooRem3bNJuTVjGhasYEo=.fc88f863-333a-4c03-953e-c8a74d450731@github.com>

On Mon, 17 Jan 2022 14:15:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing some empty methods.
> 
> Test: hotspot_gc

Marked as reviewed by iwalulya (Reviewer).

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

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


From ayang at openjdk.java.net  Tue Jan 18 12:57:48 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 Jan 2022 12:57:48 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary
 PSCardTable::resize_covered_region_by_end [v2]
In-Reply-To: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
Message-ID: <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>

> Simple change of removing effectively dead code.
> 
> Test: tier1-6

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/7087/files
  - new: https://git.openjdk.java.net/jdk/pull/7087/files/57da2e73..2556b3fc

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

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

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


From ayang at openjdk.java.net  Tue Jan 18 12:57:51 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 Jan 2022 12:57:51 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary
 PSCardTable::resize_covered_region_by_end [v2]
In-Reply-To: <kSZgM8ohGb_LgscgoWksfphRHHlt_EJA0_SuG7mDSWA=.ce06da07-bfe0-4b69-9599-01402f1dacdd@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
 <kSZgM8ohGb_LgscgoWksfphRHHlt_EJA0_SuG7mDSWA=.ce06da07-bfe0-4b69-9599-01402f1dacdd@github.com>
Message-ID: <KjGyCON97QkSl3bTAj5VKEZvTS_9WH8_cHZpgl8YxGg=.7e5f6f1e-79e5-455f-9227-64332bb43634@github.com>

On Tue, 18 Jan 2022 11:41:28 GMT, Thomas Schatzl <tschatzl 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/parallel/psCardTable.cpp line 417:
> 
>> 415: // allows identification of the region that is being resized.
>> 416: void PSCardTable::resize_covered_region(MemRegion new_region) {
>> 417:   for (int i = 0; i < _cur_covered_regions; i++) {
> 
> This method seems to be completely superfluous now and a call to the parent method achieves exactly the same.
> 
> I mean, this code in all cases calls `resize_covered_region_by_start()` in any case, which calls the super class method.
> 
> `CardTable::resize_covered_region` performs that `_cur_covered_regions < _max_covered_regions` assert too anyway (in `CardTable::find_covered_region_by_base()`).
> 
> So I think this entire method (and `resize_covered_region_by_start`) should be removed too.
> 
> I think this is a leftover from removal of the (ever broken, see [here](https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22useadaptivegcboundary%22)) functionality to move the generation boundary (`UseAdaptiveGCBoundary`).

Yes, you are right. I have removed those two methods.

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

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


From ayang at openjdk.java.net  Tue Jan 18 13:02:27 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 Jan 2022 13:02:27 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary region resizing methods
 in PSCardTable [v2]
In-Reply-To: <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
 <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
Message-ID: <QBFkTgw_lj1pYEOPUU_6_g4aDprCxCBmqnb7FZC_KJI=.09baf99a-a80b-4413-aec8-6adfc41d3d6e@github.com>

On Tue, 18 Jan 2022 12:57:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Updated the title to reflect the new diff.

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

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


From tschatzl at openjdk.java.net  Tue Jan 18 14:00:28 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 18 Jan 2022 14:00:28 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary region resizing methods
 in PSCardTable [v2]
In-Reply-To: <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
 <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
Message-ID: <jT2K6EDuZ0ZY182WremRRlwZO6H8MolixmVQ9CRolvc=.9bcd5c1c-a48d-4aa8-9088-116edc6eae17@github.com>

On Tue, 18 Jan 2022 12:57:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: tier1-6
>
> 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/7087


From shade at openjdk.java.net  Tue Jan 18 14:44:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 18 Jan 2022 14:44:32 GMT
Subject: RFR: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
Message-ID: <rNLC3-9FukOMvyKxfrDrSTeKzFr7KGbNP7n3UNjgEuk=.3bd970bf-aba9-4aae-a103-800dbabe300a@github.com>

On Mon, 17 Jan 2022 12:24:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.
> 
> Additional testing:
>   - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
>   - [x] Linux x86_32 fastdebug `tier1`
>   - [x] Linux x86_32 fastdebug `tier2`
>   - [x] Linux x86_32 fastdebug `tier3`

Thanks for reviews, I am integrating to make GHA cleaner.

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

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


From shade at openjdk.java.net  Tue Jan 18 14:44:32 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 18 Jan 2022 14:44:32 GMT
Subject: Integrated: 8280029: G1:
 "Overflow during reference processing, can not continue" on x86_32
In-Reply-To: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
References: <89oZufQv4TvD0gQ-_hZwok_RIJ3jKYNt__LRCaH1WPA=.5a421172-b8af-49c1-8467-5f54b3b7c4c9@github.com>
Message-ID: <Vh9gcGtymmPUyHggG2S4LBZMApRSgo_O8GLKxnG2sNA=.4ebe11b1-b4df-48eb-861f-a5b6e528f2f2@github.com>

On Mon, 17 Jan 2022 12:24:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This should fix the intermittent G1 x86_32 failure in GHA. See more investigation in the bug. I think at this point we are better off bumping the default mark stack size for 32-bit builds. Also fix the error message to be less misleading.
> 
> Additional testing:
>   - [x] Affected test on Linux fastdebug x86_32, 100 repeats; used to fail at about 10th iteration, does not fail anymore;
>   - [x] Linux x86_32 fastdebug `tier1`
>   - [x] Linux x86_32 fastdebug `tier2`
>   - [x] Linux x86_32 fastdebug `tier3`

This pull request has now been integrated.

Changeset: 1725f77b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1725f77bcd6528d56960a0796fcea3725cc98b6a
Stats:     5 lines in 2 files changed: 1 ins; 0 del; 4 mod

8280029: G1: "Overflow during reference processing, can not continue" on x86_32

Reviewed-by: tschatzl, ayang

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

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


From ayang at openjdk.java.net  Tue Jan 18 14:54:27 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 Jan 2022 14:54:27 GMT
Subject: RFR: 8280079: Serial: Remove empty Generation::prepare_for_verify
In-Reply-To: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
References: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
Message-ID: <QQA9PghNOp-UA3XlGYQqvqQnc5GpdCYwpmAaf_7ShcA=.9e9d071e-1615-4888-8769-78888bd02d06@github.com>

On Mon, 17 Jan 2022 14:15:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing some empty methods.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Jan 18 14:57:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 18 Jan 2022 14:57:32 GMT
Subject: Integrated: 8280079: Serial: Remove empty
 Generation::prepare_for_verify
In-Reply-To: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
References: <FE08m1GvmSXhqXIftyBrRkQgKKKg7i7PBE2VrD95Zh4=.7b2276e7-b0db-4f42-993e-1c63c6e19cb5@github.com>
Message-ID: <ymU8wCYoOsNW6YQDL__LZG4LuBI_lAItqFifYupQWvM=.b3d5a91d-eb3e-4159-ac07-e0c3518593d5@github.com>

On Mon, 17 Jan 2022 14:15:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing some empty methods.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: d175d33f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d175d33f44e996d2927f953dac2ad4fef542f2a0
Stats:     22 lines in 6 files changed: 0 ins; 22 del; 0 mod

8280079: Serial: Remove empty Generation::prepare_for_verify

Reviewed-by: tschatzl, iwalulya

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

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


From mli at openjdk.java.net  Wed Jan 19 01:35:29 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 19 Jan 2022 01:35:29 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary region resizing methods
 in PSCardTable [v2]
In-Reply-To: <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
 <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
Message-ID: <XWI0Q-dQ8qwSZbLz5r8ggN-KrMWYXzdn5Ws9voKCY74=.35516389-c343-44e2-b5e1-846153a5b904@github.com>

On Tue, 18 Jan 2022 12:57:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Lgtm

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

Marked as reviewed by mli (Reviewer).

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


From kbarrett at openjdk.java.net  Wed Jan 19 04:40:19 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 19 Jan 2022 04:40:19 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS [v2]
In-Reply-To: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
Message-ID: <zWwFyp4Y9qfU8q5wX7KfXQYJ6lQIOSSW6YecnHRTcO0=.85b98a6f-7219-4523-8f51-d97947dac3cd@github.com>

> Please review this fix of an ABA problem in G1DirtyCardQueueSet's use of
> NonblockingQueue. 
> 
> Consider queue q contains one entry, `X`.
> 
> Thread1 begins a push/append operation. WOLG, assume a push of `Y`. It
> atomically exchanges `q._tail` with `Y`, retaining the old value of `q._tail`,
> which is `X`. Pause Thread1 here.
> 
> Thread2 pops `X` from the queue. It successfully changes `X._next` from
> end-marker to null and `q._head` from `X` to null. Thread2 fails to change
> `q._tail` from `X` to null, as Thread1 already changed it to `Y`.
> 
> Various threads add entries to the queue after `Y`, and various threads try to
> pop entries and find the queue "empty" because `q._head` will remain null
> until Thread1 proceeds.
> 
> In parallel with entries being added, Thread2 processes `X` and releases it
> for reuse. Some thread reallocates it, fills it, and pushes it onto the
> queue. We now have a chain from `Y` => `X` in `q._tail` with `q._head` still
> null.
> 
> If Thread1 resumes at that point, it finds `X._next` == end-marker,
> successfully changes it to `Y`, and "completes". We now have `q._head` == null
> and `q._tail` == `X`, with `X` => `Y` => `X`. The next push/append will
> observe `q._tail` of `X` having a non-end-marker `_next` and change both
> `q._head` and `q._tail`, dropping the list containing `X`, `Y`, &etc on the
> floor.
> 
> There may be other similarly bad scenarios, depending on exactly what is going
> on when Thread1 resumes.
> 
> All of these are fixed by performing the push operation in a critical section,
> so that `X` cannot be reused until the push that is observing it
> completes. That is, in `DirtyCardQueueSet::enqueue_completed_buffer`, put
> `_completed.push(*cbn);` in a GlobalCounter critical section.
> 
> Testing:
> mach5 tier1
> 
> Running the failing test with -XX:G1UpdateBufferSize=3 was failing at a rate
> of about 1/1K runs of the test.  With this change, there were no failures in
> more than 60K runs.

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 fix-dcqs-push
 - DCQS push buffers inside CS

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

Changes:
  - all: https://git.openjdk.java.net/jdk18/pull/104/files
  - new: https://git.openjdk.java.net/jdk18/pull/104/files/9fd316f5..27e24d24

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

  Stats: 1502 lines in 58 files changed: 743 ins; 581 del; 178 mod
  Patch: https://git.openjdk.java.net/jdk18/pull/104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/104/head:pull/104

PR: https://git.openjdk.java.net/jdk18/pull/104


From kbarrett at openjdk.java.net  Wed Jan 19 04:40:19 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 19 Jan 2022 04:40:19 GMT
Subject: [jdk18] RFR: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS [v2]
In-Reply-To: <K9HSc848oN99QE8Mwja4IEiSiPeyC_0gILPE5X0ZUug=.ad38107d-932a-49be-99db-119a12947ca7@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
 <iz28r5FZnENchTlA0r4xNQx1TUo7ipYbQlFSNZE3HNQ=.402c609a-5796-450a-a66d-eea7addc3dea@github.com>
 <gCDUxfvjObve8jOic5VzfGMPUQwLLPUIX888Yt44-EA=.04f5a6bd-b3f1-4290-98e6-0dbd58c8b0f7@github.com>
 <nkS5U5JTalq0HUwQuz-jZ7tbu4I5LXMgfSAWcg2sIOY=.250fe1ae-4d70-486b-864f-cf63dc7b9e06@github.com>
 <ERG11pg76MRumSmIL_lm7rexAdumHhIFLRXd--XplOc=.ea898113-cbbc-43e7-bf3c-6243eba6bc72@github.com>
 <K9HSc848oN99QE8Mwja4IEiSiPeyC_0gILPE5X0ZUug=.ad38107d-932a-49be-99db-119a12947ca7@github.com>
Message-ID: <UkPIX3neTG5Uv4Fk2L0yM53FBtJcUPlNc_k6X315pCk=.48b2b123-ee2d-4a02-8526-e1526425f3b7@github.com>

On Tue, 18 Jan 2022 09:27:18 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>>> > I was planning to do that as one of several planned JDK 19 RFEs, while keeping the bug fix change minimal. If you prefer, I can bring forward the comment changes.
>>> 
>>> I would prefer but if you plan bigger changes to the comments I'm fine with leaving it to 19.
>> 
>> I'm not sure; I haven't written the comment updates yet.  There might not be much that needs to be changed.  I'll look through all the changes and see which other ones (if any) need such updates.
>> 
>>> > The buffers that get pushed by enqueue_previous_paused_buffers were taken from the queue and paused before the previous safepoint. No thread can be in push/append or try_pop (via DCQS) across a safepoint boundary. So no ABA.
>>> 
>>> I was mostly thinking about this case, that you mentioned. That for a short period of time after a safepoint some threads might still think they should yield. In that case it is not clear to me when such paused buffers would be re-added.
>> 
>> That case you describe is https://bugs.openjdk.java.net/browse/JDK-8278475.  The buffers that get paused then won't be re-enqueued until after the next safepoint.
>
>> That case you describe is https://bugs.openjdk.java.net/browse/JDK-8278475. The buffers that get paused then won't be re-enqueued until after the next safepoint.
> 
> Thanks for clarifying this. Then I'm all good with the change ?

Thanks @kstefanj and @tschatzl  for reviews.

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From kbarrett at openjdk.java.net  Wed Jan 19 04:40:19 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 19 Jan 2022 04:40:19 GMT
Subject: [jdk18] Integrated: 8273383:
 vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes
 verifying length of DCQS
In-Reply-To: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
References: <tvj2An9LXeDSvIfbXqn-1TQQNP6LyaI7gRoDldJKR9o=.42cb2e46-c272-4327-abb8-05fd369bab01@github.com>
Message-ID: <Zf1ISLoq8_ropjbTT3R57Rh5GJnRtIUNJl3IkS2UM1I=.b3be7afe-261e-47bf-9ed5-a3998d31b22f@github.com>

On Sun, 16 Jan 2022 18:20:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of an ABA problem in G1DirtyCardQueueSet's use of
> NonblockingQueue. 
> 
> Consider queue q contains one entry, `X`.
> 
> Thread1 begins a push/append operation. WOLG, assume a push of `Y`. It
> atomically exchanges `q._tail` with `Y`, retaining the old value of `q._tail`,
> which is `X`. Pause Thread1 here.
> 
> Thread2 pops `X` from the queue. It successfully changes `X._next` from
> end-marker to null and `q._head` from `X` to null. Thread2 fails to change
> `q._tail` from `X` to null, as Thread1 already changed it to `Y`.
> 
> Various threads add entries to the queue after `Y`, and various threads try to
> pop entries and find the queue "empty" because `q._head` will remain null
> until Thread1 proceeds.
> 
> In parallel with entries being added, Thread2 processes `X` and releases it
> for reuse. Some thread reallocates it, fills it, and pushes it onto the
> queue. We now have a chain from `Y` => `X` in `q._tail` with `q._head` still
> null.
> 
> If Thread1 resumes at that point, it finds `X._next` == end-marker,
> successfully changes it to `Y`, and "completes". We now have `q._head` == null
> and `q._tail` == `X`, with `X` => `Y` => `X`. The next push/append will
> observe `q._tail` of `X` having a non-end-marker `_next` and change both
> `q._head` and `q._tail`, dropping the list containing `X`, `Y`, &etc on the
> floor.
> 
> There may be other similarly bad scenarios, depending on exactly what is going
> on when Thread1 resumes.
> 
> All of these are fixed by performing the push operation in a critical section,
> so that `X` cannot be reused until the push that is observing it
> completes. That is, in `DirtyCardQueueSet::enqueue_completed_buffer`, put
> `_completed.push(*cbn);` in a GlobalCounter critical section.
> 
> Testing:
> mach5 tier1
> 
> Running the failing test with -XX:G1UpdateBufferSize=3 was failing at a rate
> of about 1/1K runs of the test.  With this change, there were no failures in
> more than 60K runs.

This pull request has now been integrated.

Changeset: 69cfa9cb
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk18/commit/69cfa9cb36ab2b5490c231c30306f682665faab4
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8273383: vmTestbase/vm/gc/containers/Combination05/TestDescription.java crashes verifying length of DCQS

Reviewed-by: tschatzl, sjohanss

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

PR: https://git.openjdk.java.net/jdk18/pull/104


From sjohanss at openjdk.java.net  Wed Jan 19 08:45:29 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 19 Jan 2022 08:45:29 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase [v2]
In-Reply-To: <nlyoQ1jiBzeunDVcvEGJX5UO-h1uHH-05RGwYJObimI=.7e454a31-687a-48a2-a37a-c193783b0d75@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
 <nlyoQ1jiBzeunDVcvEGJX5UO-h1uHH-05RGwYJObimI=.7e454a31-687a-48a2-a37a-c193783b0d75@github.com>
Message-ID: <L3-0oI261T5Z5puEEpsr5d_ERaB1dgUxW99hcDkR3lA=.23757086-e93c-4da0-950c-9fdbda60df41@github.com>

On Mon, 10 Jan 2022 10:56:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
>> 
>> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

Nice cleanup, not sure if I agree that it's that simple though ?  At least it requires a lot of testing to make sure there is no regression. 

In general it looks good, I basically just have a few naming suggestions/comments. I think it would be nice to keep the terminology to use threshold rather than boundary since this is what the BOT is currently calling it.

src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 34:

> 32: #include "runtime/atomic.hpp"
> 33: 
> 34: inline HeapWord* G1BlockOffsetTablePart::align_up_by_card_size(HeapWord* const addr) const {

What do you think about calling this `align_up_to_threshold()`.

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

> 513:       // old. If the current allocation was done outside the PLAB this call will
> 514:       // have no effect since the _top of the PLAB has not changed.
> 515:       update_bot_after_copying(obj, word_sz);

The comment above needs to be modified to match the new code. This call now handles the update for direct allocations as well.

src/hotspot/share/gc/g1/heapRegion.hpp line 167:

> 165: 
> 166:   // Update BOT if this obj is the first entering a new card (i.e. crossing the card boundary).
> 167:   inline void update_bot_if_crossing_boundary(HeapWord* obj_start, size_t obj_size);

I would prefer using threshold instead of boundary here since threshold is the term used in the BOT.

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

> 243:          p2i(obj_start), p2i(obj_end));
> 244: 
> 245:   HeapWord* cur_card_boundary = _bot_part.align_up_by_card_size(obj_start);

I think something like `next_bot_threshold` would be even more descriptive.

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

> 246: 
> 247:   // strictly greater-than
> 248:   bool cross_card_boundary = (obj_end > cur_card_boundary);

Any reason for keeping this as a separate statement? Otherwise I would just do the comparison directly in the if-statement.

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

Changes requested by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Jan 19 09:26:58 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 19 Jan 2022 09:26:58 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
Message-ID: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>

Hi all,

  can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.

The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.

The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.

This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.

The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).

Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference

Thanks,
  Thomas

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

Commit messages:
 - Copyright dates, Fix compilation
 - Cleanup, inlining
 - Crashes-a-lot

Changes: https://git.openjdk.java.net/jdk/pull/7106/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7106&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279241
  Stats: 495 lines in 9 files changed: 286 ins; 145 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7106/head:pull/7106

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


From ayang at openjdk.java.net  Wed Jan 19 12:03:28 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 Jan 2022 12:03:28 GMT
Subject: RFR: 8280024: Parallel: Remove unnecessary region resizing methods
 in PSCardTable [v2]
In-Reply-To: <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
 <gUyX2HOpfKWiN_Y3Htn8U9gJNOGY-FsnYojHoNnLnQE=.d15a9072-d899-42ff-a69c-cbcf7d9ac3f0@github.com>
Message-ID: <dVXY9d1jItdmbGhgPU_AybypFY8-OsYPoV6_ViaCl2E=.3abfc47c-0f7e-48f5-8e51-def9e963cca2@github.com>

On Tue, 18 Jan 2022 12:57:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing effectively dead code.
>> 
>> Test: tier1-6
>
> 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/7087


From ayang at openjdk.java.net  Wed Jan 19 12:06:28 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 19 Jan 2022 12:06:28 GMT
Subject: Integrated: 8280024: Parallel: Remove unnecessary region resizing
 methods in PSCardTable
In-Reply-To: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
References: <bkrvw5KYDuCCr1fXqEX4tE8RswLND_morIqziFsBJkA=.03f31abd-e296-4daa-ad59-f1a23a233320@github.com>
Message-ID: <Olv-itlI11RueseqdF60l1Bnb3C_khYi0VxjY47V8mI=.e1b0e95e-82d9-42a2-a1d5-42a3e8b0ef35@github.com>

On Fri, 14 Jan 2022 14:40:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing effectively dead code.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: cc2f474c
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc2f474c18082413420b353528198883055de73a
Stats:     299 lines in 2 files changed: 0 ins; 299 del; 0 mod

8280024: Parallel: Remove unnecessary region resizing methods in PSCardTable

Reviewed-by: tschatzl, mli

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

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


From tschatzl at openjdk.java.net  Wed Jan 19 13:03:45 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 19 Jan 2022 13:03:45 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing in
 task queue stats
Message-ID: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>

Hi all,

  can I have reviews that improves task queue statistics?

This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.

Old output of `gc+tasks+stats=trace` after compiling in these statistics:

thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
--- ---------- ---------- ---------- ---------- ---------- ---------- ----------
0    3777115    3776816       3872      17434       9630          0          0

And new:

thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
--- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
[...]

The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
`ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.

There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.

Thanks,
  Thomas

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

Commit messages:
 - Cleanup, remove tasks count
 - More task queue statistics

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

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


From iwalulya at openjdk.java.net  Wed Jan 19 16:57:27 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 19 Jan 2022 16:57:27 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
Message-ID: <8BK-WaEzNjNkvMQw_ZSrGrrJUAmDLfAXVK5kQNZLtzY=.71e165b7-2d5a-4197-b978-db131b02c091@github.com>

On Mon, 17 Jan 2022 11:00:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
> 
> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
> 
> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
> 
> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
> 
> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
> 
> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
> 
> Thanks,
>   Thomas

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From kbarrett at openjdk.java.net  Wed Jan 19 20:52:52 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 19 Jan 2022 20:52:52 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats
In-Reply-To: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
Message-ID: <73VGkKRLuhHydsa6Nlr0ZSWlYr27dH5ZbTE4ziXoT7k=.beb5caab-83c4-4c98-812c-6eb305fcc08a@github.com>

On Wed, 19 Jan 2022 12:55:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews that improves task queue statistics?
> 
> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
> 
> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
> 
> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>   0    3777115    3776816       3872      17434       9630          0          0
> 
> And new:
> 
> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
> [...]
> 
> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
> 
> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
> 
> Thanks,
>   Thomas

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/taskqueue.hpp line 76:

> 74:   inline void record_pop_slow()      { record_pop(); ++_stats[pop_slow]; }
> 75:   inline void record_steal_attempt(uint kind) { ++_stats[steal_attempt]; ++_stats[steal_empty + kind]; }
> 76:   inline void record_contended_in_a_row(uint in_a_row) { if (_stats[steal_max_contended_in_a_row] < in_a_row) _stats[steal_max_contended_in_a_row] = in_a_row; }

Please add some line breaks to this very long definition.

src/hotspot/share/gc/shared/taskqueue.hpp line 366:

> 364:   // recently pushed).
> 365:   // The result value order of this correspond to the order in the corresponding StatId.
> 366:   enum PopResult {

I think the `PopResult` enum should be in `TaskQueueSuper`.  I think that will allow some of the references to be simplified.  Others might be simplified by being brought into scope via `using`.

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

> 299:       sel_k = k2;
> 300:       suc = _queues[k2]->pop_global(t);
> 301:       TASKQUEUE_STATS_ONLY(queue(queue_num)->stats.record_steal_attempt((uint)suc);)

Consider adding `TaskQueueSuper::record_steal_attempt(PopResult)` to package up this idiom.

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

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


From kbarrett at openjdk.java.net  Wed Jan 19 20:52:52 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 19 Jan 2022 20:52:52 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats
In-Reply-To: <73VGkKRLuhHydsa6Nlr0ZSWlYr27dH5ZbTE4ziXoT7k=.beb5caab-83c4-4c98-812c-6eb305fcc08a@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
 <73VGkKRLuhHydsa6Nlr0ZSWlYr27dH5ZbTE4ziXoT7k=.beb5caab-83c4-4c98-812c-6eb305fcc08a@github.com>
Message-ID: <Briz0yCOg6NDY8MMnHSjxlZciGLCwtL-8NVEzWyXZ10=.888551e6-85a1-4693-9d64-cf6431a0582a@github.com>

On Wed, 19 Jan 2022 19:55:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews that improves task queue statistics?
>> 
>> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
>> 
>> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
>> 
>> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
>> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>>   0    3777115    3776816       3872      17434       9630          0          0
>> 
>> And new:
>> 
>> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
>> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
>> [...]
>> 
>> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
>> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
>> 
>> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/shared/taskqueue.hpp line 366:
> 
>> 364:   // recently pushed).
>> 365:   // The result value order of this correspond to the order in the corresponding StatId.
>> 366:   enum PopResult {
> 
> I think the `PopResult` enum should be in `TaskQueueSuper`.  I think that will allow some of the references to be simplified.  Others might be simplified by being brought into scope via `using`.

Also, consider making `PopResult` an enum class.

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

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


From kbarrett at openjdk.java.net  Wed Jan 19 22:38:06 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 19 Jan 2022 22:38:06 GMT
Subject: RFR: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused
Message-ID: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>

Please review this change to avoid attempts to refine dirty cards by Java
threads when there is an active STS yield request, as the attempt will just
end up being paused.  When going into a safepoint this avoids wasted work and
transfer of buffers into the paused list.  More importantly, when coming out
of a pause this avoids deferring buffers to after the next safepoint, due to
the yield request being cleared after Java threads are restarted.

Testing:
mach5 tier1

Lots of testing as part of investigation of JDK-8273383.

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

Commit messages:
 - fix

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

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


From mli at openjdk.java.net  Thu Jan 20 09:57:12 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 20 Jan 2022 09:57:12 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark
Message-ID: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>

In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

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

Commit messages:
 - Initial commit

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

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


From mli at openjdk.java.net  Thu Jan 20 10:02:04 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 20 Jan 2022 10:02:04 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure
Message-ID: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>

Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.

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

Commit messages:
 - Initial commit

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

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


From tschatzl at openjdk.java.net  Thu Jan 20 10:18:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 20 Jan 2022 10:18:50 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure
In-Reply-To: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
Message-ID: <1695HD4rCrUjjkvH1wdu3GH-FPNMLPLnMXWbqlrNiAk=.2ccbaad7-56dc-4d2a-bdd2-2438b1c7899d@github.com>

On Thu, 20 Jan 2022 09:55:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.

src/hotspot/share/gc/g1/g1RemSet.cpp line 1960:

> 1958: 
> 1959:       HeapWord* cur = hr->bottom();
> 1960:       while (cur < hr->top()) {

I think it is possible (and less misleading) to just use a `while (true) {` loop. Neither a condition containing `end()` or `top()` is correct. The only boundary that matters is `top_at_rebuild_start()`; since it can change between iterations, and it is needed in the loop I do not see a good condition here.
(Using `top()` may exit the loop just a tiny bit earlier than the `next_chunk.is_empty()` check below though, but for simplicity, i.e. having one exit condition less to think about, it might be useful to just state `true` here).

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

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


From tschatzl at openjdk.java.net  Thu Jan 20 10:23:49 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 20 Jan 2022 10:23:49 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <9wpyb7fwvZxHgOJpwr5BttlSmTsTfP0gEcSavOaD5NQ=.af2a8af7-65ad-4cb3-b8e9-bb76004da94e@github.com>

On Thu, 20 Jan 2022 09:49:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

Lgtm apart from the comment. I'll push this through our internal test suite and report back any issues.

src/hotspot/share/gc/g1/g1EvacFailure.cpp line 136:

> 134:       }
> 135:     }
> 136:     _cm->clear_range_in_prev_bitmap(mr);

The comment in line 107 needs to be updated to something like:


// Fill the memory area from start to end with filler objects, and update the BOT
// accordingly. Since we clear and use the prev bitmap for marking objects that
// failed evacuation, there is no work to be done there.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Jan 20 10:41:48 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 20 Jan 2022 10:41:48 GMT
Subject: RFR: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused
In-Reply-To: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
References: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
Message-ID: <6cqY6FOlunbBECf2Nwffz3SfFLM3EnXNBiHRTfl4_O8=.f0ddd053-a507-4a77-a1b9-9a218245b877@github.com>

On Wed, 19 Jan 2022 22:31:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to avoid attempts to refine dirty cards by Java
> threads when there is an active STS yield request, as the attempt will just
> end up being paused.  When going into a safepoint this avoids wasted work and
> transfer of buffers into the paused list.  More importantly, when coming out
> of a pause this avoids deferring buffers to after the next safepoint, due to
> the yield request being cleared after Java threads are restarted.
> 
> Testing:
> mach5 tier1
> 
> Lots of testing as part of investigation of JDK-8273383.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Jan 20 11:11:22 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 20 Jan 2022 11:11:22 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats [v2]
In-Reply-To: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
Message-ID: <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>

> Hi all,
> 
>   can I have reviews that improves task queue statistics?
> 
> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
> 
> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
> 
> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>   0    3777115    3776816       3872      17434       9630          0          0
> 
> And new:
> 
> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
> [...]
> 
> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
> 
> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
> 
> Thanks,
>   Thomas

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

 - Some further cleanup
 - kbarrett review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7143/files
  - new: https://git.openjdk.java.net/jdk/pull/7143/files/4236e2d9..60b25d7a

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

  Stats: 49 lines in 2 files changed: 20 ins; 8 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7143.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7143/head:pull/7143

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


From zgu at openjdk.java.net  Thu Jan 20 16:00:12 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 20 Jan 2022 16:00:12 GMT
Subject: RFR: 8280391: NMT: Correct NMT tag on CollectedHeap
Message-ID: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>

Please review this trivial patch.

Heap is the centerpiece of GC, it is odd to see that it is tagged as mtInternal.

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

Commit messages:
 - 8280391: NMT: Correct NMT tag on CollectedHeap

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

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


From ayang at openjdk.java.net  Thu Jan 20 16:09:24 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 20 Jan 2022 16:09:24 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase [v3]
In-Reply-To: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
Message-ID: <3P4OPgL-yei0BZjwibalHwiB2DKz-ExlBg8H_LZ4Ydo=.d38168d6-f006-433a-8abc-055050f48060@github.com>

> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
> 
> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015

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/6916/files
  - new: https://git.openjdk.java.net/jdk/pull/6916/files/1242f947..b506b728

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

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

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


From ayang at openjdk.java.net  Thu Jan 20 16:09:28 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 20 Jan 2022 16:09:28 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase [v2]
In-Reply-To: <L3-0oI261T5Z5puEEpsr5d_ERaB1dgUxW99hcDkR3lA=.23757086-e93c-4da0-950c-9fdbda60df41@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
 <nlyoQ1jiBzeunDVcvEGJX5UO-h1uHH-05RGwYJObimI=.7e454a31-687a-48a2-a37a-c193783b0d75@github.com>
 <L3-0oI261T5Z5puEEpsr5d_ERaB1dgUxW99hcDkR3lA=.23757086-e93c-4da0-950c-9fdbda60df41@github.com>
Message-ID: <YwgSFpL7GXd0OuARB6olw2QbKT2JKf1kC-isw79EROk=.857e6fb0-2079-4726-b031-8c231694c407@github.com>

On Wed, 19 Jan 2022 07:56:43 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:
>> 
>>   Update src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp
>>   
>>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> src/hotspot/share/gc/g1/heapRegion.inline.hpp line 248:
> 
>> 246: 
>> 247:   // strictly greater-than
>> 248:   bool cross_card_boundary = (obj_end > cur_card_boundary);
> 
> Any reason for keeping this as a separate statement? Otherwise I would just do the comparison directly in the if-statement.

Just wanna highlight it's "strictly greater-than" and give it a meaningful name to match the method name, "XXX_if_crossing_boundary".

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

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


From sjohanss at openjdk.java.net  Thu Jan 20 16:50:50 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 20 Jan 2022 16:50:50 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase [v3]
In-Reply-To: <3P4OPgL-yei0BZjwibalHwiB2DKz-ExlBg8H_LZ4Ydo=.d38168d6-f006-433a-8abc-055050f48060@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
 <3P4OPgL-yei0BZjwibalHwiB2DKz-ExlBg8H_LZ4Ydo=.d38168d6-f006-433a-8abc-055050f48060@github.com>
Message-ID: <I_twOY2rCuc7L0Z6EVhe2EpCx9fBM2Qj3Ej96YmO-xM=.da41b569-a083-4983-a789-ca22cf8532bf@github.com>

On Thu, 20 Jan 2022 16:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
>> 
>> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by sjohanss (Reviewer).

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

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


From ayang at openjdk.java.net  Thu Jan 20 17:22:53 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 20 Jan 2022 17:22:53 GMT
Subject: RFR: 8279008: G1: Calculate BOT threshold on-the-fly during Object
 Copy phase [v3]
In-Reply-To: <3P4OPgL-yei0BZjwibalHwiB2DKz-ExlBg8H_LZ4Ydo=.d38168d6-f006-433a-8abc-055050f48060@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
 <3P4OPgL-yei0BZjwibalHwiB2DKz-ExlBg8H_LZ4Ydo=.d38168d6-f006-433a-8abc-055050f48060@github.com>
Message-ID: <7t2J0Kzn5cx_pjrOL3HJI14TqwEAC40qWV9v3JG_E90=.b51299e7-502c-4caf-b4c5-526015982331@github.com>

On Thu, 20 Jan 2022 16:09:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
>> 
>> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

As discussed with Stefan, I will keep the term "card boundary" in this PR and remove `G1BlockOffsetTablePart::_next_offset_threshold` in a new PR, since "threshold" is too abstract and less precise.

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Jan 20 17:22:53 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 20 Jan 2022 17:22:53 GMT
Subject: Integrated: 8279008: G1: Calculate BOT threshold on-the-fly during
 Object Copy phase
In-Reply-To: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
References: <m_kzXkuR2cZuBiQ2QeKDpXgc4tMsJOEQgNqyftmg4Uw=.476d70f5-8a6b-4a30-a233-8a7c6c29ac60@github.com>
Message-ID: <kX4MXuJ7pezjT142SZR4cQCl1eoK-sAY6zk6btnnn5Y=.ee121e3f-66c5-4380-8ee7-f61ac55db67b@github.com>

On Wed, 22 Dec 2021 12:48:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of unifying BOT logic for PLAB and direct allocation during GC.
> 
> Test: tier1-6; no difference observed while running BigRamTester, SPECjbb2015

This pull request has now been integrated.

Changeset: 96365026
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9636502658c0844c5790cf37af4b15163bf9fa61
Stats:     138 lines in 11 files changed: 15 ins; 105 del; 18 mod

8279008: G1: Calculate BOT threshold on-the-fly during Object Copy phase

Reviewed-by: tschatzl, sjohanss

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

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


From kbarrett at openjdk.java.net  Thu Jan 20 21:42:52 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 20 Jan 2022 21:42:52 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats [v2]
In-Reply-To: <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
 <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
Message-ID: <UpkxeJ5Pe449Kdf3-_AEmhIhD1NbVZ9HtmDMKoqRzDA=.d61ca533-5f1e-401a-8a19-b49355169e91@github.com>

On Thu, 20 Jan 2022 11:11:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews that improves task queue statistics?
>> 
>> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
>> 
>> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
>> 
>> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
>> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>>   0    3777115    3776816       3872      17434       9630          0          0
>> 
>> And new:
>> 
>> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
>> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
>> [...]
>> 
>> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
>> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
>> 
>> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some further cleanup
>  - kbarrett review

Marked as reviewed by kbarrett (Reviewer).

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

> 206: // (4) Thief will discard the read value, because its cmpxchg of age will fail.
> 207: template<class E, MEMFLAGS F, unsigned int N>
> 208: typename GenericTaskQueue<E, F, N>::PopResult GenericTaskQueue<E, F, N>::pop_global(E& t) {

These are places that are just made for trailing return types, putting the return type in the scope of the function.  That's still in the "undecided features" list in the style guide though.


template<class E, MEMFLAGS F, unsigned int N>
auto GenericTaskQueue<E, F, N>::pop_global(E& t) -> PopResult { ... }

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

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


From tschatzl at openjdk.java.net  Fri Jan 21 08:48:44 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 21 Jan 2022 08:48:44 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <uCz-qqUFbTdMKbrdWqbgtXQgdqyv9lgqhNKS3pKBdLs=.847267b4-4532-4db7-ae7e-24c6540e6df5@github.com>

On Thu, 20 Jan 2022 09:49:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

Testing seems all good (tier1-5)

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

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


From mli at openjdk.java.net  Fri Jan 21 09:07:49 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 21 Jan 2022 09:07:49 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <SLGLfPYWGW59Bx18Otv1LsJwLzVn1sF9yGsOI5mK60c=.beb8658e-2bb9-4fd6-a8d6-98099ba77cdd@github.com>

On Thu, 20 Jan 2022 09:49:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

Thanks Thomas for testing and updating. Will update the comment.

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

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


From mli at openjdk.java.net  Fri Jan 21 09:20:51 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 21 Jan 2022 09:20:51 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure
In-Reply-To: <1695HD4rCrUjjkvH1wdu3GH-FPNMLPLnMXWbqlrNiAk=.2ccbaad7-56dc-4d2a-bdd2-2438b1c7899d@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
 <1695HD4rCrUjjkvH1wdu3GH-FPNMLPLnMXWbqlrNiAk=.2ccbaad7-56dc-4d2a-bdd2-2438b1c7899d@github.com>
Message-ID: <egMYlB6AqFda_RFW9AFgki6lcd0YoH619FKNZawEO9g=.80fbe0f0-0c3c-46b9-94a9-2517471fc508@github.com>

On Thu, 20 Jan 2022 10:15:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.
>
> src/hotspot/share/gc/g1/g1RemSet.cpp line 1960:
> 
>> 1958: 
>> 1959:       HeapWord* cur = hr->bottom();
>> 1960:       while (cur < hr->top()) {
> 
> I think it is possible (and less misleading) to just use a `while (true) {` loop. Neither a condition containing `end()` or `top()` is correct. The only boundary that matters is `top_at_rebuild_start()`; since it can change between iterations, and it is needed in the loop I do not see a good condition here.
> (Using `top()` may exit the loop just a tiny bit earlier than the `next_chunk.is_empty()` check below though, but for simplicity, i.e. having one exit condition less to think about, it might be useful to just state `true` here).

Agree, will upate the patch.

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

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


From tschatzl at openjdk.java.net  Fri Jan 21 11:52:13 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 21 Jan 2022 11:52:13 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing
Message-ID: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>

Hi all,

  can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).

Testing: gha (building), local testing

Thanks,
  Thomas

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

Commit messages:
 - Initial implementation using CollectedHeap

Changes: https://git.openjdk.java.net/jdk/pull/7174/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7174&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280397
  Stats: 138 lines in 8 files changed: 68 ins; 64 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7174.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7174/head:pull/7174

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


From mli at openjdk.java.net  Fri Jan 21 12:41:33 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 21 Jan 2022 12:41:33 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure [v2]
In-Reply-To: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
Message-ID: <49k4_fuOPsrrMVwTMaPILzsg9Sxp_rF7rmto94rBV6o=.c4a478ff-6c15-429d-85de-ae19c44453fc@github.com>

> Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.

Hamlin Li 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/7154/files
  - new: https://git.openjdk.java.net/jdk/pull/7154/files/aa2f6565..e3c5efe9

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

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

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


From mli at openjdk.java.net  Fri Jan 21 12:52:17 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 21 Jan 2022 12:52:17 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark [v2]
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <QGoo8LTq0atMrOmq6IPtfgwiAHqmwNDld1kAxIt-IgQ=.78f08af4-7ecb-49b4-becf-d6461ee6a404@github.com>

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

Hamlin Li 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/7153/files
  - new: https://git.openjdk.java.net/jdk/pull/7153/files/e28bf093..2fa41ad2

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

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

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


From tschatzl at openjdk.java.net  Fri Jan 21 13:38:52 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 21 Jan 2022 13:38:52 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure [v2]
In-Reply-To: <49k4_fuOPsrrMVwTMaPILzsg9Sxp_rF7rmto94rBV6o=.c4a478ff-6c15-429d-85de-ae19c44453fc@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
 <49k4_fuOPsrrMVwTMaPILzsg9Sxp_rF7rmto94rBV6o=.c4a478ff-6c15-429d-85de-ae19c44453fc@github.com>
Message-ID: <j-zx0F-RHWDW6kFZTtmA5g1_L_0ipWgX2xL7m0jJQ74=.5b4d6a2e-647a-4e85-9b84-385129730f4d@github.com>

On Fri, 21 Jan 2022 12:41:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Jan 21 14:54:13 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 21 Jan 2022 14:54:13 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to make
 work available to other threads
Message-ID: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>

Hi all,

  can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.

This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.

This is the change for g1.

The CR shows some numbers how bad this can be.

Thanks,
  Thomas

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

Commit messages:
 - Initial commit

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

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


From ayang at openjdk.java.net  Fri Jan 21 15:00:16 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 Jan 2022 15:00:16 GMT
Subject: RFR: 8280458: G1: Remove
 G1BlockOffsetTablePart::_next_offset_threshold
Message-ID: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>

This PR consists of two commits:

1. the real change of removing the field and updating surrounding code.
2. refactoring only (rename, comment updates, method inline, etc).

PS: `oop.inline.hpp` is needed for `klass_or_null`; it worked before by accident. Changes to `G1FullGCCompactionPoint` is kept to minimal to avoid conflicts with #7106.

Test: tier1-6

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

Commit messages:
 - rename
 - remove-bot-threshold

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

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


From ayang at openjdk.java.net  Fri Jan 21 16:32:52 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 21 Jan 2022 16:32:52 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
Message-ID: <GG87d0jmc3TXbdQnczN7CwalM7-uX1nslSWlWgNVzUg=.6ab46c47-a76d-430f-9503-60815b8634d3@github.com>

On Mon, 17 Jan 2022 11:00:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
> 
> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
> 
> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
> 
> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
> 
> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
> 
> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
> 
> Thanks,
>   Thomas

Some minor comments/suggestions.

src/hotspot/share/gc/g1/g1FullCollector.cpp line 307:

> 305: 
> 306:   // To avoid OOM when there is memory left.
> 307:   if (!found_new_empty_regions && !has_free_compaction_targets) {

`has_free_compaction_targets` itself should be enough.

src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp line 68:

> 66: inline G1FullGCCompactionPoint* G1DetermineCompactionQueueClosure::next_compaction_point() {
> 67:   return _collector->compaction_point(next_worker());
> 68: }

I don't see much benefit of having such separated in two methods; this is the sole call site of `next_worker()` after all. Instead of `%`, manually setting it to zero on reaching `workers()` is fairly readable as well.

src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp line 77:

> 75:   // Add region to the compaction queue.
> 76:   cp->add(hr);
> 77: }

Instead of relying on all callers passing in the correct `cp`, how about accepting `hr` only and `auto cp = next_compaction_point();` inside this method?

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

Marked as reviewed by ayang (Reviewer).

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


From kbarrett at openjdk.java.net  Fri Jan 21 19:35:15 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 21 Jan 2022 19:35:15 GMT
Subject: RFR: 8280437: Move G1BufferNodeList to gc/shared
Message-ID: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>

Please review this simple (trivial?) change, renaming G1BufferNodeList to
BufferNodeList and moving its files from gc/g1 to gc/shared.

Testing:
mach5 tier1

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

Commit messages:
 - rename G1BufferNodeList

Changes: https://git.openjdk.java.net/jdk/pull/7183/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7183&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280437
  Stats: 185 lines in 9 files changed: 83 ins; 83 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7183/head:pull/7183

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


From mli at openjdk.java.net  Sat Jan 22 04:21:24 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 22 Jan 2022 04:21:24 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
Message-ID: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>

Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.

This patch tries to improve parallelism when walking over the regions in chunks

Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.

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

Commit messages:
 - clean vm options
 - sync region preparation before iterate through chunks in a region
 - use const G1CMBitMap
 - adapt to update_bot_if_crossing_boundary changes
 - Merge branch 'master' into parallelize-evac-failure-in-bm
 - Merge from master
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/7047/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256265
  Stats: 504 lines in 17 files changed: 461 ins; 17 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From kbarrett at openjdk.java.net  Sat Jan 22 08:12:22 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 22 Jan 2022 08:12:22 GMT
Subject: RFR: 8280496: Remove unused G1PageBasedVirtualSpace::pretouch_internal
Message-ID: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>

Please review this trivial change to remove an unused function.

Testing:
mach5 tier1

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

Commit messages:
 - remove unused pretouch_internal

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

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


From kbarrett at openjdk.java.net  Sat Jan 22 19:07:04 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 22 Jan 2022 19:07:04 GMT
Subject: RFR: 8280391: NMT: Correct NMT tag on CollectedHeap
In-Reply-To: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
References: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
Message-ID: <UtwL5WBhhtcwH8kHHjtZx7f8Vc7lguQ1A4guY_y1GLI=.d9ead204-8d3c-4ef6-a0d4-f6cd2b50b877@github.com>

On Thu, 20 Jan 2022 15:54:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch.
> 
> Heap is the centerpiece of GC, it is odd to see that it is tagged as mtInternal.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jan 24 08:23:09 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 08:23:09 GMT
Subject: RFR: 8280391: NMT: Correct NMT tag on CollectedHeap
In-Reply-To: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
References: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
Message-ID: <qXr97jzkGC5RQe9ec3O26lHj8Wfa2U35p5k0FxMr2RM=.e49d1045-ef16-4eae-b551-85bd928077f1@github.com>

On Thu, 20 Jan 2022 15:54:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch.
> 
> Heap is the centerpiece of GC, it is odd to see that it is tagged as mtInternal.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jan 24 08:23:10 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 08:23:10 GMT
Subject: RFR: 8280496: Remove unused
 G1PageBasedVirtualSpace::pretouch_internal
In-Reply-To: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
References: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
Message-ID: <LfRADZd5NZFJnUMvzcD89zUBRvoYt_CYOUIlh7u6cHk=.17ec966d-4473-4778-88b4-fc2841991308@github.com>

On Sat, 22 Jan 2022 08:05:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove an unused function.
> 
> Testing:
> mach5 tier1

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Jan 24 08:23:10 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 08:23:10 GMT
Subject: RFR: 8280496: Remove unused
 G1PageBasedVirtualSpace::pretouch_internal
In-Reply-To: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
References: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
Message-ID: <BPlE-ML_rlsWnICLQAsSnOuRHfRyxzBBeSecdkolSYE=.9ede1082-0dc8-449b-aedc-33452b3b0738@github.com>

On Sat, 22 Jan 2022 08:05:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove an unused function.
> 
> Testing:
> mach5 tier1

Marked as reviewed by sjohanss (Reviewer).

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

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


From sjohanss at openjdk.java.net  Mon Jan 24 08:47:04 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 08:47:04 GMT
Subject: RFR: 8280437: Move G1BufferNodeList to gc/shared
In-Reply-To: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
References: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
Message-ID: <NOw48aoepgtGt6o6WHfgLOU_FhXV3CCK_R9_UF8dWXE=.de34e9cb-5211-490f-9051-3cfc9ef535a6@github.com>

On Fri, 21 Jan 2022 18:58:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change, renaming G1BufferNodeList to
> BufferNodeList and moving its files from gc/g1 to gc/shared.
> 
> Testing:
> mach5 tier1

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From pliden at openjdk.java.net  Mon Jan 24 08:48:08 2022
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 24 Jan 2022 08:48:08 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing
In-Reply-To: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
Message-ID: <10cynGvFwS95ZlR-f5M7LmPbUklFlQGNHEdJEJiXcyw=.bdef10ad-b245-4ef0-859f-0b46988b1f85@github.com>

On Fri, 21 Jan 2022 11:45:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
> 
> Testing: gha (building), local testing
> 
> Thanks,
>   Thomas

src/hotspot/share/gc/shared/collectedHeap.inline.hpp line 55:

> 53: #if TASKQUEUE_STATS
> 54: template <class T, MEMFLAGS F>
> 55: inline void CollectedHeap::print_and_reset_taskqueue_stats(GenericTaskQueueSet<T, F>* queue_set, const char* label) const {

Can we please move this function to `GenericTaskQueueSet`? It seems to have little to do with `CollectedHeap`.

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 08:59:09 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 08:59:09 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing
In-Reply-To: <10cynGvFwS95ZlR-f5M7LmPbUklFlQGNHEdJEJiXcyw=.bdef10ad-b245-4ef0-859f-0b46988b1f85@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <10cynGvFwS95ZlR-f5M7LmPbUklFlQGNHEdJEJiXcyw=.bdef10ad-b245-4ef0-859f-0b46988b1f85@github.com>
Message-ID: <6Au8incMN5OnDEcFKlpVnTtmZ8i1YaLekj6QGF_jxNA=.69f3a99c-d395-402a-ba38-f80349e2e74c@github.com>

On Mon, 24 Jan 2022 08:44:32 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
>> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
>> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
>> 
>> Testing: gha (building), local testing
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/shared/collectedHeap.inline.hpp line 55:
> 
>> 53: #if TASKQUEUE_STATS
>> 54: template <class T, MEMFLAGS F>
>> 55: inline void CollectedHeap::print_and_reset_taskqueue_stats(GenericTaskQueueSet<T, F>* queue_set, const char* label) const {
> 
> Can we please move this function to `GenericTaskQueueSet`? It seems to have little to do with `CollectedHeap`.

That is fine with me; the reason I put it there has been that it sets up the logging specifically for GC which I did feel not appropriate for the taskqueue. Passing an outputstream to this would require to add per-collector helper methods again...

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

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


From sjohanss at openjdk.java.net  Mon Jan 24 09:10:07 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 09:10:07 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
Message-ID: <ZbE92p60gjJUVUy304Vyy6wgRiCBLL44K2v8DWZbKeY=.36d7e07d-8179-44b7-9dfb-486d7dcae09a@github.com>

On Mon, 17 Jan 2022 11:00:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
> 
> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
> 
> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
> 
> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
> 
> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
> 
> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
> 
> Thanks,
>   Thomas

Looks good, just one small comment.

src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp line 134:

> 132:   if (!_collector->is_compaction_target(region_idx)) {
> 133:     assert(!hr->is_free(), "all free regions should be compaction targets");
> 134:     assert(_collector->is_skip_compacting(region_idx) || hr->is_closed_archive(), "must be"); // FIXME: second clause

What's to fix? Either fix or remove the comment :)

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

Marked as reviewed by sjohanss (Reviewer).

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


From iwalulya at openjdk.java.net  Mon Jan 24 09:15:08 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 24 Jan 2022 09:15:08 GMT
Subject: RFR: 8280437: Move G1BufferNodeList to gc/shared
In-Reply-To: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
References: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
Message-ID: <7XEKdgUCh6DjbO8vG-PnjB0dSgD59dDpwwzU3cLDVCs=.03a95527-51c4-4a08-a1fb-4563fdd2a6f2@github.com>

On Fri, 21 Jan 2022 18:58:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change, renaming G1BufferNodeList to
> BufferNodeList and moving its files from gc/g1 to gc/shared.
> 
> Testing:
> mach5 tier1

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From pliden at openjdk.java.net  Mon Jan 24 09:19:10 2022
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 24 Jan 2022 09:19:10 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing
In-Reply-To: <6Au8incMN5OnDEcFKlpVnTtmZ8i1YaLekj6QGF_jxNA=.69f3a99c-d395-402a-ba38-f80349e2e74c@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <10cynGvFwS95ZlR-f5M7LmPbUklFlQGNHEdJEJiXcyw=.bdef10ad-b245-4ef0-859f-0b46988b1f85@github.com>
 <6Au8incMN5OnDEcFKlpVnTtmZ8i1YaLekj6QGF_jxNA=.69f3a99c-d395-402a-ba38-f80349e2e74c@github.com>
Message-ID: <oLEHN4F9bIcew3O8ZMaelnxGYHo6KOfg6FEvn5TpECE=.dda2b1ab-aa13-4e25-8a70-ae02a078a144@github.com>

On Mon, 24 Jan 2022 08:55:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/collectedHeap.inline.hpp line 55:
>> 
>>> 53: #if TASKQUEUE_STATS
>>> 54: template <class T, MEMFLAGS F>
>>> 55: inline void CollectedHeap::print_and_reset_taskqueue_stats(GenericTaskQueueSet<T, F>* queue_set, const char* label) const {
>> 
>> Can we please move this function to `GenericTaskQueueSet`? It seems to have little to do with `CollectedHeap`.
>
> That is fine with me; the reason I put it there has been that it sets up the logging specifically for GC which I did feel not appropriate for the taskqueue. Passing an outputstream to this would require to add per-collector helper methods again...

I'm not sure I follow. Can't we just move the whole function as is? I'm thinking all collectors want to log in the same way, so no need to separate out the logging setup.

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

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


From mli at openjdk.java.net  Mon Jan 24 09:25:09 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 24 Jan 2022 09:25:09 GMT
Subject: RFR: 8280496: Remove unused
 G1PageBasedVirtualSpace::pretouch_internal
In-Reply-To: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
References: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
Message-ID: <W9L6QLe5st0MKDeGuXFQ-dzhs8melxb6_awtitw35DE=.8ef3540e-5f67-4480-9a4e-c773719fff0d@github.com>

On Sat, 22 Jan 2022 08:05:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove an unused function.
> 
> Testing:
> mach5 tier1

Marked as reviewed by mli (Reviewer).

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

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


From mli at openjdk.java.net  Mon Jan 24 09:25:10 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 24 Jan 2022 09:25:10 GMT
Subject: RFR: 8280437: Move G1BufferNodeList to gc/shared
In-Reply-To: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
References: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
Message-ID: <_cQgATDYxG5ykF1aVlfivOFMrQf0kpBNyY0Wxl9U23Q=.b52621c7-6685-44e4-8388-aff117fa4eb2@github.com>

On Fri, 21 Jan 2022 18:58:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change, renaming G1BufferNodeList to
> BufferNodeList and moving its files from gc/g1 to gc/shared.
> 
> Testing:
> mach5 tier1

Marked as reviewed by mli (Reviewer).

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

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


From mli at openjdk.java.net  Mon Jan 24 09:26:08 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 24 Jan 2022 09:26:08 GMT
Subject: RFR: 8280391: NMT: Correct NMT tag on CollectedHeap
In-Reply-To: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
References: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
Message-ID: <nPzV2YrE9sduIXBL5fcnJWrqT48x9unkmrO2Ibagneo=.02ec5cc1-d53d-41ed-abc5-fdc2a08c8a7b@github.com>

On Thu, 20 Jan 2022 15:54:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch.
> 
> Heap is the centerpiece of GC, it is odd to see that it is tagged as mtInternal.

Marked as reviewed by mli (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 09:35:04 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 09:35:04 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing
In-Reply-To: <oLEHN4F9bIcew3O8ZMaelnxGYHo6KOfg6FEvn5TpECE=.dda2b1ab-aa13-4e25-8a70-ae02a078a144@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <10cynGvFwS95ZlR-f5M7LmPbUklFlQGNHEdJEJiXcyw=.bdef10ad-b245-4ef0-859f-0b46988b1f85@github.com>
 <6Au8incMN5OnDEcFKlpVnTtmZ8i1YaLekj6QGF_jxNA=.69f3a99c-d395-402a-ba38-f80349e2e74c@github.com>
 <oLEHN4F9bIcew3O8ZMaelnxGYHo6KOfg6FEvn5TpECE=.dda2b1ab-aa13-4e25-8a70-ae02a078a144@github.com>
Message-ID: <uur2-WAuYcVM5yMfqFrMc8qxhASFw98VpsaGfxVQHCs=.4d7e6766-fb7a-4ac5-99dc-24833b0c2163@github.com>

On Mon, 24 Jan 2022 09:15:45 GMT, Per Liden <pliden at openjdk.org> wrote:

> [...] I'm thinking all collectors want to log in the same way [...]

That's why I initially put it in `CollectedHeap`, because the _collectors_ should determine where to log to, not necessarily the class. `CollectedHeap` already contains quite a few `print*` methods too.
There also were some experimental uses of `GenericTaskQueue` for other purposes than keeping oops I them recently (still in GC code).

Currently testing a change that simply moves the method as suggested. I do not have a very strong opinion about this.

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 09:38:39 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 09:38:39 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v2]
In-Reply-To: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
Message-ID: <LBfEw1rqiUChPM74qmP5xyIqutuV1UPhjEL5EFEjqb4=.28a567a0-cff7-450e-828a-dddb4ca642bd@github.com>

> Hi all,
> 
>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
> 
> Testing: gha (building), local testing
> 
> Thanks,
>   Thomas

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

  pliden review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7174/files
  - new: https://git.openjdk.java.net/jdk/pull/7174/files/d97fc2c5..bc9edc9e

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

  Stats: 44 lines in 5 files changed: 19 ins; 24 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7174.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7174/head:pull/7174

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


From tschatzl at openjdk.java.net  Mon Jan 24 09:48:11 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 09:48:11 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <GG87d0jmc3TXbdQnczN7CwalM7-uX1nslSWlWgNVzUg=.6ab46c47-a76d-430f-9503-60815b8634d3@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
 <GG87d0jmc3TXbdQnczN7CwalM7-uX1nslSWlWgNVzUg=.6ab46c47-a76d-430f-9503-60815b8634d3@github.com>
Message-ID: <QjiKbdZkOPg_1BowlKPVOpwqV-P1CzJ6ccMlQJyNCo8=.4a37da1a-4cdd-4939-b91e-15f56ce2b381@github.com>

On Fri, 21 Jan 2022 16:15:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
>> 
>> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
>> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
>> 
>> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
>> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
>> 
>> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
>> 
>> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
>> 
>> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp line 68:
> 
>> 66: inline G1FullGCCompactionPoint* G1DetermineCompactionQueueClosure::next_compaction_point() {
>> 67:   return _collector->compaction_point(next_worker());
>> 68: }
> 
> I don't see much benefit of having such separated in two methods; this is the sole call site of `next_worker()` after all. Instead of `%`, manually setting it to zero on reaching `workers()` is fairly readable as well.

This is a fairly trivial implementation for `next_worker()` to fix the issue at hand. As suggested by the description, there needs to be some more thought put into it to handle e.g. imbalance of region occupancies or humongous regions.
Unless you insist I would like to keep the current implementation as is.

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

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


From ayang at openjdk.java.net  Mon Jan 24 09:55:08 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 24 Jan 2022 09:55:08 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <QjiKbdZkOPg_1BowlKPVOpwqV-P1CzJ6ccMlQJyNCo8=.4a37da1a-4cdd-4939-b91e-15f56ce2b381@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
 <GG87d0jmc3TXbdQnczN7CwalM7-uX1nslSWlWgNVzUg=.6ab46c47-a76d-430f-9503-60815b8634d3@github.com>
 <QjiKbdZkOPg_1BowlKPVOpwqV-P1CzJ6ccMlQJyNCo8=.4a37da1a-4cdd-4939-b91e-15f56ce2b381@github.com>
Message-ID: <CAEygLcIHmsIuKn3bgKsonQUYGkcQOh9bwUneBPwvmw=.3e08a1c4-b507-4972-9619-866138291b78@github.com>

On Mon, 24 Jan 2022 09:44:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I would like to keep the current implementation as is.

Sure.

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 09:55:08 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 09:55:08 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <ZbE92p60gjJUVUy304Vyy6wgRiCBLL44K2v8DWZbKeY=.36d7e07d-8179-44b7-9dfb-486d7dcae09a@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
 <ZbE92p60gjJUVUy304Vyy6wgRiCBLL44K2v8DWZbKeY=.36d7e07d-8179-44b7-9dfb-486d7dcae09a@github.com>
Message-ID: <fXGzqGkOY6AveQHIr9_GLUaSrX845pIE6TOxGE77xCg=.a13d8a6c-8fbc-44e5-b49f-1a98607291fb@github.com>

On Mon, 24 Jan 2022 08:48:53 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
>> 
>> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
>> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
>> 
>> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
>> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
>> 
>> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
>> 
>> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
>> 
>> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp line 134:
> 
>> 132:   if (!_collector->is_compaction_target(region_idx)) {
>> 133:     assert(!hr->is_free(), "all free regions should be compaction targets");
>> 134:     assert(_collector->is_skip_compacting(region_idx) || hr->is_closed_archive(), "must be"); // FIXME: second clause
> 
> What's to fix? Either fix or remove the comment :)

Remove the comment :)

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

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


From pliden at openjdk.java.net  Mon Jan 24 10:07:05 2022
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 24 Jan 2022 10:07:05 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v2]
In-Reply-To: <LBfEw1rqiUChPM74qmP5xyIqutuV1UPhjEL5EFEjqb4=.28a567a0-cff7-450e-828a-dddb4ca642bd@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <LBfEw1rqiUChPM74qmP5xyIqutuV1UPhjEL5EFEjqb4=.28a567a0-cff7-450e-828a-dddb4ca642bd@github.com>
Message-ID: <GKP5H0kGPUnECsDV4-ui4zbsuX13uYGKBPbDZ-5N3os=.a5183cb9-8b43-413c-8c77-866f2899c051@github.com>

On Mon, 24 Jan 2022 09:38:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
>> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
>> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
>> 
>> Testing: gha (building), local testing
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pliden review

Change looks good to me.

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

Marked as reviewed by pliden (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jan 24 10:13:45 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 10:13:45 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses [v2]
In-Reply-To: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
Message-ID: <QqYX9oLTFxyPAtYdFMMu407kPaQFxEw69nqPpWZScNg=.ad3aea9f-f8bb-463c-a4bc-b70e6034c8eb@github.com>

> Hi all,
> 
>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
> 
> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
> 
> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
> 
> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
> 
> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
> 
> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
> 
> Thanks,
>   Thomas

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

  sjohanss, ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7106/files
  - new: https://git.openjdk.java.net/jdk/pull/7106/files/30ee7079..1500d6c6

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

  Stats: 21 lines in 5 files changed: 3 ins; 7 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7106/head:pull/7106

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


From tschatzl at openjdk.java.net  Mon Jan 24 10:45:26 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 10:45:26 GMT
Subject: RFR: 8280384: Parallel: Remove VMThread specific ParCompactionManager
Message-ID: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>

Hi all,

   can I have reviews for this change? Parallel GC allocates `ParallelGCThreads+1` `ParCompactionManagers`, the last one only used for work in the VM thread. That `ParCompactionManager``s task queue is also not wired into the work stealing mechanism (i.e. the `TaskQueueSet`). This causes unnecessary code duplication when printing statistics for something which is mostly not used at all.

The suggestion is to remove that unnecessarily allocated task queue as it seems unnecessary: this special handling for an apparently uncommon case prevents factoring out task queue statistics code, and use the 0'th `ParcompactionManager` for these tasks which the code states to be just fine (and it is). In e.g. G1 we also just use the 0'th "worker id" and associated data structures when doing work in the VM thread directly.

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - Merge branch 'master' into 8280384-vmthread-parcompactionmanager
 - Remove unnecessary assert
 - Fixes
 - Remove VMThread ParCompactionManager

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

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


From ayang at openjdk.java.net  Mon Jan 24 11:12:05 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 24 Jan 2022 11:12:05 GMT
Subject: RFR: 8280384: Parallel: Remove VMThread specific
 ParCompactionManager
In-Reply-To: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
References: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
Message-ID: <aW1TUpZGXtf-0ip1iKNV09Zj5P67HXsW0Knbo1FHiMk=.e4ab7560-9cdc-4317-b2fe-757db9056dfb@github.com>

On Mon, 24 Jan 2022 10:38:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>    can I have reviews for this change? Parallel GC allocates `ParallelGCThreads+1` `ParCompactionManagers`, the last one only used for work in the VM thread. That `ParCompactionManager`'s task queue is also not wired into the work stealing mechanism (i.e. the `TaskQueueSet`). This causes unnecessary code duplication when printing statistics for something which is mostly not used at all.
> 
> The suggestion is to remove that unnecessarily allocated task queue as it seems unnecessary: this special handling for an apparently uncommon case prevents factoring out task queue statistics code, and use the 0'th `ParcompactionManager` for these tasks which the code states to be just fine (and it is). In e.g. G1 we also just use the 0'th "worker id" and associated data structures when doing work in the VM thread directly.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 11:23:43 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 11:23:43 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v2]
In-Reply-To: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
Message-ID: <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>

> Hi all,
> 
>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
> 
> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
> 
> This is the change for g1.
> 
> The CR shows some numbers how bad this can be.
> 
> Thanks,
>   Thomas

Thomas Schatzl 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 8280396-g1-fullgc-stack-drain
 - Remove unused methods
 - Initial commit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7175/files
  - new: https://git.openjdk.java.net/jdk/pull/7175/files/56503a5d..13648b7d

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

  Stats: 217 lines in 28 files changed: 148 ins; 35 del; 34 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7175/head:pull/7175

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


From tschatzl at openjdk.java.net  Mon Jan 24 12:05:08 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 12:05:08 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v2]
In-Reply-To: <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>
Message-ID: <4CF6aiNlYxKiSLSQek6H9ETA2ArvnkOPznSYiOuQ2eI=.7a35ddec-1c0f-42a5-a4f3-cf4454d2795a@github.com>

On Mon, 24 Jan 2022 11:23:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
>> 
>> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
>> 
>> This is the change for g1.
>> 
>> The CR shows some numbers how bad this can be.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl 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 8280396-g1-fullgc-stack-drain
>  - Remove unused methods
>  - Initial commit

Looking a bit more into improvements for this change.

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

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


From zgu at openjdk.java.net  Mon Jan 24 13:35:10 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 24 Jan 2022 13:35:10 GMT
Subject: RFR: 8280391: NMT: Correct NMT tag on CollectedHeap
In-Reply-To: <UtwL5WBhhtcwH8kHHjtZx7f8Vc7lguQ1A4guY_y1GLI=.d9ead204-8d3c-4ef6-a0d4-f6cd2b50b877@github.com>
References: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
 <UtwL5WBhhtcwH8kHHjtZx7f8Vc7lguQ1A4guY_y1GLI=.d9ead204-8d3c-4ef6-a0d4-f6cd2b50b877@github.com>
Message-ID: <picp-eV6ALX7zvbQoRQ4trPguazKsJ6wk7g2hh-mfE4=.19aa9bff-25f7-4044-bb6e-041b0df85da5@github.com>

On Sat, 22 Jan 2022 19:03:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this trivial patch.
>> 
>> Heap is the centerpiece of GC, it is odd to see that it is tagged as mtInternal.
>
> Looks good.

Thanks, @kimbarrett  @tschatzl  @Hamlin-Li

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

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


From zgu at openjdk.java.net  Mon Jan 24 13:38:12 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 24 Jan 2022 13:38:12 GMT
Subject: Integrated: 8280391: NMT: Correct NMT tag on CollectedHeap
In-Reply-To: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
References: <ER89fKBVJNekbQQ6fB6s7LUHu-mcTR5dYoGhI05H_LU=.b3fdd034-418a-4055-86a3-2e39cbac2fcf@github.com>
Message-ID: <4vT_aOVfbbLmHGMfdTNPSq4uhvmtmknx4pz-n4--0-g=.a93bb2b6-ce4c-4ec7-bc5a-ddd502f9ec34@github.com>

On Thu, 20 Jan 2022 15:54:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch.
> 
> Heap is the centerpiece of GC, it is odd to see that it is tagged as mtInternal.

This pull request has now been integrated.

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

8280391: NMT: Correct NMT tag on CollectedHeap

Reviewed-by: kbarrett, tschatzl, mli

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

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


From sjohanss at openjdk.java.net  Mon Jan 24 14:20:02 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 14:20:02 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v2]
In-Reply-To: <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>
Message-ID: <QZHkK-P4fC6xlIhp2TfGEBNt5mpTR2e9iTZB3h9Ik5Q=.40cf1d9d-f75b-45ce-8a3b-32988bc568cc@github.com>

On Mon, 24 Jan 2022 11:23:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
>> 
>> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
>> 
>> This is the change for g1.
>> 
>> The CR shows some numbers how bad this can be.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl 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 8280396-g1-fullgc-stack-drain
>  - Remove unused methods
>  - Initial commit

Nice improvement. One comment, but I'm fine with the current approach if you prefer it.

src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp line 162:

> 160:         follow_object(obj);
> 161:       }
> 162:     }

What do you think about instead of extracting all this into `drain_stack()` have something like `transfer_from_overflow()` as the first statement in in `pop_object()`? It would either return an object that can't be transferred or push it back to the overflow and just let pop do what it does today. 

The problem I see with that is that `pop_object(...)` would have side effects that you wouldn't really expect, so if doing that maybe we should call it `drain_object_stack(...)` or something like that.

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

Marked as reviewed by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jan 24 15:51:33 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 15:51:33 GMT
Subject: RFR: 8280384: Parallel: Remove VMThread specific
 ParCompactionManager [v2]
In-Reply-To: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
References: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
Message-ID: <h-CdyBcB4c3WpNOewLGZyrtaDYDo3PdfUFh17BxNBVo=.c51a8a75-4bd9-4b9f-8f65-b3db18828220@github.com>

> Hi all,
> 
>    can I have reviews for this change? Parallel GC allocates `ParallelGCThreads+1` `ParCompactionManagers`, the last one only used for work in the VM thread. That `ParCompactionManager`'s task queue is also not wired into the work stealing mechanism (i.e. the `TaskQueueSet`). This causes unnecessary code duplication when printing statistics for something which is mostly not used at all.
> 
> The suggestion is to remove that unnecessarily allocated task queue as it seems unnecessary: this special handling for an apparently uncommon case prevents factoring out task queue statistics code, and use the 0'th `ParcompactionManager` for these tasks which the code states to be just fine (and it is). In e.g. G1 we also just use the 0'th "worker id" and associated data structures when doing work in the VM thread directly.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

  Fix merge error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7195/files
  - new: https://git.openjdk.java.net/jdk/pull/7195/files/14d5f83c..cddd45aa

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

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 16:45:53 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 16:45:53 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v3]
In-Reply-To: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
Message-ID: <joFgSX1j1aSysb1wVa-FNKCM2vQxNERQbzYa-EW1zCo=.0d94d631-3752-4d40-948a-fcad4e01fef4@github.com>

> Hi all,
> 
>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
> 
> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
> 
> This is the change for g1.
> 
> The CR shows some numbers how bad this can be.
> 
> Thanks,
>   Thomas

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

 - More cleanup
 - Refactoring

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7175/files
  - new: https://git.openjdk.java.net/jdk/pull/7175/files/13648b7d..8028a370

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

  Stats: 48 lines in 2 files changed: 26 ins; 7 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7175.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7175/head:pull/7175

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


From tschatzl at openjdk.java.net  Mon Jan 24 16:53:51 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 16:53:51 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v4]
In-Reply-To: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
Message-ID: <iV8wMn_Vbo3TVkIf3L9hXnQzvzlaOqhAq9xb2bHDX1g=.b8c224bd-a37d-4aa5-8386-cf5ad11fca4f@github.com>

> Hi all,
> 
>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
> 
> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
> 
> This is the change for g1.
> 
> The CR shows some numbers how bad this can be.
> 
> Thanks,
>   Thomas

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

  Comments, cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7175/files
  - new: https://git.openjdk.java.net/jdk/pull/7175/files/8028a370..c447ea95

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

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

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


From tschatzl at openjdk.java.net  Mon Jan 24 16:53:54 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 24 Jan 2022 16:53:54 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v2]
In-Reply-To: <QZHkK-P4fC6xlIhp2TfGEBNt5mpTR2e9iTZB3h9Ik5Q=.40cf1d9d-f75b-45ce-8a3b-32988bc568cc@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>
 <QZHkK-P4fC6xlIhp2TfGEBNt5mpTR2e9iTZB3h9Ik5Q=.40cf1d9d-f75b-45ce-8a3b-32988bc568cc@github.com>
Message-ID: <drezkJJOi6hhtRanuQROUFmSHd6f5BnH7O9jKX3zhrY=.375b261a-8be6-4103-a836-5c934edee6c2@github.com>

On Mon, 24 Jan 2022 14:15:22 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl 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 8280396-g1-fullgc-stack-drain
>>  - Remove unused methods
>>  - Initial commit
>
> src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp line 162:
> 
>> 160:         follow_object(obj);
>> 161:       }
>> 162:     }
> 
> What do you think about instead of extracting all this into `drain_stack()` have something like `transfer_from_overflow()` as the first statement in in `pop_object()`? It would either return an object that can't be transferred or push it back to the overflow and just let pop do what it does today. 
> 
> The problem I see with that is that `pop_object(...)` would have side effects that you wouldn't really expect, so if doing that maybe we should call it `drain_object_stack(...)` or something like that.

Refactored the code a bit, to hopefully something better.

I *think* there are some additional gains to be made by not draining the regular oop task queue fully when trying to move work from its overflow stack to the shared one, however measurements were within a few percent so far. I will file an issue for working on that idea - the current change is already much better than what has been there before.

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

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


From kbarrett at openjdk.java.net  Mon Jan 24 17:13:46 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 Jan 2022 17:13:46 GMT
Subject: RFR: 8280496: Remove unused
 G1PageBasedVirtualSpace::pretouch_internal [v2]
In-Reply-To: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
References: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
Message-ID: <ZZcunUC5Hxu5VZQW57xDu9LHesw3rKL1vQBp6qBumN4=.01518f7e-2569-42b1-93e8-9c09a87256ea@github.com>

> Please review this trivial change to remove an unused function.
> 
> 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 remove-pretouch-internal
 - remove unused pretouch_internal

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7186/files
  - new: https://git.openjdk.java.net/jdk/pull/7186/files/eeca4c3e..566f024c

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

  Stats: 483 lines in 42 files changed: 350 ins; 52 del; 81 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7186.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7186/head:pull/7186

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


From kbarrett at openjdk.java.net  Mon Jan 24 17:13:47 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 Jan 2022 17:13:47 GMT
Subject: RFR: 8280496: Remove unused
 G1PageBasedVirtualSpace::pretouch_internal [v2]
In-Reply-To: <LfRADZd5NZFJnUMvzcD89zUBRvoYt_CYOUIlh7u6cHk=.17ec966d-4473-4778-88b4-fc2841991308@github.com>
References: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
 <LfRADZd5NZFJnUMvzcD89zUBRvoYt_CYOUIlh7u6cHk=.17ec966d-4473-4778-88b4-fc2841991308@github.com>
Message-ID: <WAk37CtbJLFFdgGUVTt_rpcOCzQFz4RCx8DP8w7n1B0=.cc33ca76-dfdc-4f71-99f1-759977a3cff1@github.com>

On Mon, 24 Jan 2022 08:19:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> 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 remove-pretouch-internal
>>  - remove unused pretouch_internal
>
> Lgtm and trivial.

Thanks @tschatzl , @kstefanj , @Hamlin-Li for reviews.

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

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


From kbarrett at openjdk.java.net  Mon Jan 24 17:13:48 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 Jan 2022 17:13:48 GMT
Subject: Integrated: 8280496: Remove unused
 G1PageBasedVirtualSpace::pretouch_internal
In-Reply-To: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
References: <xFoLis-Kp4Fxe-sDcI0251rcY5EVh_W3HTgpDp_D0hc=.03cecd65-83d9-4cdd-9b46-45d0482e9490@github.com>
Message-ID: <4uePhpMeyUFzMUOLlVjIH5-4_5vtFhBQMqP_ahbVx5s=.6002c506-39a0-49f9-bf43-ed6a4b890cf3@github.com>

On Sat, 22 Jan 2022 08:05:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove an unused function.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: 4b329add
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4b329addf1aca4b5f67057b5c6852d283d0c8f49
Stats:     12 lines in 2 files changed: 0 ins; 10 del; 2 mod

8280496: Remove unused G1PageBasedVirtualSpace::pretouch_internal

Reviewed-by: tschatzl, sjohanss, mli

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

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


From kbarrett at openjdk.java.net  Mon Jan 24 17:28:55 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 Jan 2022 17:28:55 GMT
Subject: RFR: 8280437: Move G1BufferNodeList to gc/shared [v2]
In-Reply-To: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
References: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
Message-ID: <QliWidbh4WPZlB_IeGMwsaW4Ty-l4ZpeA_WwMjYiMGQ=.f4a195d8-c76f-48fe-91aa-77494858427b@github.com>

> Please review this simple (trivial?) change, renaming G1BufferNodeList to
> BufferNodeList and moving its files from gc/g1 to gc/shared.
> 
> 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 rename-bnl
 - rename G1BufferNodeList

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7183/files
  - new: https://git.openjdk.java.net/jdk/pull/7183/files/3761c3e4..288acaf3

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

  Stats: 774 lines in 78 files changed: 498 ins; 112 del; 164 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7183.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7183/head:pull/7183

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


From kbarrett at openjdk.java.net  Mon Jan 24 17:28:56 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 Jan 2022 17:28:56 GMT
Subject: RFR: 8280437: Move G1BufferNodeList to gc/shared [v2]
In-Reply-To: <7XEKdgUCh6DjbO8vG-PnjB0dSgD59dDpwwzU3cLDVCs=.03a95527-51c4-4a08-a1fb-4563fdd2a6f2@github.com>
References: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
 <7XEKdgUCh6DjbO8vG-PnjB0dSgD59dDpwwzU3cLDVCs=.03a95527-51c4-4a08-a1fb-4563fdd2a6f2@github.com>
Message-ID: <RktfJ-Ta1bRSL1k-nGl35JgbqsDwjGCwhoQiMdEkr-E=.71e14068-f7d6-47bc-bee3-a7b899883eb9@github.com>

On Mon, 24 Jan 2022 09:12:13 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> 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 rename-bnl
>>  - rename G1BufferNodeList
>
> Lgtm!

Thanks @walulyai , @Hamlin-Li , and @kstefanj for reviews.

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

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


From kbarrett at openjdk.java.net  Mon Jan 24 17:28:58 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 24 Jan 2022 17:28:58 GMT
Subject: Integrated: 8280437: Move G1BufferNodeList to gc/shared
In-Reply-To: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
References: <bQFOiaWy8hG9NYRX6vhOtle_eqyctWfF-GX73we5C1I=.08997ef1-1b9c-4abd-8c92-2e547f02d07c@github.com>
Message-ID: <Kli-Z55FpMa_ceYdyLAeChyU9uHDW8EQpueFihBgEw8=.549d5289-635f-4348-b54a-6853ab2123d6@github.com>

On Fri, 21 Jan 2022 18:58:47 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simple (trivial?) change, renaming G1BufferNodeList to
> BufferNodeList and moving its files from gc/g1 to gc/shared.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: 1c7769d3
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1c7769d35b3a2aa4afe3125239dbfa1da5cfdeee
Stats:     185 lines in 9 files changed: 83 ins; 83 del; 19 mod

8280437: Move G1BufferNodeList to gc/shared

Reviewed-by: sjohanss, iwalulya, mli

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

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


From sjohanss at openjdk.java.net  Mon Jan 24 19:54:13 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 19:54:13 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v4]
In-Reply-To: <iV8wMn_Vbo3TVkIf3L9hXnQzvzlaOqhAq9xb2bHDX1g=.b8c224bd-a37d-4aa5-8386-cf5ad11fca4f@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <iV8wMn_Vbo3TVkIf3L9hXnQzvzlaOqhAq9xb2bHDX1g=.b8c224bd-a37d-4aa5-8386-cf5ad11fca4f@github.com>
Message-ID: <SBSg-IXbLU6VfNg6f4JtnqQDUVmRIRFHczf1MsarcW4=.7efb3276-37b7-42df-ad80-3a25240da270@github.com>

On Mon, 24 Jan 2022 16:53:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
>> 
>> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
>> 
>> This is the change for g1.
>> 
>> The CR shows some numbers how bad this can be.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments, cleanup

Marked as reviewed by sjohanss (Reviewer).

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

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


From sjohanss at openjdk.java.net  Mon Jan 24 19:54:14 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 19:54:14 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v2]
In-Reply-To: <drezkJJOi6hhtRanuQROUFmSHd6f5BnH7O9jKX3zhrY=.375b261a-8be6-4103-a836-5c934edee6c2@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <CH-gojnXXRJ39hyl6OYUMZoHb6spKAHiX8Ra4ahW2oA=.9d403453-ab08-4889-b21b-4cc81e55c729@github.com>
 <QZHkK-P4fC6xlIhp2TfGEBNt5mpTR2e9iTZB3h9Ik5Q=.40cf1d9d-f75b-45ce-8a3b-32988bc568cc@github.com>
 <drezkJJOi6hhtRanuQROUFmSHd6f5BnH7O9jKX3zhrY=.375b261a-8be6-4103-a836-5c934edee6c2@github.com>
Message-ID: <7dYqkWfseWexqlJF0cwzVmgKqPRR0Sswmlh6Z1fE10w=.9112ab23-cd4e-4c26-8d8c-0d83b7a8e6fa@github.com>

On Mon, 24 Jan 2022 16:48:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp line 162:
>> 
>>> 160:         follow_object(obj);
>>> 161:       }
>>> 162:     }
>> 
>> What do you think about instead of extracting all this into `drain_stack()` have something like `transfer_from_overflow()` as the first statement in in `pop_object()`? It would either return an object that can't be transferred or push it back to the overflow and just let pop do what it does today. 
>> 
>> The problem I see with that is that `pop_object(...)` would have side effects that you wouldn't really expect, so if doing that maybe we should call it `drain_object_stack(...)` or something like that.
>
> Refactored the code a bit, to hopefully something better.
> 
> I *think* there are some additional gains to be made by not draining the regular oop task queue fully when trying to move work from its overflow stack to the shared one, however measurements were within a few percent so far. I will file an issue for working on that idea - the current change is already much better than what has been there before.

I think this is better and I'm not too worried if this is not optimal. As you say, still a good improvement.

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

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


From sjohanss at openjdk.java.net  Mon Jan 24 20:17:05 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 24 Jan 2022 20:17:05 GMT
Subject: RFR: 8280384: Parallel: Remove VMThread specific
 ParCompactionManager [v2]
In-Reply-To: <h-CdyBcB4c3WpNOewLGZyrtaDYDo3PdfUFh17BxNBVo=.c51a8a75-4bd9-4b9f-8f65-b3db18828220@github.com>
References: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
 <h-CdyBcB4c3WpNOewLGZyrtaDYDo3PdfUFh17BxNBVo=.c51a8a75-4bd9-4b9f-8f65-b3db18828220@github.com>
Message-ID: <7D7JMr_sdQQFkX-JKeJTqiPM8VDszrcu8Zdlm8av-Fs=.f14eeba9-ba5f-4520-a2ff-127f79907661@github.com>

On Mon, 24 Jan 2022 15:51:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>    can I have reviews for this change? Parallel GC allocates `ParallelGCThreads+1` `ParCompactionManagers`, the last one only used for work in the VM thread. That `ParCompactionManager`'s task queue is also not wired into the work stealing mechanism (i.e. the `TaskQueueSet`). This causes unnecessary code duplication when printing statistics for something which is mostly not used at all.
>> 
>> The suggestion is to remove that unnecessarily allocated task queue as it seems unnecessary: this special handling for an apparently uncommon case prevents factoring out task queue statistics code, and use the 0'th `ParcompactionManager` for these tasks which the code states to be just fine (and it is). In e.g. G1 we also just use the 0'th "worker id" and associated data structures when doing work in the VM thread directly.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge error

Marked as reviewed by sjohanss (Reviewer).

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

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


From ayang at openjdk.java.net  Mon Jan 24 21:58:10 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 24 Jan 2022 21:58:10 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark [v2]
In-Reply-To: <QGoo8LTq0atMrOmq6IPtfgwiAHqmwNDld1kAxIt-IgQ=.78f08af4-7ecb-49b4-becf-d6461ee6a404@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
 <QGoo8LTq0atMrOmq6IPtfgwiAHqmwNDld1kAxIt-IgQ=.78f08af4-7ecb-49b4-becf-d6461ee6a404@github.com>
Message-ID: <r4p0WsC0gGMb00L9x2xF38sjDpsco0ns1Xe3UqdGs_o=.5cb8cdaf-a8cd-4dd5-acc6-db16e9420512@github.com>

On Fri, 21 Jan 2022 12:52:17 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

Just for my own understanding, the removed line (L136) could have been an assert that bits for `mr` are *not* set, right?

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

Marked as reviewed by ayang (Reviewer).

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


From ayang at openjdk.java.net  Mon Jan 24 22:19:08 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 24 Jan 2022 22:19:08 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure [v2]
In-Reply-To: <49k4_fuOPsrrMVwTMaPILzsg9Sxp_rF7rmto94rBV6o=.c4a478ff-6c15-429d-85de-ae19c44453fc@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
 <49k4_fuOPsrrMVwTMaPILzsg9Sxp_rF7rmto94rBV6o=.c4a478ff-6c15-429d-85de-ae19c44453fc@github.com>
Message-ID: <aYBe-q_Sm_ScqZ7cZFKDygKVG8Jnjedv__hP88sSFIY=.970c8b3b-ee25-4164-9c78-f74537380600@github.com>

On Fri, 21 Jan 2022 12:41:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

Marked as reviewed by ayang (Reviewer).

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

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


From kbarrett at openjdk.java.net  Tue Jan 25 05:10:59 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 25 Jan 2022 05:10:59 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid walking
 pending list
Message-ID: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>

Please review this change to BufferNode::Allocator::release to avoid needing
to walk the pending list in preparation for transferring it to the free list.
We need to have both the head and the tail of the pending list to perform that
transfer.

Rather than using a LockFreeStack to accumulate the pending list, we now use a
bespoke data structure that only supports concurrent additions, since that's
all we need.  This simplifies the code, and also makes it easy to capture the
first pushed node as the tail.

To make the transfer from the pending list to the free list, we double-buffer
the pending list.  Additions are made to the currently active pending list.  A
transfer flips which pending list is active, and transfers from the list that
was just deactivated.  Additions are made in a critical section.  The critical
section synchronization already performed when transferring now does double
duty, also synchronizing the pending list flip.

Testing:
mach5 tier1-3

Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
occurring as expected.

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

Commit messages:
 - double-buffer pending list

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

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


From mli at openjdk.java.net  Tue Jan 25 06:41:10 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 25 Jan 2022 06:41:10 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark [v3]
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <0A5lLfnnbocRNE4E4lwzAaYMPeuN9FhdgBMW-4Q8emE=.082e548e-f201-46de-81d1-8f07258e0e4a@github.com>

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

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/7153/files
  - new: https://git.openjdk.java.net/jdk/pull/7153/files/2fa41ad2..048f1896

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

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

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


From mli at openjdk.java.net  Tue Jan 25 06:41:12 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 25 Jan 2022 06:41:12 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark [v2]
In-Reply-To: <QGoo8LTq0atMrOmq6IPtfgwiAHqmwNDld1kAxIt-IgQ=.78f08af4-7ecb-49b4-becf-d6461ee6a404@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
 <QGoo8LTq0atMrOmq6IPtfgwiAHqmwNDld1kAxIt-IgQ=.78f08af4-7ecb-49b4-becf-d6461ee6a404@github.com>
Message-ID: <pxhbpCrPN4WQQsW55UTmLrsl7Zk-n_kqsMkyUz80GCw=.bd554746-1ec7-4a12-9869-11c2ee2dc7ab@github.com>

On Fri, 21 Jan 2022 12:52:17 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas review

> Just for my own understanding, the removed line (L136) could have been an assert that bits for `mr` are _not_ set, right?

Agree, I will add assert. Thanks

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 09:15:41 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 09:15:41 GMT
Subject: RFR: 8280384: Parallel: Remove VMThread specific
 ParCompactionManager [v2]
In-Reply-To: <aW1TUpZGXtf-0ip1iKNV09Zj5P67HXsW0Knbo1FHiMk=.e4ab7560-9cdc-4317-b2fe-757db9056dfb@github.com>
References: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
 <aW1TUpZGXtf-0ip1iKNV09Zj5P67HXsW0Knbo1FHiMk=.e4ab7560-9cdc-4317-b2fe-757db9056dfb@github.com>
Message-ID: <b1iAOOwe0db2pj0rdBkAf47kG83sM8-7pnrLzGdE-Ps=.44885bdb-dabb-4165-a3d1-cc77beb073ef@github.com>

On Mon, 24 Jan 2022 11:08:46 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 merge error
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 09:15:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 09:15:42 GMT
Subject: Integrated: 8280384: Parallel: Remove VMThread specific
 ParCompactionManager
In-Reply-To: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
References: <4IiqHcP_0eQQwMp8BjcMyCM5wiFUpn6NOtgAlzQ0p9s=.75a0990d-df8b-4679-a832-08f854f8cc19@github.com>
Message-ID: <iUrCxWUkP_aj3wWaJuHBXtDJln5Jw9lK9Xy-RA-7RUo=.fb368d43-98a3-4074-bbd0-162f094ee463@github.com>

On Mon, 24 Jan 2022 10:38:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>    can I have reviews for this change? Parallel GC allocates `ParallelGCThreads+1` `ParCompactionManagers`, the last one only used for work in the VM thread. That `ParCompactionManager`'s task queue is also not wired into the work stealing mechanism (i.e. the `TaskQueueSet`). This causes unnecessary code duplication when printing statistics for something which is mostly not used at all.
> 
> The suggestion is to remove that unnecessarily allocated task queue as it seems unnecessary: this special handling for an apparently uncommon case prevents factoring out task queue statistics code, and use the 0'th `ParcompactionManager` for these tasks which the code states to be just fine (and it is). In e.g. G1 we also just use the 0'th "worker id" and associated data structures when doing work in the VM thread directly.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: b3277465
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b32774653f72f379655192874cb7076079d238e6
Stats:     51 lines in 7 files changed: 2 ins; 28 del; 21 mod

8280384: Parallel: Remove VMThread specific ParCompactionManager

Reviewed-by: ayang, sjohanss

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 09:17:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 09:17:42 GMT
Subject: RFR: 8279241: G1 Full GC does not always slide memory to bottom
 addresses [v2]
In-Reply-To: <GG87d0jmc3TXbdQnczN7CwalM7-uX1nslSWlWgNVzUg=.6ab46c47-a76d-430f-9503-60815b8634d3@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
 <GG87d0jmc3TXbdQnczN7CwalM7-uX1nslSWlWgNVzUg=.6ab46c47-a76d-430f-9503-60815b8634d3@github.com>
Message-ID: <_LzYcEsOewKAa647ItBbs2-WKKUCqEnMzK9j3BolKk4=.cfd50b5c-cb94-4d0e-bf45-08a1521c7acd@github.com>

On Fri, 21 Jan 2022 16:29:20 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:
>> 
>>   sjohanss, ayang review
>
> Some minor comments/suggestions.

Thanks @albertnetymk @kstefanj @walulyai for your reviews

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 09:17:44 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 09:17:44 GMT
Subject: Integrated: 8279241: G1 Full GC does not always slide memory to bottom
 addresses
In-Reply-To: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
References: <8FbC-AQkOV9HuJvizBRzLOT7VZ3LsG2wz-RYAAq9-h8=.882aa76e-00a2-4a85-ac17-c403b79373c8@github.com>
Message-ID: <jKGAXCZhl1n0VQew6CY1S616bwGTHdFb45sVogq3pqk=.7dfe06ea-a0ce-4cbd-ac0f-1032116beac7@github.com>

On Mon, 17 Jan 2022 11:00:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that completely fixes the possibility that during g1 full gc memory will not be slid to bottom addresses consistently in presence of threads.
> 
> The problem is that multiple thread compete for regions to compact into - it could happen that given live data somewhere "high up" the heap gets to be the bottom region for a particular thread, so all data will be compacted starting from that region.
> The problem with that is region level fragmentation, i.e. that after gc there is not enough free contiguous space for a humongous object, leading to OOME.
> 
> The change splits the phase where determining the compaction point queue (the set of regions a particular thread compacts into) from the part of that phase where the new locations of the objects is determined (i.e. putting a forwarding pointer into the live objects in these regions) and other stuff best done in parallel.
> This makes determining the compaction point queue deterministic (by distributing these regions we can compact into in a round-robin fashion) in a way that always slides live data consistently into the bottom heap area.
> 
> This change also makes it easier to, in the future, improve work distribution of the compaction phase (which directly uses the compaction point queues) by distributing them  according to live data, and also incorporate last-ditch moves of humongous objects.
> 
> The most important thing about this split is probably the changes in the parallel part: every thread must make sure that some work is done on the compaction point queue (i.e. the forwarding), and other work on all regions (clearing metadata, updating the BOT of young regions that are not moved).
> 
> Testing: tier1-5, checking performance on some simple full gc benchmarks with no particular difference
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 295b263f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/295b263fa951b9d51bfa92c04e49b2a17a62bd6f
Stats:     492 lines in 9 files changed: 283 ins; 146 del; 63 mod

8279241: G1 Full GC does not always slide memory to bottom addresses

Reviewed-by: iwalulya, ayang, sjohanss

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

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


From ayang at openjdk.java.net  Tue Jan 25 09:55:14 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 25 Jan 2022 09:55:14 GMT
Subject: RFR: 8280030: [REDO] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range [v2]
In-Reply-To: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
References: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
Message-ID: <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>

> Second try in refining the range calculation in `ObjectStartArray::object_starts_in_range`.
> 
> Test: tier1-6

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/7111/files
  - new: https://git.openjdk.java.net/jdk/pull/7111/files/a3ad3883..d6befa02

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

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

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


From sjohanss at openjdk.java.net  Tue Jan 25 10:03:36 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 25 Jan 2022 10:03:36 GMT
Subject: RFR: 8280030: [REDO] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range [v2]
In-Reply-To: <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>
References: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
 <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>
Message-ID: <c8Q2RQanmLjQB5yWpjCYcGy-fNfMGOBbnaOi4KOGKWg=.38b8d927-b5e6-4de8-b2a5-90e516b73253@github.com>

On Tue, 25 Jan 2022 09:55:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Second try in refining the range calculation in `ObjectStartArray::object_starts_in_range`.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for doing the extra testing. Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From iwalulya at openjdk.java.net  Tue Jan 25 10:14:35 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 25 Jan 2022 10:14:35 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list
In-Reply-To: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
Message-ID: <cQUOeZURJuttXOVb5LASaQBipvGA4OO_Cy70kGrMRDU=.38d320f1-57d6-4cc2-9ffb-6e721c6d3edd@github.com>

On Tue, 25 Jan 2022 05:04:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to BufferNode::Allocator::release to avoid needing
> to walk the pending list in preparation for transferring it to the free list.
> We need to have both the head and the tail of the pending list to perform that
> transfer.
> 
> Rather than using a LockFreeStack to accumulate the pending list, we now use a
> bespoke data structure that only supports concurrent additions, since that's
> all we need.  This simplifies the code, and also makes it easy to capture the
> first pushed node as the tail.
> 
> To make the transfer from the pending list to the free list, we double-buffer
> the pending list.  Additions are made to the currently active pending list.  A
> transfer flips which pending list is active, and transfers from the list that
> was just deactivated.  Additions are made in a critical section.  The critical
> section synchronization already performed when transferring now does double
> duty, also synchronizing the pending list flip.
> 
> Testing:
> mach5 tier1-3
> 
> Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
> occurring as expected.

Nice clean-up!

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

Marked as reviewed by iwalulya (Reviewer).

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


From duke at openjdk.java.net  Tue Jan 25 10:17:06 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Tue, 25 Jan 2022 10:17:06 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset
Message-ID: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>

Can I have review on this small change that skips some unnecessary work in cset choosing?

When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

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

Commit messages:
 - 8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 10:41:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 10:41:34 GMT
Subject: RFR: 8280030: [REDO] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range [v2]
In-Reply-To: <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>
References: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
 <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>
Message-ID: <6RIk8g1XvJobMofoOtMguHudRp-Y6--Kk4Kq4M8o4qc=.ea4fab7f-45d6-444e-8290-2f5085a0a112@github.com>

On Tue, 25 Jan 2022 09:55:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Second try in refining the range calculation in `ObjectStartArray::object_starts_in_range`.
>> 
>> Test: tier1-6
>
> 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/7111


From mli at openjdk.java.net  Tue Jan 25 12:13:07 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 25 Jan 2022 12:13:07 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark [v4]
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <MXqmHzF8Tygjb5RBoe4v98EGlLR__BbkhHBRwir9pRg=.a3898f1a-4e26-4225-a7cc-f191a3d653ff@github.com>

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

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

  keep only prev bitmap assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7153/files
  - new: https://git.openjdk.java.net/jdk/pull/7153/files/048f1896..fc2a3c59

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

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

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


From mli at openjdk.java.net  Tue Jan 25 12:14:33 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 25 Jan 2022 12:14:33 GMT
Subject: RFR: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure [v2]
In-Reply-To: <j-zx0F-RHWDW6kFZTtmA5g1_L_0ipWgX2xL7m0jJQ74=.5b4d6a2e-647a-4e85-9b84-385129730f4d@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
 <49k4_fuOPsrrMVwTMaPILzsg9Sxp_rF7rmto94rBV6o=.c4a478ff-6c15-429d-85de-ae19c44453fc@github.com>
 <j-zx0F-RHWDW6kFZTtmA5g1_L_0ipWgX2xL7m0jJQ74=.5b4d6a2e-647a-4e85-9b84-385129730f4d@github.com>
Message-ID: <eBkhhUBS6BmsMVzLsHFDjr5jcd-q_ydgLTvI9GJG7Cc=.1a7f7663-d052-436c-9ee0-4cf143f413ee@github.com>

On Fri, 21 Jan 2022 13:35:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Thomas review
>
> Lgtm.

Thanks @tschatzl @albertnetymk for you reviews.

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

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


From mli at openjdk.java.net  Tue Jan 25 12:14:34 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 25 Jan 2022 12:14:34 GMT
Subject: Integrated: 8280375: G1: Tighten mem region limit in
 G1RebuildRemSetHeapRegionClosure
In-Reply-To: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
References: <X5OAUDg7AWZkbyvKumtN1-XsE-pA2kk4LMfoEgdWQTo=.7c9a7ad1-2be5-43c6-8afc-781eb899cac7@github.com>
Message-ID: <1B-Z4UwHYsfgB-D811nLOxg2y3OQfZeLml2gG0ilJCs=.1671c5ac-0a2e-47cb-8c04-f318c1306306@github.com>

On Thu, 20 Jan 2022 09:55:21 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, it uses `hr->end()` to guard the mem scan limit, but it should be top instead of end.

This pull request has now been integrated.

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

8280375: G1: Tighten mem region limit in G1RebuildRemSetHeapRegionClosure

Reviewed-by: tschatzl, ayang

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

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


From ayang at openjdk.java.net  Tue Jan 25 14:13:31 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 25 Jan 2022 14:13:31 GMT
Subject: RFR: 8280030: [REDO] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range [v2]
In-Reply-To: <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>
References: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
 <M6HDw_IrRKWhGepAsSqGnkvDyNJyX01kDRI4cf6uwsk=.5a191b1e-50ea-4281-95ff-9aa7e76c4c41@github.com>
Message-ID: <MODgeWV5K-mbPqSjSScPH7rLeUpbFvrZALXC1nZNhf8=.1c3e3750-e1e1-4516-a6d6-f5cf8e0ecc81@github.com>

On Tue, 25 Jan 2022 09:55:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Second try in refining the range calculation in `ObjectStartArray::object_starts_in_range`.
>> 
>> Test: tier1-6
>
> 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/7111


From ayang at openjdk.java.net  Tue Jan 25 14:13:31 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 25 Jan 2022 14:13:31 GMT
Subject: Integrated: 8280030: [REDO] Parallel: More precise boundary in
 ObjectStartArray::object_starts_in_range
In-Reply-To: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
References: <7RLaN-nTWmTxgGejyoqRy_ZKAT5UYe9lO6T3_E7-jhc=.fb1abad4-5ef8-479f-8ff7-eb3ecfbb1581@github.com>
Message-ID: <2C99lSe6yHLjem9EG1sWTlONqwF4D_gDf_z97bRpWpQ=.099aec12-4ece-4d8f-af0d-19ca2e96812c@github.com>

On Mon, 17 Jan 2022 13:20:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Second try in refining the range calculation in `ObjectStartArray::object_starts_in_range`.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: 496baada
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/496baada1021eecae03e737afe838ad6d383cba9
Stats:     13 lines in 2 files changed: 9 ins; 0 del; 4 mod

8280030: [REDO] Parallel: More precise boundary in ObjectStartArray::object_starts_in_range

Reviewed-by: sjohanss, tschatzl

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

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


From ayang at openjdk.java.net  Tue Jan 25 15:40:04 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 25 Jan 2022 15:40:04 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
Message-ID: <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>

> Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:

 - review
 - review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7028/files
  - new: https://git.openjdk.java.net/jdk/pull/7028/files/37979a3b..aee7f1b7

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

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

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


From ayang at openjdk.java.net  Tue Jan 25 15:43:36 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 25 Jan 2022 15:43:36 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>
Message-ID: <RKxobHIomBBGdHJafhv2yg3J_oNZIelr7SVz-LxILlM=.69cc767f-02ec-4c27-bdac-954fe3ef045d@github.com>

On Mon, 17 Jan 2022 09:37:37 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review
>>  - review
>
> src/hotspot/share/gc/shared/preservedMarks.hpp line 60:
> 
>> 58:   size_t size() const { return _stack.size(); }
>> 59:   inline void push_if_necessary(oop obj, markWord m);
>> 60:   inline void push_always(oop obj, markWord m);
> 
> Any reason not to just call this `push()` like we had in the past and maybe also re-use it in `push_if_necessary()`?

I was thinking `push_always` makes a clearer contrast with its neighbor: the two are parallel and there's no interconnection/dependency btw them.

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

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


From shade at openjdk.java.net  Tue Jan 25 16:00:29 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 25 Jan 2022 16:00:29 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <juDGOxh3csV6bgwp7kI1k7TYMIRY9tRh2Iy4PtPOvcg=.95d7c722-cce4-4f83-a6e5-cc4d05bc485e@github.com>

On Tue, 25 Jan 2022 10:10:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

Huh, this might actually work, let me take a closer look.

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

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


From ayang at openjdk.java.net  Tue Jan 25 16:20:34 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 25 Jan 2022 16:20:34 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v4]
In-Reply-To: <iV8wMn_Vbo3TVkIf3L9hXnQzvzlaOqhAq9xb2bHDX1g=.b8c224bd-a37d-4aa5-8386-cf5ad11fca4f@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <iV8wMn_Vbo3TVkIf3L9hXnQzvzlaOqhAq9xb2bHDX1g=.b8c224bd-a37d-4aa5-8386-cf5ad11fca4f@github.com>
Message-ID: <SQSU6pMrxqa-yttFQxat81MIQYRCsyAsCJ7d0W2zsCk=.10b5cbf2-b4e7-4132-b2f9-17b2dfcbbee9@github.com>

On Mon, 24 Jan 2022 16:53:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
>> 
>> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
>> 
>> This is the change for g1.
>> 
>> The CR shows some numbers how bad this can be.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments, cleanup

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 16:31:33 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 16:31:33 GMT
Subject: RFR: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads [v4]
In-Reply-To: <SBSg-IXbLU6VfNg6f4JtnqQDUVmRIRFHczf1MsarcW4=.7efb3276-37b7-42df-ad80-3a25240da270@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
 <iV8wMn_Vbo3TVkIf3L9hXnQzvzlaOqhAq9xb2bHDX1g=.b8c224bd-a37d-4aa5-8386-cf5ad11fca4f@github.com>
 <SBSg-IXbLU6VfNg6f4JtnqQDUVmRIRFHczf1MsarcW4=.7efb3276-37b7-42df-ad80-3a25240da270@github.com>
Message-ID: <ScpVjThnmCO1B1TjTCC_5R-8yLhyywUxzQUTwN_u3AQ=.f921e397-2859-42b1-9ed2-7228f3adced6@github.com>

On Mon, 24 Jan 2022 19:50:32 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments, cleanup
>
> Marked as reviewed by sjohanss (Reviewer).

Thanks @kstefanj @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 16:31:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 16:31:34 GMT
Subject: Integrated: 8280396: G1: Full gc mark stack draining should prefer to
 make work available to other threads
In-Reply-To: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
References: <tZwIcuwBktU99iDdf3QI5uhtxipJNNEIVlbwZM_RbzQ=.40a6e5d7-f713-4ca5-9862-0682fabbcd6f@github.com>
Message-ID: <t2frLkwrW8ibjEV9Nd4UcPmxCCN3Ru34r3K8urGyEB0=.91cc7435-efbe-40ba-9b5f-2f2765d60709@github.com>

On Fri, 21 Jan 2022 14:33:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that fixes a significant performance problem with g1 full gc marking when the overflow queue is in use? Basically this case causes the threads never share their work from the overflow queue, resulting in very bad parallelization in some cases.
> 
> This is a problem that has been fixed already in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438), but when looking at this code on g1 and parallel full gc, they both showed that issue.
> 
> This is the change for g1.
> 
> The CR shows some numbers how bad this can be.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 674a97b2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/674a97b27ef621e7b54c13c121c625f91df5ee60
Stats:     50 lines in 2 files changed: 32 ins; 10 del; 8 mod

8280396: G1: Full gc mark stack draining should prefer to make work available to other threads

Reviewed-by: sjohanss, ayang

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 16:53:36 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 16:53:36 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <4cYVRPilXAiBTSWrZkseFHULO3E41w-3qxa5iNs_WV0=.e9539f5e-a829-4f79-b491-3ff9fc761311@github.com>

On Wed, 12 Jan 2022 09:03:45 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

Just a recap of what the change adds:

* on evacuation failure, also records the number of bytes that failed evacuation in that region in a per-region live-map (using `G1RegionMarkStats`)
* (at the start of the Post Evacuation Cleanup 1 we flush that cache - ideally this would be done in `Merge PSS`, but we can't because we need it in the remove self forwards pointer task potentially running in parallel)
* remove self forwards in Post Evacuation Cleanup 1 does roughly the following:
1) let the threads claim and "prepare" the region - mostly setting live bytes from that new per-region live map, "readying the region" (BOT reset, some statistics), finally set to "ready"
2) wait for the region being "ready"
3) let the threads claim parts ("chunks") of the region; these chunks are first generated using information from the region (and the bitmap). They contain information to handle the zapping and restoring, which is then immediately used by that thread.

Fwiw, I did some hacking, adding lots of statistics output to it because I was a bit surprised of some of the numbers I saw (available at https://github.com/tschatzl/jdk/tree/pull/7047-evac-failure-chunking).

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

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


From shade at openjdk.java.net  Tue Jan 25 17:03:34 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 25 Jan 2022 17:03:34 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <TQGysh5-mmGcABC04D8J9EUxQ9gXBv20lRc584vfkTc=.2586e021-127e-470b-a7eb-86004efedb4f@github.com>

On Tue, 25 Jan 2022 10:10:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

I am still not quite convinced about the performance gains here -- my point tests show there is slight regression in "Choose Collection Set" (use `-Xlog:gc+stats` to get it, and look at the table before JVM shutdown). Have you have any promising performance data?

Meanwhile, if we do this, I suggest two things:

1) Update the large "logic" comment like this:


  // Therefore, we start by sorting the regions by garbage. Then we unconditionally add the best candidates
  // before we meet min_garbage. Then we add all candidates that fit with a garbage threshold.
  // If max_cset is hit during that phase, we terminate the cset selection. Note that in this scheme,
  // ShenandoahGarbageThreshold is the soft threshold which would be ignored until min_garbage is hit.

2) Assert sorting invariants like this:


    } else if (cur_garbage >= min_garbage) {
      // Min garbage condition satisfied, and the regions left would never meet
      // the garbage threshold, because we sorted by garbage. Can break here.
#ifdef ASSERT
      for (size_t c_idx = idx; c_idx < size; c_idx++) {
        assert(data[c_idx]._region->garbage() <= garbage_threshold, "Sorting invariant");
      }
#endif
      break;
    }

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

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


From tschatzl at openjdk.java.net  Tue Jan 25 17:22:32 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 25 Jan 2022 17:22:32 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark [v4]
In-Reply-To: <MXqmHzF8Tygjb5RBoe4v98EGlLR__BbkhHBRwir9pRg=.a3898f1a-4e26-4225-a7cc-f191a3d653ff@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
 <MXqmHzF8Tygjb5RBoe4v98EGlLR__BbkhHBRwir9pRg=.a3898f1a-4e26-4225-a7cc-f191a3d653ff@github.com>
Message-ID: <tqQDotpHS96WxxNi0Loik8c12IrS8tjA0Q94CIi1HBc=.1fb28216-50a5-4792-883e-6fda3d2f4e4e@github.com>

On Tue, 25 Jan 2022 12:13:07 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only prev bitmap assert

Still good.

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

Marked as reviewed by tschatzl (Reviewer).

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


From kbarrett at openjdk.java.net  Wed Jan 26 03:10:30 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 26 Jan 2022 03:10:30 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v2]
In-Reply-To: <LBfEw1rqiUChPM74qmP5xyIqutuV1UPhjEL5EFEjqb4=.28a567a0-cff7-450e-828a-dddb4ca642bd@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <LBfEw1rqiUChPM74qmP5xyIqutuV1UPhjEL5EFEjqb4=.28a567a0-cff7-450e-828a-dddb4ca642bd@github.com>
Message-ID: <GtArC27A8ctHshphavjDqNxsUXFOxhHtPUXkmM9-dPY=.af885c5e-2e30-45da-a4db-d1f66f69af8c@github.com>

On Mon, 24 Jan 2022 09:38:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
>> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
>> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
>> 
>> Testing: gha (building), local testing
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pliden review

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 40:

> 38: #include "gc/g1/heapRegionRemSet.hpp"
> 39: #include "gc/g1/heapRegionSet.inline.hpp"
> 40: #include "gc/shared/collectedHeap.inline.hpp"

Not sure what this is for?  Maybe left-over from initial commit?

src/hotspot/share/gc/shared/collectedHeap.hpp line 30:

> 28: #include "gc/shared/gcCause.hpp"
> 29: #include "gc/shared/gcWhen.hpp"
> 30: #include "gc/shared/taskqueue.hpp"

Not sure what this is for.  Maybe left-over from initial commit?

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

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


From duke at openjdk.java.net  Wed Jan 26 04:33:37 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 26 Jan 2022 04:33:37 GMT
Subject: Withdrawn: 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: <oZS9ZcBfxN9GSJcriwx2F94EXAF-TMLrXJJ15D6--ZU=.d20697b7-cea9-4f4b-99e8-4078e27818b5@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

This pull request has been closed without being integrated.

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

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


From duke at openjdk.java.net  Wed Jan 26 04:37:00 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Wed, 26 Jan 2022 04:37:00 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v2]
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <rSZGoB2sp8JGvYGshdpK78MyEhjvB66DWgs2yf2bTQM=.ce6a9c02-74e5-41cb-b591-24f40d3baaf1@github.com>

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

Yude Lin 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 'openjdk:master' into JDK-8280579
 - 8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7211/files
  - new: https://git.openjdk.java.net/jdk/pull/7211/files/5b6738c2..cfa75958

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

  Stats: 11257 lines in 643 files changed: 7224 ins; 2232 del; 1801 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7211.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7211/head:pull/7211

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


From duke at openjdk.java.net  Wed Jan 26 04:44:04 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Wed, 26 Jan 2022 04:44:04 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v3]
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <CwlP2mKgPfQPLC3ar29F11RVN2mPEwfdtdBIB9rMfW8=.87dfa753-0cee-41c0-ba6a-4047f2c3bc7e@github.com>

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

Yude Lin 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:

  8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7211/files
  - new: https://git.openjdk.java.net/jdk/pull/7211/files/cfa75958..6aebfea6

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

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

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


From duke at openjdk.java.net  Wed Jan 26 04:44:05 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Wed, 26 Jan 2022 04:44:05 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v3]
In-Reply-To: <TQGysh5-mmGcABC04D8J9EUxQ9gXBv20lRc584vfkTc=.2586e021-127e-470b-a7eb-86004efedb4f@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
 <TQGysh5-mmGcABC04D8J9EUxQ9gXBv20lRc584vfkTc=.2586e021-127e-470b-a7eb-86004efedb4f@github.com>
Message-ID: <EfRZgMSQUNbpjdZkQF9w0HBDZ6ILPQCQeW3EUv6WpAE=.f58f9bf0-f28f-415f-9a12-55e0bee8002f@github.com>

On Tue, 25 Jan 2022 17:00:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I am still not quite convinced about the performance gains here -- my point tests show there is slight regression in "Choose Collection Set" (use `-Xlog:gc+stats` to get it, and look at the table before JVM shutdown). Have you have any promising performance data?
> 

I found this in a small test case where the algorithm would iterate over tens of regions for nothing. With the change the test goes from ~5us to ~1us, measuring the thread cpu time* of the choosing cset loop. I noticed that most of "Choose Collection Set" (which is ~50us) is taken by the sorting work before the loop. So in general the difference wouldn't be noticeable. I simply think it's wasted some time and the change is the more proper way.

Update with the suggested change.

* I put something like this ``clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tp);`` around the loop.

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

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


From ccheung at openjdk.java.net  Wed Jan 26 04:45:42 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 26 Jan 2022 04:45:42 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops
Message-ID: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>

This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.

Passed CI tiers 1 - 4 and hs-tier7-rt tests.

Preliminary HelloWorld startup perf. improvement:

instr delta =    -68813432    -49.7140%
time  delta =      -14.720 ms -20.3599%

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

Commit messages:
 - fix a linux-x86 build issue
 - 8255495: Support CDS Archived Heap for uncompressed oops

Changes: https://git.openjdk.java.net/jdk/pull/7223/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7223&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255495
  Stats: 220 lines in 12 files changed: 163 ins; 6 del; 51 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7223.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7223/head:pull/7223

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


From mli at openjdk.java.net  Wed Jan 26 06:13:34 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 26 Jan 2022 06:13:34 GMT
Subject: RFR: 8280374: G1: Remove unnecessary prev bitmap mark
In-Reply-To: <uCz-qqUFbTdMKbrdWqbgtXQgdqyv9lgqhNKS3pKBdLs=.847267b4-4532-4db7-ae7e-24c6540e6df5@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
 <uCz-qqUFbTdMKbrdWqbgtXQgdqyv9lgqhNKS3pKBdLs=.847267b4-4532-4db7-ae7e-24c6540e6df5@github.com>
Message-ID: <XXaMyivsxQgGTBVrddhGg04yKDWFQYPV3_SXw_tW6cQ=.cd889eae-18f9-424c-b8c7-6732ee185741@github.com>

On Fri, 21 Jan 2022 08:45:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.
>
> Testing seems all good (tier1-5)

Thanks @tschatzl @albertnetymk for your reviews.

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

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


From mli at openjdk.java.net  Wed Jan 26 06:13:35 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 26 Jan 2022 06:13:35 GMT
Subject: Integrated: 8280374: G1: Remove unnecessary prev bitmap mark
In-Reply-To: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
References: <J6sysNS-9SayR0HRDWXrNsJnKO2ug88JMI7vcw-XRGQ=.0fddbc6e-9563-4d4e-a434-5f5baea067f6@github.com>
Message-ID: <acJHksrLOPmWhhDASzvWQ9AVESoJu1wNu_vh15kCgMM=.44f3f8fa-6a5c-4ac6-b249-b547e2c4af8f@github.com>

On Thu, 20 Jan 2022 09:49:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

> In JDK-8278917, the prev bitmap is used to mark evac failure objs, so at the post of evacuation, the evacuation failure objects are already marked during pss evacuation, so there is no need to mark them again in remove self forwardee phase.

This pull request has now been integrated.

Changeset: 2c64a7f2
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c64a7f2e30dc83701456595814a831e41e5f628
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8280374: G1: Remove unnecessary prev bitmap mark

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Wed Jan 26 07:29:40 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 26 Jan 2022 07:29:40 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <29ywcN5rKktrydM1p_Azw8hhK9d6i0Dsz0L9yvgc9lI=.8b1b2ee7-368a-43d0-a82e-998e9d05be4e@github.com>

On Wed, 12 Jan 2022 09:03:45 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

Thanks Thomas for the summary and logging code.
I attached related log output below.


[3.236s][debug][gc,phases] GC(0)     Post Evacuate Cleanup 1: 5.4ms
[3.236s][debug][gc,phases] GC(0)     Evac Fail Merge Live: 0.0ms
...
[3.236s][debug][gc,phases] GC(0)       Restore Retained Regions (ms): Min:  5.1, Avg:  5.1, Max:  5.3, Diff:  0.2, Sum: 41.0, Workers: 8
[3.236s][debug][gc,phases] GC(0)         Regions:                       Min: 1, Avg:  1.0, Max: 1, Diff: 0, Sum: 4, Workers: 4
[3.237s][debug][gc,phases] GC(0)         Prepared Retained Regions (ms): Min:  0.0, Avg:  0.0, Max:  0.0, Diff:  0.0, Sum:  0.0, Workers: 4
[3.237s][debug][gc,phases] GC(0)         Wait For Ready In Retained Regions (ms): Min:  0.0, Avg:  0.0, Max:  0.0, Diff:  0.0, Sum:  0.0, Workers: 8
[3.237s][debug][gc,phases] GC(0)         Prepare Chunks (ms):           Min:  0.0, Avg:  0.0, Max:  0.0, Diff:  0.0, Sum:  0.1, Workers: 8
[3.237s][debug][gc,phases] GC(0)         Remove Self Forwards In Chunks (ms): Min:  5.0, Avg:  5.1, Max:  5.2, Diff:  0.2, Sum: 40.6, Workers: 8
[3.237s][debug][gc,phases] GC(0)           Forward Chunks:                Min: 16, Avg: 16.0, Max: 16, Diff: 0, Sum: 128, Workers: 8
[3.237s][debug][gc,phases] GC(0)           Empty Forward Chunks:          Min: 32, Avg: 128.0, Max: 351, Diff: 319, Sum: 896, Workers: 7
[3.237s][debug][gc,phases] GC(0)           Forward Objects:               Min: 432330, Avg: 440400.4, Max: 449475, Diff: 17145, Sum: 3523203, Workers: 8
[3.237s][debug][gc,phases] GC(0)           Forward Bytes:                 Min: 13543912, Avg: 13680514.0, Max: 13779400, Diff: 235488, Sum: 109444112, Workers: 8

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

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


From tschatzl at openjdk.java.net  Wed Jan 26 09:27:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 Jan 2022 09:27:50 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v3]
In-Reply-To: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
Message-ID: <kTt56SyGamgJbWvA26oWnGEMyOqy7XoDXqDr7zKzx2c=.689dcc5b-b0c4-4276-b1fa-e62781d9687b@github.com>

> Hi all,
> 
>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
> 
> Testing: gha (building), local testing
> 
> 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 four commits:

 - Merge branch 'master' into 8280397-central-taskqueue-printing
 - kbarrett review, copyright dates
 - pliden review
 - Initial implementation using CollectedHeap

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

Changes: https://git.openjdk.java.net/jdk/pull/7174/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7174&range=02
  Stats: 136 lines in 5 files changed: 61 ins; 64 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7174.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7174/head:pull/7174

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


From sjohanss at openjdk.java.net  Wed Jan 26 10:17:41 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 26 Jan 2022 10:17:41 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <RKxobHIomBBGdHJafhv2yg3J_oNZIelr7SVz-LxILlM=.69cc767f-02ec-4c27-bdac-954fe3ef045d@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>
 <RKxobHIomBBGdHJafhv2yg3J_oNZIelr7SVz-LxILlM=.69cc767f-02ec-4c27-bdac-954fe3ef045d@github.com>
Message-ID: <WvFnjaUsrd9FhDwHoQfYJaTMUV397am5dx61DP69zlo=.415a7b68-a212-4e8c-b957-28cebeec4aee@github.com>

On Tue, 25 Jan 2022 15:40:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/preservedMarks.hpp line 60:
>> 
>>> 58:   size_t size() const { return _stack.size(); }
>>> 59:   inline void push_if_necessary(oop obj, markWord m);
>>> 60:   inline void push_always(oop obj, markWord m);
>> 
>> Any reason not to just call this `push()` like we had in the past and maybe also re-use it in `push_if_necessary()`?
>
> I was thinking `push_always` makes a clearer contrast with its neighbor: the two are parallel and there's no interconnection/dependency btw them.

Sure, but they do push elements the same way so it could be shared to avoid having to change two places if anything needs updating in the future. That said, the code is small and live close together so should be fine if you prefer it this way.

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

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


From tschatzl at openjdk.java.net  Wed Jan 26 12:26:33 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 Jan 2022 12:26:33 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <MkKC_uMmSFGS3pmLPRy8uFfvcFzoKuAf5_OCKsoZTL8=.f367f555-6945-4dd0-af8f-8a8b0d482567@github.com>

On Wed, 12 Jan 2022 09:03:45 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

Regarding the log messages: We might want to fix up them a bit, I did not look at our recent email discussion on what we came up with, and their level.

Some other initial thoughts worth considering:

*) What I already noticed yesterday on some tests, and can also be seen in your log snippet, is that the "Remove self-forwards in chunks" takes a lot of time, unexpectedly much to me actually. I want to look further into this to understand the reason(s).

*) The other concern I have is whether we really need (or can avoid) the need for the "Wait for Ready In Retained Regions" phase. It looks a bit unfortunate to actually have a busy-loop in there; this should definitely use proper synchronization or something to wait on if it is really needed. What of the retained region preparation do we really need? On a first look, maybe just the BOT reset, which we might be able to put somewhere else (I may be totally wrong). Also, if so, the Prepare Retained regions should probably be split out to be started before all other tasks in this "Post Evacuate Cleanup 1" phase.

I can see that from a timing perspective "Wait For Ready" is not a problem in all of my tests so far.

*) The "Prepared Retained Regions" phase stores the amount of live data into the `HeapRegion`; for this reason the change adds these `G1RegionMarkStats` data gathering via the `G1RegionMarkStatsCache`; I think the same information could be provided while iterating over the chunks (just do an `Atomic::add` here) instead. A single `Atomic::add` per thread per retained region at most seems to be okay. That would also remove the `Evac Fail Merge Live` phase afaict.

*) Not too happy that the `G1HeapRegionChunk` constructor does surprisingly much work, which surprisingly takes very little time.

*) I was wondering whether it would be somewhat more efficient for the `Prepare Chunks` phase to collect some of the information needed there somehow else. Something is bubbling up in my mind, but nothing specific yet, and as mentioned, it might not be worth doing given its (lack of) cost.

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

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


From ayang at openjdk.java.net  Wed Jan 26 15:08:34 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 26 Jan 2022 15:08:34 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <WvFnjaUsrd9FhDwHoQfYJaTMUV397am5dx61DP69zlo=.415a7b68-a212-4e8c-b957-28cebeec4aee@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <YjRwjmOWFx8LqOLLUZhFLoSb66Ukea3lnUzXpV7uihc=.5914e45c-d131-45ed-9fa5-aaebff5be8b4@github.com>
 <RKxobHIomBBGdHJafhv2yg3J_oNZIelr7SVz-LxILlM=.69cc767f-02ec-4c27-bdac-954fe3ef045d@github.com>
 <WvFnjaUsrd9FhDwHoQfYJaTMUV397am5dx61DP69zlo=.415a7b68-a212-4e8c-b957-28cebeec4aee@github.com>
Message-ID: <Hrkn_nLRpCZ0Sw2b7slMnq1WDroFMyDwjgPJ8slaeOw=.3ef6a6a3-18b1-4bb4-a309-bce7ffcd5e16@github.com>

On Wed, 26 Jan 2022 10:14:52 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> I was thinking `push_always` makes a clearer contrast with its neighbor: the two are parallel and there's no interconnection/dependency btw them.
>
> Sure, but they do push elements the same way so it could be shared to avoid having to change two places if anything needs updating in the future. That said, the code is small and live close together so should be fine if you prefer it this way.

I think it's better not to mix the two APIs. The duplication is very small after all.

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

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


From mseledtsov at openjdk.java.net  Wed Jan 26 16:13:35 2022
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 26 Jan 2022 16:13:35 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops
In-Reply-To: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
Message-ID: <qPdg0rXcxeDlvxnzepbbp-xwgY5bUL5umjl1Jn8137Y=.532e6937-4e07-475a-8611-6d555c55973a@github.com>

On Wed, 26 Jan 2022 02:48:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
> 
> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
> 
> Preliminary HelloWorld startup perf. improvement:
> 
> instr delta =    -68813432    -49.7140%
> time  delta =      -14.720 ms -20.3599%

Test and test group changes look good to me.

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

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


From tschatzl at openjdk.java.net  Wed Jan 26 17:33:56 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 26 Jan 2022 17:33:56 GMT
Subject: RFR: 8280719: G1: Remove outdated comment in
 RemoveSelfForwardPtrObjClosure::apply
Message-ID: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>

Hi all,

  can I have reviews for this trivial change that removes an obsolete comment after JDK-8280374? Zapping does not clear the bitmap any more.

Thanks,
  Thomas

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

Commit messages:
 - Remove comment

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

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


From ayang at openjdk.java.net  Wed Jan 26 17:40:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 26 Jan 2022 17:40:32 GMT
Subject: RFR: 8280719: G1: Remove outdated comment in
 RemoveSelfForwardPtrObjClosure::apply
In-Reply-To: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
References: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
Message-ID: <osolLV_67N5RaaAjg4-BbukBtSlIRD-bmA12xUW8jDQ=.f30acf38-c49e-4bb9-922c-fd3924412233@github.com>

On Wed, 26 Jan 2022 17:25:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial change that removes an obsolete comment after JDK-8280374? Zapping does not clear the bitmap any more.
> 
> Thanks,
>   Thomas

Good and trivial.

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

Marked as reviewed by ayang (Reviewer).

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


From iklam at openjdk.java.net  Wed Jan 26 22:30:40 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 26 Jan 2022 22:30:40 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops
In-Reply-To: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
Message-ID: <VT6PPE1RnmrBdH1Ir1bIP3gHdy0ngWYHDREum0Mblxk=.6e340e07-a1e2-4f39-b884-3bc01ff26870@github.com>

On Wed, 26 Jan 2022 02:48:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
> 
> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
> 
> Preliminary HelloWorld startup perf. improvement:
> 
> instr delta =    -68813432    -49.7140%
> time  delta =      -14.720 ms -20.3599%

The changes look good overall. I have some suggestions for simplifying the code. Also a question on testing.

src/hotspot/share/cds/filemap.cpp line 2151:

> 2149:     HeapShared::set_runtime_delta(delta);
> 2150:   }
> 2151: 

I think the code in the previous few blocks can be simplified by adding two utility functions:


// The address where the bottom of this shared heap region should be mapped
// at runtime
address FileMapInfo::heap_region_runtime_start_address(FileMapRegion* spc) {
  assert(UseSharedSpaces, "runtime only");
  spc->assert_is_heap_region();
  if (UseCompressedOops) {
    return start_address_as_decoded_from_archive(si);
  } else {
     header()->heap_begin() + si->mapping_offset() + HeapShared::set_runtime_delta();
  }
}

void FileMapInfo::set_shared_heap_runtime_delta(ptrdiff_t delta) {
  if (UseCompressedOops) {
    HeapShared::init_narrow_oop_decoding(narrow_oop_base() + delta, narrow_oop_shift());
  } else {
    HeapShared::set_runtime_delta(delta);
  }
}


Then, many of the `if (UseCompressedOops)` checks above can be eliminated.

src/hotspot/share/cds/filemap.cpp line 2211:

> 2209:         assert(is_aligned(si->mapping_offset(), sizeof(HeapWord)), "must be");
> 2210:         start = (HeapWord*)(header()->heap_begin() + si->mapping_offset() + HeapShared::runtime_delta());
> 2211:       }

This block can also be replaced with


HeapWord* start = (HeapWord*)heap_region_runtime_start_address(si);

The `is_aligned(si->mapping_offset()` check can be moved into `heap_region_runtime_start_address()`

src/hotspot/share/cds/heapShared.hpp line 425:

> 423:   static void clear_root(int index);
> 424: 
> 425:   static void set_runtime_delta(ptrdiff_t offset) {

For consistency, `offset` should be renamed to `delta`.

src/hotspot/share/runtime/arguments.cpp line 3454:

> 3452: 
> 3453:   if (DumpSharedSpaces && !UseCompressedOops) {
> 3454:     FLAG_SET_CMDLINE(MaxHeapSize, (size_t)4 * G);

I think we should override MaxHeapSize only if it's greater than 4G. The user should be able to choose a smaller value.

test/hotspot/jtreg/runtime/cds/appcds/javaldr/HumongousDuringDump.java line 31:

> 29:  * @requires vm.cds.write.archived.java.heap
> 30:  * @requires vm.jvmti
> 31:  * @requires vm.opt.final.UseCompressedOops == true

Why is this change needed?

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

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


From mli at openjdk.java.net  Thu Jan 27 02:20:30 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 27 Jan 2022 02:20:30 GMT
Subject: RFR: 8280719: G1: Remove outdated comment in
 RemoveSelfForwardPtrObjClosure::apply
In-Reply-To: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
References: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
Message-ID: <kZgJcvUvV5xNhVKbT8sb-55mv_YaTuc5JpVzM3bMJh4=.e42eed48-d523-474c-b752-f305351f9a63@github.com>

On Wed, 26 Jan 2022 17:25:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial change that removes an obsolete comment after JDK-8280374? Zapping does not clear the bitmap any more.
> 
> Thanks,
>   Thomas

Marked as reviewed by mli (Reviewer).

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

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


From ayang at openjdk.java.net  Thu Jan 27 08:57:46 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 27 Jan 2022 08:57:46 GMT
Subject: RFR: 8280783: Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
Message-ID: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>

A new version of `PSCardTable::scavenge_contents_parallel` with cleaner structure and most of the existing behavior. The deviation is so large that the diff is not very sensible; reading the new code directly is probably easier.

This PR doesn't take advantage of precise card marking, just like the existing code. IOW, the code assumes all cards are *imprecisely* marked. Optimizations like utilizing precise card marking will be investigated/attempted in another ticket/PR.

Test: Tier1-6

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

Commit messages:
 - scavenge_contents_parallel

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

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


From tschatzl at openjdk.java.net  Thu Jan 27 09:09:38 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 09:09:38 GMT
Subject: RFR: 8280719: G1: Remove outdated comment in
 RemoveSelfForwardPtrObjClosure::apply
In-Reply-To: <osolLV_67N5RaaAjg4-BbukBtSlIRD-bmA12xUW8jDQ=.f30acf38-c49e-4bb9-922c-fd3924412233@github.com>
References: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
 <osolLV_67N5RaaAjg4-BbukBtSlIRD-bmA12xUW8jDQ=.f30acf38-c49e-4bb9-922c-fd3924412233@github.com>
Message-ID: <ugkZVJwSzdmV3Q4e9WPSpu1x_LgiZ42sT9qjhSaIOGA=.e1ac5333-08c0-489a-97fc-8313450ba322@github.com>

On Wed, 26 Jan 2022 17:37:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this trivial change that removes an obsolete comment after JDK-8280374? Zapping does not clear the bitmap any more.
>> 
>> Thanks,
>>   Thomas
>
> Good and trivial.

Thanks @albertnetymk @Hamlin-Li for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Jan 27 09:09:39 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 09:09:39 GMT
Subject: Integrated: 8280719: G1: Remove outdated comment in
 RemoveSelfForwardPtrObjClosure::apply
In-Reply-To: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
References: <LTWtW5-HOCZ4Q-lJHDSKS1bazBTGIUb4n-93PhmMzkk=.171d0d20-d74e-4a6a-ab1e-a86d64563730@github.com>
Message-ID: <lTPW5dD6I0CAiMOb8KKNJWgKP8LHHqxe_uz3kMvAMDM=.95dfcc82-984f-4fbc-927a-f94c3f62cd60@github.com>

On Wed, 26 Jan 2022 17:25:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial change that removes an obsolete comment after JDK-8280374? Zapping does not clear the bitmap any more.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8280719: G1: Remove outdated comment in RemoveSelfForwardPtrObjClosure::apply

Reviewed-by: ayang, mli

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

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


From mli at openjdk.java.net  Thu Jan 27 09:26:34 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 27 Jan 2022 09:26:34 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <MkKC_uMmSFGS3pmLPRy8uFfvcFzoKuAf5_OCKsoZTL8=.f367f555-6945-4dd0-af8f-8a8b0d482567@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <MkKC_uMmSFGS3pmLPRy8uFfvcFzoKuAf5_OCKsoZTL8=.f367f555-6945-4dd0-af8f-8a8b0d482567@github.com>
Message-ID: <GxkulZGOPm60wg8jBtsfptd-rylbb22C38uanX--aeo=.6fa546bc-e2e0-4d28-a86e-3e93f06a16ce@github.com>

On Wed, 26 Jan 2022 12:23:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Regarding the log messages: We might want to fix up them a bit, I did not look at our recent email discussion on what we came up with, and their level.
> 
> Some other initial thoughts worth considering:
> 
> *) What I already noticed yesterday on some tests, and can also be seen in your log snippet, is that the "Remove self-forwards in chunks" takes a lot of time, unexpectedly much to me actually. I want to look further into this to understand the reason(s).
> 

In fact, normally most of time of "Post Evacuate Cleanup 1" is spent on "Restore Retained Regions" in baseline version. In parallel version, the proportion of "Restore Retained Regions" in "Post Evacuate Cleanup 1" is reduced.  e.g. following is the "Post Evacuate Cleanup 1"/"Restore Retained Regions" time comparison between baseline and parallel:
baseline:

[3.169s][info ][gc,phases] GC(0)   Post Evacuate Collection Set: 10.0ms
[3.169s][debug][gc,phases] GC(0)     Post Evacuate Cleanup 1: 9.5ms

parallel

[3.105s][info ][gc,phases] GC(0)   Post Evacuate Collection Set: 2.5ms
[3.106s][debug][gc,phases] GC(0)     Post Evacuate Cleanup 1: 2.0ms

the difference between "Post Evacuate Cleanup 1" and "Restore Retained Regions" is the same between baseline and parallel version, which is spent on other subphases in "Post Evacuate Cleanup 1".


> *) The other concern I have is whether we really need (or can avoid) the need for the "Wait for Ready In Retained Regions" phase. It looks a bit unfortunate to actually have a busy-loop in there; this should definitely use proper synchronization or something to wait on if it is really needed. What of the retained region preparation do we really need? On a first look, maybe just the BOT reset, which we might be able to put somewhere else (I may be totally wrong). Also, if so, the Prepare Retained regions should probably be split out to be started before all other tasks in this "Post Evacuate Cleanup 1" phase.
> 
> I can see that from a timing perspective "Wait For Ready" is not a problem in all of my tests so far.

Yes, currently seems "Wait For Ready" does not cost much time, as "Prepared Retained Regions" is quick, not sure if synchronization will help any more.
But I will investigate if we can omit "Prepared Retained Regions" and "Wait For Ready" subphases totally to simplify the logic. [TODO]

> 
> *) The "Prepared Retained Regions" phase stores the amount of live data into the `HeapRegion`; for this reason the change adds these `G1RegionMarkStats` data gathering via the `G1RegionMarkStatsCache`; I think the same information could be provided while iterating over the chunks (just do an `Atomic::add` here) instead. A single `Atomic::add` per thread per retained region at most seems to be okay. That would also remove the `Evac Fail Merge Live` phase afaict.

I will do this refactor soon.

> 
> *) Not too happy that the `G1HeapRegionChunk` constructor does surprisingly much work, which surprisingly takes very little time.
> 
> *) I was wondering whether it would be somewhat more efficient for the `Prepare Chunks` phase to collect some of the information needed there somehow else. Something is bubbling up in my mind, but nothing specific yet, and as mentioned, it might not be worth doing given its (lack of) cost.

I will put it on backlog to see if it can be simplied. [TODO]

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

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


From tschatzl at openjdk.java.net  Thu Jan 27 10:21:34 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 10:21:34 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <GxkulZGOPm60wg8jBtsfptd-rylbb22C38uanX--aeo=.6fa546bc-e2e0-4d28-a86e-3e93f06a16ce@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <MkKC_uMmSFGS3pmLPRy8uFfvcFzoKuAf5_OCKsoZTL8=.f367f555-6945-4dd0-af8f-8a8b0d482567@github.com>
 <GxkulZGOPm60wg8jBtsfptd-rylbb22C38uanX--aeo=.6fa546bc-e2e0-4d28-a86e-3e93f06a16ce@github.com>
Message-ID: <BHLuzndX3lTML0u7US6xbXSB3ck2itC99AoBtKZ0DYg=.5434aaba-d4da-4211-b8f7-87e9c70208c3@github.com>

On Thu, 27 Jan 2022 09:23:27 GMT, Hamlin Li <mli at openjdk.org> wrote:

> >Some other initial thoughts worth considering:
> >
> > *) What I already noticed yesterday on some tests, and can also be seen in your log snippet, is that the "Remove self-forwards in chunks" takes a lot of time, unexpectedly much to me actually. I want to look further into this to understand the reason(s).
> 
> In fact, normally most of time of "Post Evacuate Cleanup 1" is spent on "Restore Retained Regions" in baseline version. In parallel version, the proportion of "Restore Retained Regions" in "Post Evacuate Cleanup 1" is reduced. [...]

I agree. This has only been a general remark about its performance, not meant to belittle the usefulness this change and in general all the changes in this series have, which are quite substantial. ?  I compared the throughput (bytes/ms) between `Object Copy` and this phase, and at least without JDK-8280374 the `remove self forwards` is only like 2x the throughput of `Object Copy`, which seemed quite bad compared to what they do. With JDK-8280374 the results are much better (~4.5x) afaict on a single benchmark I tried though. It's a bit hard to reproduce the exact situation/heap though...

Another (future) optimization that may be worthwhile here may be to get some occupancy statistics of the chunks and switch between walking the bitmap and walking the objects; another one that might be "simpler" to implement (but fairly messy probably) is to simply check if the object after the current one is also forwarded, and if so, do not switch back to the bitmap walking but immediately process that one as well.
This might help somewhat because given typical avg. object sizes (~40 bytes), the mark word after the current one might be already in the cache anyway, so a read access practically free.

These are only ideas though.

> > *) The other concern I have is whether we really need (or can avoid) the need for the "Wait for Ready In Retained Regions" phase. It looks a bit unfortunate to actually have a busy-loop in there; this should definitely use proper synchronization or something to wait on if it is really needed. What of the retained region preparation do we really need? On a first look, maybe just the BOT reset, which we might be able to put somewhere else (I may be totally wrong). Also, if so, the Prepare Retained regions should probably be split out to be started before all other tasks in this "Post Evacuate Cleanup 1" phase.
> 
>> I can see that from a timing perspective "Wait For Ready" is not a problem in all of my tests so far.
> 
> Yes, currently seems "Wait For Ready" does not cost much time, as "Prepared Retained Regions" is quick, not sure if synchronization will help any more.
> But I will investigate if we can omit "Prepared Retained Regions" and "Wait For Ready" subphases totally to simplify the logic. [TODO]

The point of "proper synchronization" isn't that it's faster, but it does not burn cpu cycles unnecessarily which potentially keeps the one thread that others are waiting on do the work. If we can remove the dependencies between the "Prepare Retained Regions" and the remaining phases, which only seems to be the BOT. One idea is that maybe all that prepare stuff could be placed where G1 adds that region to the list of retained regions. This does not work for the liveness count obviously - but that can be recreated by the actual self forwarding removal as suggested earlier ?).

Then none of that is required which is even better.

> 
> >*) The "Prepared Retained Regions" phase stores the amount of live data into the HeapRegion; for this reason the change adds these G1RegionMarkStats data gathering via the G1RegionMarkStatsCache; I think the same information could be provided while iterating over the chunks (just do an Atomic::add here) instead. A single Atomic::add per thread per retained region at most seems to be okay. That would also remove the Evac Fail Merge Live phase afaict.
> 
> I will do this refactor soon.

Thanks!

> 
> >*) Not too happy that the G1HeapRegionChunk constructor does surprisingly much work, which surprisingly takes very little time.
> >
>  >*) I was wondering whether it would be somewhat more efficient for the Prepare Chunks phase to collect some of the information needed there somehow else. Something is bubbling up in my mind, but nothing specific yet, and as mentioned, it might not be worth doing given its (lack of) cost.
> 
> I will put it on backlog to see if it can be simplified. [TODO]
> 

Not necessarily simplified: one option is to make that work explicit (we tend to try to not do too much work in constructors - but maybe this just fits here), another is to pre-calculate some of these values during evacuation failure somehow.

We can maybe also postpone the optimization part of that suggestion given that currently that phase takes almost no time if it seems to be too much work.

Thanks for your hard work,
  Thomas

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

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


From tschatzl at openjdk.java.net  Thu Jan 27 10:28:33 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 10:28:33 GMT
Subject: RFR: 8280783: Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
References: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
Message-ID: <mxWDe2-CagOKjjeaKJmlYt_SJMD6-Fs4pVO5msJF5ek=.02cba729-e0ee-4215-9806-da5e1a3059b7@github.com>

On Thu, 27 Jan 2022 08:49:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> A new version of `PSCardTable::scavenge_contents_parallel` with cleaner structure and most of the existing behavior. The deviation is so large that the diff is not very sensible; reading the new code directly is probably easier.
> 
> This PR doesn't take advantage of precise card marking, just like the existing code. IOW, the code assumes all cards are *imprecisely* marked. Optimizations like utilizing precise card marking will be investigated/attempted in another ticket/PR.
> 
> Test: Tier1-6

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From mli at openjdk.java.net  Thu Jan 27 12:49:06 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 27 Jan 2022 12:49:06 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v2]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <pmSO1Pal5ff15uofp3PZFQ1fjWJv_BILO_3c1LaBHi8=.4482440a-265e-42e5-b1ad-9d0a89b61d32@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

 - Add logging code from Thomas
 - Collect livewords in chunk closure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/320549c0..a78499a5

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

  Stats: 137 lines in 13 files changed: 68 ins; 42 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From tschatzl at openjdk.java.net  Thu Jan 27 12:55:59 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 12:55:59 GMT
Subject: RFR: 8280705: Parallel: Full gc mark stack draining should prefer to
 make work available to other threads
Message-ID: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>

Hi all,

  can I get reviews for this change that improves task queue handling during queue overflow similar to JDK-8280396 for Parallel GC? Basically the change modifies the queue selection heuristics to be the same as for G1.

Testing: tier1-5, internal promotion perf testing, perf testing of some local benchmarks (BRT, optaplanner) looking for regressions

Thanks,
  Thomas

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

Commit messages:
 - Parallel gc task queue

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

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


From ayang at openjdk.java.net  Thu Jan 27 13:37:33 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 27 Jan 2022 13:37:33 GMT
Subject: RFR: 8280705: Parallel: Full gc mark stack draining should prefer
 to make work available to other threads
In-Reply-To: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
References: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
Message-ID: <6J8ekT8JdKzdZ110jgXtB-pJwsN7hwf0rxrWzbtNg6A=.f94d0a10-a070-4d00-b0da-df42e940d342@github.com>

On Thu, 27 Jan 2022 12:49:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that improves task queue handling during queue overflow similar to JDK-8280396 for Parallel GC? Basically the change modifies the queue selection heuristics to be the same as for G1.
> 
> Testing: tier1-5, internal promotion perf testing, perf testing of some local benchmarks (BRT, optaplanner) looking for regressions
> 
> Thanks,
>   Thomas

`transfer_from_overflow_stack` tries to publish any many items as possible to the global queue (eligible for work stealing), and returns whether we have successfully popped an item from the local overflow queue. How about `publish_or_pop_overflow`?

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

Marked as reviewed by ayang (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Jan 27 14:36:33 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 14:36:33 GMT
Subject: RFR: 8280705: Parallel: Full gc mark stack draining should prefer
 to make work available to other threads
In-Reply-To: <6J8ekT8JdKzdZ110jgXtB-pJwsN7hwf0rxrWzbtNg6A=.f94d0a10-a070-4d00-b0da-df42e940d342@github.com>
References: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
 <6J8ekT8JdKzdZ110jgXtB-pJwsN7hwf0rxrWzbtNg6A=.f94d0a10-a070-4d00-b0da-df42e940d342@github.com>
Message-ID: <EU1gAJqxHQcpfVlK8qDnA8MWUdt613OCW8Pe6yjbuO4=.8f49d69a-da69-480b-8178-c3dcbe2079b6@github.com>

On Thu, 27 Jan 2022 13:34:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> `transfer_from_overflow_stack` tries to publish any many items as possible to the global queue (eligible for work stealing), and returns whether we have successfully popped an item from the local overflow queue. How about `publish_or_pop_overflow`?

I will do the name change separately with the same renaming for G1. It would be nice to keep these in sync.

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

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


From ayang at openjdk.java.net  Thu Jan 27 14:42:55 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 27 Jan 2022 14:42:55 GMT
Subject: RFR: 8280804: Parallel: Remove unused variables in
 PSPromotionManager::drain_stacks_depth
Message-ID: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>

Trivial change of removing dead code.

Test: build

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

Commit messages:
 - trivial

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

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


From tschatzl at openjdk.java.net  Thu Jan 27 15:35:35 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 27 Jan 2022 15:35:35 GMT
Subject: RFR: 8280804: Parallel: Remove unused variables in
 PSPromotionManager::drain_stacks_depth
In-Reply-To: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
References: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
Message-ID: <pKst1Wfdb0lpgjBQ0Mw8HqkNDiMogt5ULv6iXbVocjg=.6b68ef70-3b14-4e43-9fa8-d7c5ed8ecd55@github.com>

On Thu, 27 Jan 2022 14:34:40 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/7245


From kbarrett at openjdk.java.net  Thu Jan 27 20:37:59 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 27 Jan 2022 20:37:59 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v3]
In-Reply-To: <kTt56SyGamgJbWvA26oWnGEMyOqy7XoDXqDr7zKzx2c=.689dcc5b-b0c4-4276-b1fa-e62781d9687b@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <kTt56SyGamgJbWvA26oWnGEMyOqy7XoDXqDr7zKzx2c=.689dcc5b-b0c4-4276-b1fa-e62781d9687b@github.com>
Message-ID: <1o6KoGDryNP6j_NsiWhK6UhHgGT2ZWud84E9iQMfsjI=.172a69f3-b403-465f-9bc4-5825757d116e@github.com>

On Wed, 26 Jan 2022 09:27:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
>> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
>> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
>> 
>> Testing: gha (building), local testing
>> 
>> 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 four commits:
> 
>  - Merge branch 'master' into 8280397-central-taskqueue-printing
>  - kbarrett review, copyright dates
>  - pliden review
>  - Initial implementation using CollectedHeap

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Fri Jan 28 01:08:11 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 28 Jan 2022 01:08:11 GMT
Subject: RFR: 8280804: Parallel: Remove unused variables in
 PSPromotionManager::drain_stacks_depth
In-Reply-To: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
References: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
Message-ID: <RzA-uOsYMgmanRu_cHMVY7dmjO7k1TIZlm8QbJKePyg=.bc13b1f4-31b6-4ddf-8111-742f09876413@github.com>

On Thu, 27 Jan 2022 14:34:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Marked as reviewed by mli (Reviewer).

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

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


From mli at openjdk.java.net  Fri Jan 28 01:23:10 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 28 Jan 2022 01:23:10 GMT
Subject: RFR: 8280705: Parallel: Full gc mark stack draining should prefer
 to make work available to other threads
In-Reply-To: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
References: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
Message-ID: <WfGcDZxPruT0Lc5qdwEqH-bkRg1WwKCItSUAVLSHBxI=.de3a09b6-d99c-493d-a09f-f314c49aca70@github.com>

On Thu, 27 Jan 2022 12:49:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that improves task queue handling during queue overflow similar to JDK-8280396 for Parallel GC? Basically the change modifies the queue selection heuristics to be the same as for G1.
> 
> Testing: tier1-5, internal promotion perf testing, perf testing of some local benchmarks (BRT, optaplanner) looking for regressions
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by mli (Reviewer).

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


From mli at openjdk.java.net  Fri Jan 28 01:33:17 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 28 Jan 2022 01:33:17 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v3]
In-Reply-To: <kTt56SyGamgJbWvA26oWnGEMyOqy7XoDXqDr7zKzx2c=.689dcc5b-b0c4-4276-b1fa-e62781d9687b@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <kTt56SyGamgJbWvA26oWnGEMyOqy7XoDXqDr7zKzx2c=.689dcc5b-b0c4-4276-b1fa-e62781d9687b@github.com>
Message-ID: <9dSmgvIejPq_9mGsFzyykBoyw2yENqWp_WNYC6OMugE=.11a94c63-7763-45d0-9023-ac8973f460d4@github.com>

On Wed, 26 Jan 2022 09:27:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
>> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
>> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
>> 
>> Testing: gha (building), local testing
>> 
>> 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 four commits:
> 
>  - Merge branch 'master' into 8280397-central-taskqueue-printing
>  - kbarrett review, copyright dates
>  - pliden review
>  - Initial implementation using CollectedHeap

Marked as reviewed by mli (Reviewer).

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

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


From duke at openjdk.java.net  Fri Jan 28 03:25:08 2022
From: duke at openjdk.java.net (Yude Lin)
Date: Fri, 28 Jan 2022 03:25:08 GMT
Subject: RFR: 8280579: Shenandoah: Skip regions in the back of sorted array
 when choosing cset [v3]
In-Reply-To: <CwlP2mKgPfQPLC3ar29F11RVN2mPEwfdtdBIB9rMfW8=.87dfa753-0cee-41c0-ba6a-4047f2c3bc7e@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
 <CwlP2mKgPfQPLC3ar29F11RVN2mPEwfdtdBIB9rMfW8=.87dfa753-0cee-41c0-ba6a-4047f2c3bc7e@github.com>
Message-ID: <T4YLKC0cKY2cW8ozI2ZqLcIgEnh-P-JATj1KgOcJ0H4=.94c642de-8915-4311-9350-e4a14c89cc4e@github.com>

On Wed, 26 Jan 2022 04:44:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

>> Can I have review on this small change that skips some unnecessary work in cset choosing?
>> 
>> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.
>
> Yude Lin 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:
> 
>   8280579: Shenandoah: Skip regions in the back of sorted array when choosing cset

The original code also use new_garbage instead of cur_garbage in the line

if ((new_garbage < min_garbage) || (r->garbage() > garbage_threshold)) {

It puzzles me. There is a slight chance that GC prefers to recycle region with less garbage than more garbage
due to this. I'm not sure that's what we want. As an example:

Suppose we have regions sorted by garbage:

region_garbage=[800k, 700k, 600k, 100k]

And suppose min_garbage=2000k, garbage_threshold=600k

The algorithm will add the 800k region and the 700k region to the cset, then it skips the 600k region,
because now new_garbage=800+700+600>2000 and it will not pass the if check above. However, it will
continue the iteration and add the 100k region to the cset. Why do we do that? As long as the max_cset
condition is satisfied, the more garbage the merrier right? Should we change ``new_garbage`` to ``cur_garbage``?

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

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


From ccheung at openjdk.java.net  Fri Jan 28 05:35:55 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 28 Jan 2022 05:35:55 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v2]
In-Reply-To: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
Message-ID: <9Osl20tM5x3OuayRCJyvPxUpLF7A13P5lop2DtoZkd4=.51d6c8ca-5aac-4692-8630-8e0096552cfb@github.com>

> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
> 
> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
> 
> Preliminary HelloWorld startup perf. improvement:
> 
> instr delta =    -68813432    -49.7140%
> time  delta =      -14.720 ms -20.3599%

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7223/files
  - new: https://git.openjdk.java.net/jdk/pull/7223/files/885a949e..5ac98ba1

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

  Stats: 88 lines in 8 files changed: 56 ins; 20 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7223.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7223/head:pull/7223

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


From ccheung at openjdk.java.net  Fri Jan 28 05:46:13 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 28 Jan 2022 05:46:13 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v2]
In-Reply-To: <VT6PPE1RnmrBdH1Ir1bIP3gHdy0ngWYHDREum0Mblxk=.6e340e07-a1e2-4f39-b884-3bc01ff26870@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <VT6PPE1RnmrBdH1Ir1bIP3gHdy0ngWYHDREum0Mblxk=.6e340e07-a1e2-4f39-b884-3bc01ff26870@github.com>
Message-ID: <RH7kPT2E0PV85R-Gj0l6OnR4zJmRcL4z_WCvbgGPAGg=.43eca59f-0a8f-4998-8549-acb43d28b455@github.com>

On Wed, 26 Jan 2022 22:14:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam comments
>
> src/hotspot/share/cds/filemap.cpp line 2151:
> 
>> 2149:     HeapShared::set_runtime_delta(delta);
>> 2150:   }
>> 2151: 
> 
> I think the code in the previous few blocks can be simplified by adding two utility functions:
> 
> 
> // The address where the bottom of this shared heap region should be mapped
> // at runtime
> address FileMapInfo::heap_region_runtime_start_address(FileMapRegion* spc) {
>   assert(UseSharedSpaces, "runtime only");
>   spc->assert_is_heap_region();
>   if (UseCompressedOops) {
>     return start_address_as_decoded_from_archive(si);
>   } else {
>      header()->heap_begin() + si->mapping_offset() + HeapShared::set_runtime_delta();
>   }
> }
> 
> void FileMapInfo::set_shared_heap_runtime_delta(ptrdiff_t delta) {
>   if (UseCompressedOops) {
>     HeapShared::init_narrow_oop_decoding(narrow_oop_base() + delta, narrow_oop_shift());
>   } else {
>     HeapShared::set_runtime_delta(delta);
>   }
> }
> 
> 
> Then, many of the `if (UseCompressedOops)` checks above can be eliminated.

For `FileMapInfo::heap_region_runtime_start_address`, I have modified it slightly to the following because
the first time it is called `_runtime_delta` hasn't been set yet.


address FileMapInfo::heap_region_runtime_start_address(FileMapRegion* spc, ptrdiff_t delta) {
  assert(UseSharedSpaces, "runtime only");
  spc->assert_is_heap_region();
  if (UseCompressedOops) {
    return start_address_as_decoded_from_archive(spc);
  } else {
    assert(is_aligned(spc->mapping_offset(), sizeof(HeapWord)), "must be");
    return header()->heap_begin() + spc->mapping_offset() + delta;
  }
}

> src/hotspot/share/cds/filemap.cpp line 2211:
> 
>> 2209:         assert(is_aligned(si->mapping_offset(), sizeof(HeapWord)), "must be");
>> 2210:         start = (HeapWord*)(header()->heap_begin() + si->mapping_offset() + HeapShared::runtime_delta());
>> 2211:       }
> 
> This block can also be replaced with
> 
> 
> HeapWord* start = (HeapWord*)heap_region_runtime_start_address(si);
> 
> The `is_aligned(si->mapping_offset()` check can be moved into `heap_region_runtime_start_address()`

Done.

> src/hotspot/share/cds/heapShared.hpp line 425:
> 
>> 423:   static void clear_root(int index);
>> 424: 
>> 425:   static void set_runtime_delta(ptrdiff_t offset) {
> 
> For consistency, `offset` should be renamed to `delta`.

Done.

> src/hotspot/share/runtime/arguments.cpp line 3454:
> 
>> 3452: 
>> 3453:   if (DumpSharedSpaces && !UseCompressedOops) {
>> 3454:     FLAG_SET_CMDLINE(MaxHeapSize, (size_t)4 * G);
> 
> I think we should override MaxHeapSize only if it's greater than 4G. The user should be able to choose a smaller value.

Per our off list discussions, the InitialHeapSize, MinHeapSize, and MaxHeapSize are being set in
`universe_init()` via `MetaspaceShared::adjust_heap_sizes_for_dumping()`.

> test/hotspot/jtreg/runtime/cds/appcds/javaldr/HumongousDuringDump.java line 31:
> 
>> 29:  * @requires vm.cds.write.archived.java.heap
>> 30:  * @requires vm.jvmti
>> 31:  * @requires vm.opt.final.UseCompressedOops == true
> 
> Why is this change needed?

I ran the test with the -XX:-UseCompressedOops and without the change and it passed. I've reverted the change.

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

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


From mli at openjdk.java.net  Fri Jan 28 07:34:43 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 28 Jan 2022 07:34:43 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v3]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <JG8aUKtu7mpK5Sm0h6CQmMj-LemhBpHyoss-wxHWSbU=.8f4614cb-1252-4d24-9290-214c1bf5867b@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Remove Prepare-Region and Wait-For-Ready phases

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/a78499a5..1003c77c

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

  Stats: 204 lines in 12 files changed: 88 ins; 98 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From mli at openjdk.java.net  Fri Jan 28 08:04:18 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 28 Jan 2022 08:04:18 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <BHLuzndX3lTML0u7US6xbXSB3ck2itC99AoBtKZ0DYg=.5434aaba-d4da-4211-b8f7-87e9c70208c3@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <MkKC_uMmSFGS3pmLPRy8uFfvcFzoKuAf5_OCKsoZTL8=.f367f555-6945-4dd0-af8f-8a8b0d482567@github.com>
 <GxkulZGOPm60wg8jBtsfptd-rylbb22C38uanX--aeo=.6fa546bc-e2e0-4d28-a86e-3e93f06a16ce@github.com>
 <BHLuzndX3lTML0u7US6xbXSB3ck2itC99AoBtKZ0DYg=.5434aaba-d4da-4211-b8f7-87e9c70208c3@github.com>
Message-ID: <jXaeoVn242rRehflRqIjyYF1DubsW3wR5gEDCpsbgmE=.52d47447-d86c-48f4-83d9-01b9d7f71b8d@github.com>

On Thu, 27 Jan 2022 10:17:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I agree. This has only been a general remark about its performance, not meant to belittle the usefulness this change and in general all the changes in this series have, which are quite substantial. ? I compared the throughput (bytes/ms) between `Object Copy` and this phase, and at least without JDK-8280374 the `remove self forwards` is only like 2x the throughput of `Object Copy`, which seemed quite bad compared to what they do. With JDK-8280374 the results are much better (~4.5x) afaict on a single benchmark I tried though. It's a bit hard to reproduce the exact situation/heap though...
> 
> Another (future) optimization that may be worthwhile here may be to get some occupancy statistics of the chunks and switch between walking the bitmap and walking the objects; 

Yes, we have a similar task on our backlog, to fall back to walking the objects if the statistics tell us so.

> another one that might be "simpler" to implement (but fairly messy probably) is to simply check if the object after the current one is also forwarded, and if so, do not switch back to the bitmap walking but immediately process that one as well. This might help somewhat because given typical avg. object sizes (~40 bytes), the mark word after the current one might be already in the cache anyway, so a read access practically free.

I'm not sure how much this will help. Currently, the code looks like below, if the next obj is also marked, it will be applied with closure next time in the loop, it should has the same cache hit as the way you suggested above, the difference is the method (apply(current)) invocation overhead. But I will put it on backlog too. [TODO]

  while (next_addr < _limit) {
    Prefetch::write(next_addr, PrefetchScanIntervalInBytes);
    if (_bitmap->is_marked(next_addr)) {
      oop current = cast_to_oop(next_addr);
      next_addr += closure->apply(current);
    } else {
      next_addr = _bitmap->get_next_marked_addr(next_addr, _limit);
    }
  }


> 
> These are only ideas though.
> 
> > [...]
> > But I will investigate if we can omit "Prepared Retained Regions" and "Wait For Ready" subphases totally to simplify the logic. [TODO]
> 
> The point of "proper synchronization" isn't that it's faster, but it does not burn cpu cycles unnecessarily which potentially keeps the one thread that others are waiting on do the work. If we can remove the dependencies between the "Prepare Retained Regions" and the remaining phases, which only seems to be the BOT. One idea is that maybe all that prepare stuff could be placed where G1 adds that region to the list of retained regions. This does not work for the liveness count obviously - but that can be recreated by the actual self forwarding removal as suggested earlier ?).
> 
> Then none of that is required which is even better.

I have just delete the code related to "Prepared Retained Regions" and "Wait For Ready", and put the logic in G1EvacFailureRegions::record(...) and SampleCollectionSetCandidatesTask and VerifyAfterSelfForwardingPtrRemovalTask.

> 
> > > *) The "Prepared Retained Regions" phase stores the amount of live data into the HeapRegion; for this reason the change adds these G1RegionMarkStats data gathering via the G1RegionMarkStatsCache; I think the same information could be provided while iterating over the chunks (just do an Atomic::add here) instead. A single Atomic::add per thread per retained region at most seems to be okay. That would also remove the Evac Fail Merge Live phase afaict.
> > 
> > 
> > I will do this refactor soon.
> 
> Thanks!

This one is also done.

> 
> > > *) Not too happy that the G1HeapRegionChunk constructor does surprisingly much work, which surprisingly takes very little time.
> > > *) I was wondering whether it would be somewhat more efficient for the Prepare Chunks phase to collect some of the information needed there somehow else. Something is bubbling up in my mind, but nothing specific yet, and as mentioned, it might not be worth doing given its (lack of) cost.
> > 
> > 
> > I will put it on backlog to see if it can be simplified. [TODO]
> 
> Not necessarily simplified: one option is to make that work explicit (we tend to try to not do too much work in constructors - but maybe this just fits here), another is to pre-calculate some of these values during evacuation failure somehow.
> 
> We can maybe also postpone the optimization part of that suggestion given that currently that phase takes almost no time if it seems to be too much work.

OK, let's get back to this when it occupies much time in the phase.

> 
> Thanks for your hard work, Thomas

Thanks alot for detailed discussion and valuable suggestion, it helps alot :)

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

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


From ayang at openjdk.java.net  Fri Jan 28 08:16:14 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 Jan 2022 08:16:14 GMT
Subject: RFR: 8280804: Parallel: Remove unused variables in
 PSPromotionManager::drain_stacks_depth
In-Reply-To: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
References: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
Message-ID: <WcM0ythvUAnXW8aKA4AnuZhLJe_Ls281-iFTSkooosU=.de9f56b1-4496-4b4d-91f8-c74f6a755067@github.com>

On Thu, 27 Jan 2022 14:34:40 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/7245


From ayang at openjdk.java.net  Fri Jan 28 08:16:15 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 Jan 2022 08:16:15 GMT
Subject: Integrated: 8280804: Parallel: Remove unused variables in
 PSPromotionManager::drain_stacks_depth
In-Reply-To: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
References: <Pf54riFRoumhRaVQ4cpD0hP_fQL4fOHAY6ZTViwLt0I=.a63927da-8422-4b7c-b2f4-604a5eb35e53@github.com>
Message-ID: <WQnvi88GrlDN4goaEKV8vW4S8NtKuyFsFSmpjXQud1k=.8dd35400-351b-4391-bc9e-c77621d985f6@github.com>

On Thu, 27 Jan 2022 14:34:40 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: 973dda5c
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/973dda5ce0747a8ea67ec3a34c2ef2a0b2b6b140
Stats:     6 lines in 1 file changed: 0 ins; 6 del; 0 mod

8280804: Parallel: Remove unused variables in PSPromotionManager::drain_stacks_depth

Reviewed-by: tschatzl, mli

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

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


From mli at openjdk.java.net  Fri Jan 28 09:14:12 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 28 Jan 2022 09:14:12 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
Message-ID: <LO3hfHNfzt7d3o79u1LBq-Yp6EU-ggM52f5wrsbxgic=.5ee6e3d2-4a0a-4163-9537-23a88f5ee89f@github.com>

On Tue, 18 Jan 2022 04:31:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

> We have planned to make memory reclaimation more general, and reuse it in evacuation failure processing after JDK-8254739.
> Some of the work has already been done in JDK-8276670 and JDK-8277542.
> But after JDK-8278917, there is no need to return the memory used by G1SegmentedArray in evacuation failure processing, as it uses another way to do it.
> Currently, G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask is half-bound to card set, and half-general, it should be made more general for the readability of the code and future possible reuse of this functionality returning memory (used by G1SegmentedArray) to OS.

Kindly reminder ~

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

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


From tschatzl at openjdk.java.net  Fri Jan 28 09:19:13 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 28 Jan 2022 09:19:13 GMT
Subject: RFR: 8280397: Factor out task queue statistics printing [v3]
In-Reply-To: <9dSmgvIejPq_9mGsFzyykBoyw2yENqWp_WNYC6OMugE=.11a94c63-7763-45d0-9023-ac8973f460d4@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
 <kTt56SyGamgJbWvA26oWnGEMyOqy7XoDXqDr7zKzx2c=.689dcc5b-b0c4-4276-b1fa-e62781d9687b@github.com>
 <9dSmgvIejPq_9mGsFzyykBoyw2yENqWp_WNYC6OMugE=.11a94c63-7763-45d0-9023-ac8973f460d4@github.com>
Message-ID: <ZeJIpyqAGWMpMl6WBqdxGPuQXGtfLQgEbLhlgxCkE6c=.e73eeb86-7cf7-4afc-af68-825b91c8e304@github.com>

On Fri, 28 Jan 2022 01:30:29 GMT, Hamlin Li <mli 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 four commits:
>> 
>>  - Merge branch 'master' into 8280397-central-taskqueue-printing
>>  - kbarrett review, copyright dates
>>  - pliden review
>>  - Initial implementation using CollectedHeap
>
> Marked as reviewed by mli (Reviewer).

Thanks @Hamlin-Li @pliden @kimbarrett for your reviews!

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

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


From tschatzl at openjdk.java.net  Fri Jan 28 09:19:13 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 28 Jan 2022 09:19:13 GMT
Subject: Integrated: 8280397: Factor out task queue statistics printing
In-Reply-To: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
References: <IWNXD8gkP-Wy6WdWJIh0MmxwTEvSfOIIxgWioM1dZ_Y=.0c9f0387-898c-4a1f-912c-a293c9b7f19d@github.com>
Message-ID: <2qDpzy6DyGuyGi7DO-aCPJp18xi4ICA2LKX7Kk9npK0=.d1251ef4-febb-4321-a643-501520faa2b8@github.com>

On Fri, 21 Jan 2022 11:45:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes task queue (set) printing available in a central place so that not every user needs to reinvent the wheel?
> As example I wired up existing G1/Parallel GC young collection statistics printing, but I intend to add this for full gcs too; since ZGC and Shenandoah do not print task queues at all I do not intend to do that at least initially.
> Currently the main printing method is in `CollectedHeap`, but I can move it elsewhere if needed (all but Serial GC do use task queue sets though, so.....).
> 
> Testing: gha (building), local testing
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: ed826f29
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed826f2927457f73f058732c6d073acf54ee86f7
Stats:     136 lines in 5 files changed: 61 ins; 64 del; 11 mod

8280397: Factor out task queue statistics printing

Reviewed-by: pliden, kbarrett, mli

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

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


From tschatzl at openjdk.java.net  Fri Jan 28 10:04:27 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 28 Jan 2022 10:04:27 GMT
Subject: RFR: 8280450: Add task queue printing to STW Full GCs
Message-ID: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>

Hi all,

  please review this change that adds task queue statistics printing after full gc marking. This helps diagnosing performance issues there.

Testing: compilation, gha, local testing (all new code is guarded by `TASKQUEUE_STATS` so not compiled in by default)

Thanks,
  Thomas

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

Commit messages:
 - Initial implementation

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

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


From ayang at openjdk.java.net  Fri Jan 28 10:24:36 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 Jan 2022 10:24:36 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
Message-ID: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>

Simple change around CLD roots claim logic in `MarkFromRootsTask`.

Test: hotspot_gc

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

Commit messages:
 - ps-cld-root

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

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


From stefank at openjdk.java.net  Fri Jan 28 10:35:11 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 Jan 2022 10:35:11 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
In-Reply-To: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
Message-ID: <G0KMmAtTN-F-XfLIFmwmzfjY3lyFFVo7xFJ2-6SOXdY=.12dd0e5d-7eef-4fca-94c8-88cffa5d09aa@github.com>

On Fri, 28 Jan 2022 10:18:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
> 
> Test: hotspot_gc

FWIW, an alternative could be to completely remove the CLD *task* claiming and let all workers rely on the *CLD* claiming in CLDToOopClosure/ClassLoaderData::oops_do.

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

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


From ayang at openjdk.java.net  Fri Jan 28 11:08:43 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 Jan 2022 11:08:43 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
 [v2]
In-Reply-To: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
Message-ID: <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>

> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
> 
> 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/7265/files
  - new: https://git.openjdk.java.net/jdk/pull/7265/files/67fe7ff2..285b537a

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

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

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


From ayang at openjdk.java.net  Fri Jan 28 11:08:45 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 28 Jan 2022 11:08:45 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
In-Reply-To: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
Message-ID: <0-jtJV-IQR9uA1s-n3_5qIlbKLoGRoGsxr-zIlxJcrA=.a20b740c-d658-4af3-bc5e-6d0d787d6ea2@github.com>

On Fri, 28 Jan 2022 10:18:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
> 
> Test: hotspot_gc

> FWIW, an alternative could be to completely remove the CLD _task_ claiming and let all workers rely on the _CLD_ claiming in CLDToOopClosure/ClassLoaderData::oops_do.

Yes, you are right. Revised.

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

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


From stefank at openjdk.java.net  Fri Jan 28 12:07:12 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 28 Jan 2022 12:07:12 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
 [v2]
In-Reply-To: <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
 <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>
Message-ID: <Qows8uU29ltaBkQibGczt9EQWcVRCIukuN9ORsqPf2Q=.a547dc6e-e89a-4503-95e7-0fef2036d255@github.com>

On Fri, 28 Jan 2022 11:08:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by stefank (Reviewer).

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

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


From kbarrett at openjdk.java.net  Mon Jan 31 00:14:25 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 31 Jan 2022 00:14:25 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation
Message-ID: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>

Please review this change to to G1ConcurrentRefineThreads to simplify the
activation mechanism.

We split the class into two subclasses, one for the "primary" refinement
thread and another class for the remaining refinement threads.

The secondary threads are changed to use Monitor-based waits and notifications
with a supporting request flag.

The primary thread uses an atomic activation threshold that also serves as "is
running" state.  This activation threshold is used by the write barrier
support to determine whether the thread's semaphore needs to be signaled.
That threshold is now in the primary refinement thread rather than in the
dirty card queue set to simplify threshold management and somewhat reduce
coupling.

Testing:
mach5 tier1-3

Manual tests with refinement thread logging enabled to verify expected
activations occur.

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

Commit messages:
 - refactor refinement threads

Changes: https://git.openjdk.java.net/jdk/pull/7282/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7282&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280917
  Stats: 386 lines in 7 files changed: 237 ins; 96 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7282/head:pull/7282

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


From iwalulya at openjdk.java.net  Mon Jan 31 08:50:16 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 31 Jan 2022 08:50:16 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list
In-Reply-To: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
Message-ID: <dQEkNmbKP4fSQKdfl624EDQzAmMtSnw1-7Rq1n5maCY=.b118b557-d413-4568-8f7e-854a262e633d@github.com>

On Tue, 25 Jan 2022 05:04:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to BufferNode::Allocator::release to avoid needing
> to walk the pending list in preparation for transferring it to the free list.
> We need to have both the head and the tail of the pending list to perform that
> transfer.
> 
> Rather than using a LockFreeStack to accumulate the pending list, we now use a
> bespoke data structure that only supports concurrent additions, since that's
> all we need.  This simplifies the code, and also makes it easy to capture the
> first pushed node as the tail.
> 
> To make the transfer from the pending list to the free list, we double-buffer
> the pending list.  Additions are made to the currently active pending list.  A
> transfer flips which pending list is active, and transfers from the list that
> was just deactivated.  Additions are made in a critical section.  The critical
> section synchronization already performed when transferring now does double
> duty, also synchronizing the pending list flip.
> 
> Testing:
> mach5 tier1-3
> 
> Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
> occurring as expected.

src/hotspot/share/gc/shared/ptrQueue.cpp line 88:

> 86: BufferNode::Allocator::Allocator(const char* name, size_t buffer_size) :
> 87:   _buffer_size(buffer_size),
> 88:   _pending_lists{},

Suggestion:

  _pending_lists(),


Some buggy compilers attempt to initialize the aggregate using copy initialization ({ initializer-list }), which consequently calls the deleted PendingList copy constructor. This is a compiler bug; according to the c++14 standard (8.5.1/7 and 8.5.4/3.4), the object should be value-initialized in this case as the initializer list has no elements.

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

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


From ayang at openjdk.java.net  Mon Jan 31 09:30:14 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 31 Jan 2022 09:30:14 GMT
Subject: RFR: 8280450: Add task queue printing to STW Full GCs
In-Reply-To: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
References: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
Message-ID: <6q4ZIGQHHgFgmzj2wuto-zL58aVgg3xCbIThgJUxfZM=.efa28d06-7f34-460e-9dd9-971b27316efe@github.com>

On Fri, 28 Jan 2022 09:58:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that adds task queue statistics printing after full gc marking. This helps diagnosing performance issues there.
> 
> Testing: compilation, gha, local testing (all new code is guarded by `TASKQUEUE_STATS` so not compiled in by default)
> 
> Thanks,
>   Thomas

I feel `TASKQUEUE_STATS` and the fact that there are two task queues are too low-level in this context. However, I am not sure hiding them behind a method is definitely better either. Pragmatically, we can keep it this way for now and refine it latter if needed.

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

Marked as reviewed by ayang (Reviewer).

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


From ayang at openjdk.java.net  Mon Jan 31 09:39:30 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 31 Jan 2022 09:39:30 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
Message-ID: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>

Mostly mechanical changes of renaming some methods/comments.

Test: build

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

Commit messages:
 - rename-strong-code-roots

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

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


From sjohanss at openjdk.java.net  Mon Jan 31 15:56:10 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 31 Jan 2022 15:56:10 GMT
Subject: RFR: 8280450: Add task queue printing to STW Full GCs
In-Reply-To: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
References: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
Message-ID: <J9jVe3XIUFaUdKYdCzRJ-273bUFdmAymL0ZLq9FWQjc=.694306e1-990c-4377-81e3-1a47042a6592@github.com>

On Fri, 28 Jan 2022 09:58:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that adds task queue statistics printing after full gc marking. This helps diagnosing performance issues there.
> 
> Testing: compilation, gha, local testing (all new code is guarded by `TASKQUEUE_STATS` so not compiled in by default)
> 
> Thanks,
>   Thomas

Marked as reviewed by sjohanss (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:02:06 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:02:06 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats [v2]
In-Reply-To: <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
 <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
Message-ID: <tz-SASfJZNTbCkE2IznCmh33sXeLAKUXdd-JRytzcz4=.cd752fcc-a8b3-4991-9888-89d9699363f0@github.com>

On Thu, 20 Jan 2022 11:11:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews that improves task queue statistics?
>> 
>> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
>> 
>> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
>> 
>> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
>> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>>   0    3777115    3776816       3872      17434       9630          0          0
>> 
>> And new:
>> 
>> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
>> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
>> [...]
>> 
>> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
>> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
>> 
>> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some further cleanup
>  - kbarrett review

In need for a second reviewer... :)

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:06:18 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:06:18 GMT
Subject: Integrated: 8280705: Parallel: Full gc mark stack draining should
 prefer to make work available to other threads
In-Reply-To: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
References: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
Message-ID: <dejRINj9iKQG_OvtjMmK-62KCffTUmRUiuouJpcaHsM=.5336dcbb-3e58-4367-b288-bbf811b42e01@github.com>

On Thu, 27 Jan 2022 12:49:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that improves task queue handling during queue overflow similar to JDK-8280396 for Parallel GC? Basically the change modifies the queue selection heuristics to be the same as for G1.
> 
> Testing: tier1-5, internal promotion perf testing, perf testing of some local benchmarks (BRT, optaplanner) looking for regressions
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: bdda43e0
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bdda43e066b8da0ebf9a8ef2f843eabb230f0800
Stats:     26 lines in 3 files changed: 16 ins; 5 del; 5 mod

8280705: Parallel: Full gc mark stack draining should prefer to make work available to other threads

Reviewed-by: ayang, mli

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:06:18 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:06:18 GMT
Subject: RFR: 8280705: Parallel: Full gc mark stack draining should prefer
 to make work available to other threads
In-Reply-To: <6J8ekT8JdKzdZ110jgXtB-pJwsN7hwf0rxrWzbtNg6A=.f94d0a10-a070-4d00-b0da-df42e940d342@github.com>
References: <s7Yk1ApTkQX68s0PGks2QZhraUmXlmEh1VxxTMtx2QA=.387c60ec-e27a-4098-a0b3-190c792f4676@github.com>
 <6J8ekT8JdKzdZ110jgXtB-pJwsN7hwf0rxrWzbtNg6A=.f94d0a10-a070-4d00-b0da-df42e940d342@github.com>
Message-ID: <EkO2GCg0crODbI9QZ9z4aTZ24DN8wt-HwRXJRo1Mcqg=.232fa55d-7184-41cc-85cc-0f0132d5de63@github.com>

On Thu, 27 Jan 2022 13:34:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that improves task queue handling during queue overflow similar to JDK-8280396 for Parallel GC? Basically the change modifies the queue selection heuristics to be the same as for G1.
>> 
>> Testing: tier1-5, internal promotion perf testing, perf testing of some local benchmarks (BRT, optaplanner) looking for regressions
>> 
>> Thanks,
>>   Thomas
>
> `transfer_from_overflow_stack` tries to publish any many items as possible to the global queue (eligible for work stealing), and returns whether we have successfully popped an item from the local overflow queue. How about `publish_or_pop_overflow`?

Thanks @albertnetymk @Hamlin-Li for your reviews

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

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


From sjohanss at openjdk.java.net  Mon Jan 31 16:07:15 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 31 Jan 2022 16:07:15 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>
Message-ID: <CyzvA3-XANH7J9HCfZjmqoRB91rIl8-jwr3Dndpbyms=.79776359-7166-420b-b3e4-7a3e17c72b79@github.com>

On Tue, 25 Jan 2022 15:40:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - review

Marked as reviewed by sjohanss (Reviewer).

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

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


From iwalulya at openjdk.java.net  Mon Jan 31 16:14:12 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 31 Jan 2022 16:14:12 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats [v2]
In-Reply-To: <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
 <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
Message-ID: <H84rQ8TnB--c-GtquX-9rMZRa4Z0W7AicS9C4_S6AqA=.d5d39f2b-25f8-42f9-ba46-178b4055cf43@github.com>

On Thu, 20 Jan 2022 11:11:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews that improves task queue statistics?
>> 
>> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
>> 
>> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
>> 
>> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
>> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>>   0    3777115    3776816       3872      17434       9630          0          0
>> 
>> And new:
>> 
>> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
>> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
>> [...]
>> 
>> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
>> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
>> 
>> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Some further cleanup
>  - kbarrett review

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:55:16 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:55:16 GMT
Subject: RFR: 8280139: Report more detailed statistics about task stealing
 in task queue stats [v2]
In-Reply-To: <UpkxeJ5Pe449Kdf3-_AEmhIhD1NbVZ9HtmDMKoqRzDA=.d61ca533-5f1e-401a-8a19-b49355169e91@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
 <lqcLP3kgeJ8pvlFVsvGMbQte_KMjPm9DvI8yATOGSP4=.f6455b85-cf1f-4b4b-950c-5e55e3ca568c@github.com>
 <UpkxeJ5Pe449Kdf3-_AEmhIhD1NbVZ9HtmDMKoqRzDA=.d61ca533-5f1e-401a-8a19-b49355169e91@github.com>
Message-ID: <_ERBcnSyzxjBW76PSWJJcGPAG9mietjNCLUbLEW2pQc=.8b14fa96-b950-440a-b670-8b203c850a72@github.com>

On Thu, 20 Jan 2022 21:40:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Some further cleanup
>>  - kbarrett review
>
> Marked as reviewed by kbarrett (Reviewer).

Thanks @kimbarrett @walulyai for your reviews

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:55:16 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:55:16 GMT
Subject: Integrated: 8280139: Report more detailed statistics about task
 stealing in task queue stats
In-Reply-To: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
References: <LWHVUbxRpqmLDdgmIgD9ZWWQdsvIH5u9Uje4qfAFRrg=.f0b33cca-5c6a-46df-921c-0ca1277ffc7b@github.com>
Message-ID: <SMU0BvsO0uyoAsiPlpi-PgYTiBNrVcrJm8G7BSB3LYU=.6c89f64b-4fc9-48d0-be9f-1eafc59c9030@github.com>

On Wed, 19 Jan 2022 12:55:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews that improves task queue statistics?
> 
> This is a step to see problems with task queue in general and measure future task stealing improvements in GC; particularly contention on steal information has shown to be correlated to performance, so information about basic occurrences during stealing (how many empty, how many contended, how many contended in a row, max contended accesses in a row) in the task queue is very interesting for further performance work.
> 
> Old output of `gc+tasks+stats=trace` after compiling in these statistics:
> 
> thr      qpush       qpop     qpop-s   qattempt     qsteal      opush       omax
> --- ---------- ---------- ---------- ---------- ---------- ---------- ----------
>   0    3777115    3776816       3872      17434       9630          0          0
> 
> And new:
> 
> thr        push         pop    pop-slow  st-attempt    st-empty     st-ctdd  st-success st-ctdd-max st-biasdrop  ovflw-push   ovflw-max
> --- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- ----------- -----------
>   0     4616264     4616218        3608       12945           1        1650       11294           5        9405           0           0
> [...]
> 
> The first four columns stayed the same, then the `qsteal` has been split up into the various steal results (empty/contended/success). `st_ctdd_max` gives the maximum amount of contended steal attempts in a row. `st_biasdrop` shows how many times the steal bias has been dropped (reset).
> `ovflw-push` and `ovfl-max` are the same as before, just renamed a bit to use the available space.
> 
> There has been no intention to change anything about the algorithm, so there is no need for perf testing (I can see). Later changes will do that.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: dcc666d5
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dcc666d53d66e87c11c0c39858b36d40299b7de6
Stats:     96 lines in 3 files changed: 57 ins; 1 del; 38 mod

8280139: Report more detailed statistics about task stealing in task queue stats

Reviewed-by: kbarrett, iwalulya

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:56:15 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:56:15 GMT
Subject: RFR: 8280450: Add task queue printing to STW Full GCs
In-Reply-To: <J9jVe3XIUFaUdKYdCzRJ-273bUFdmAymL0ZLq9FWQjc=.694306e1-990c-4377-81e3-1a47042a6592@github.com>
References: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
 <J9jVe3XIUFaUdKYdCzRJ-273bUFdmAymL0ZLq9FWQjc=.694306e1-990c-4377-81e3-1a47042a6592@github.com>
Message-ID: <72rQhR-QrDh2xZ6_CfAd2bbpeQrEh-ZEsQUvkMoT6yM=.e46bc12f-1d5e-43aa-ac25-af173b45511f@github.com>

On Mon, 31 Jan 2022 15:52:40 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that adds task queue statistics printing after full gc marking. This helps diagnosing performance issues there.
>> 
>> Testing: compilation, gha, local testing (all new code is guarded by `TASKQUEUE_STATS` so not compiled in by default)
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by sjohanss (Reviewer).

Thanks @kstefanj @albertnetymk for your reviews

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:56:16 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:56:16 GMT
Subject: Integrated: 8280450: Add task queue printing to STW Full GCs
In-Reply-To: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
References: <rokzjF009MccFnl6lB0C3GuobNef8q9HHaPqqsUwa7w=.1540614a-9103-4120-9b99-60f5739db81e@github.com>
Message-ID: <I7pDhRyYcvBu4wKN4sCf-UiLxnTXr_FDm1V60o70iUQ=.02e2e265-8e7a-468e-9ecf-a7440145fb19@github.com>

On Fri, 28 Jan 2022 09:58:03 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that adds task queue statistics printing after full gc marking. This helps diagnosing performance issues there.
> 
> Testing: compilation, gha, local testing (all new code is guarded by `TASKQUEUE_STATS` so not compiled in by default)
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 993a2488
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/993a2488ef42b4c63a7e342c12bba8af8e3fab40
Stats:     8 lines in 2 files changed: 8 ins; 0 del; 0 mod

8280450: Add task queue printing to STW Full GCs

Reviewed-by: ayang, sjohanss

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

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


From tschatzl at openjdk.java.net  Mon Jan 31 16:57:21 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 16:57:21 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>
Message-ID: <6A27mo9hKyUiWbxyn_iLYy7K2woujz247ys5mytrz7s=.e5a73a39-2cf9-4bcf-8120-72909be86dbc@github.com>

On Tue, 25 Jan 2022 15:40:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - review

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jan 31 17:05:18 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 31 Jan 2022 17:05:18 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
In-Reply-To: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
Message-ID: <GEvRKOORXcL0dRxSjm4-73G3-rxPSxewTbvnElY9Au4=.623e7716-47e6-44ee-8bb8-16ce0f8fe8d5@github.com>

On Mon, 31 Jan 2022 09:31:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes of renaming some methods/comments.
> 
> Test: build

Some more candidates for renaming:


void G1CollectedHeap::rebuild_strong_code_roots() {
  RebuildStrongCodeRootClosure blob_cl(this);
  CodeCache::blobs_do(&blob_cl);
}


Please also look after "strong code root" in comments (mostly related to this method). Also e.g. in g1RemSetSummary.cpp:236/303 though.

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

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


From kbarrett at openjdk.java.net  Mon Jan 31 17:17:52 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 31 Jan 2022 17:17:52 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list [v2]
In-Reply-To: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
Message-ID: <0ysr7jD8VttN371ZU5aMlolFGelM43faeIh3ht9O_6k=.1fd6daa0-d5aa-4967-9468-7a8b560a3697@github.com>

> Please review this change to BufferNode::Allocator::release to avoid needing
> to walk the pending list in preparation for transferring it to the free list.
> We need to have both the head and the tail of the pending list to perform that
> transfer.
> 
> Rather than using a LockFreeStack to accumulate the pending list, we now use a
> bespoke data structure that only supports concurrent additions, since that's
> all we need.  This simplifies the code, and also makes it easy to capture the
> first pushed node as the tail.
> 
> To make the transfer from the pending list to the free list, we double-buffer
> the pending list.  Additions are made to the currently active pending list.  A
> transfer flips which pending list is active, and transfers from the list that
> was just deactivated.  Additions are made in a critical section.  The critical
> section synchronization already performed when transferring now does double
> duty, also synchronizing the pending list flip.
> 
> Testing:
> mach5 tier1-3
> 
> Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
> occurring as expected.

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

 - update copyrights
 - change _pending_lists init for compiler bug workaround

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7210/files
  - new: https://git.openjdk.java.net/jdk/pull/7210/files/32133237..70c52abb

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

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

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


From kbarrett at openjdk.java.net  Mon Jan 31 17:17:54 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 31 Jan 2022 17:17:54 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list [v2]
In-Reply-To: <dQEkNmbKP4fSQKdfl624EDQzAmMtSnw1-7Rq1n5maCY=.b118b557-d413-4568-8f7e-854a262e633d@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
 <dQEkNmbKP4fSQKdfl624EDQzAmMtSnw1-7Rq1n5maCY=.b118b557-d413-4568-8f7e-854a262e633d@github.com>
Message-ID: <iNG2oJpZSYxBWnUApTMDriF_jgvXu04l9NIfH9ToIFM=.8e46f002-21ec-4efa-ad45-3559177279f8@github.com>

On Mon, 31 Jan 2022 08:46:57 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyrights
>>  - change _pending_lists init for compiler bug workaround
>
> src/hotspot/share/gc/shared/ptrQueue.cpp line 88:
> 
>> 86: BufferNode::Allocator::Allocator(const char* name, size_t buffer_size) :
>> 87:   _buffer_size(buffer_size),
>> 88:   _pending_lists{},
> 
> Suggestion:
> 
>   _pending_lists(),
> 
> 
> Some buggy compilers attempt to initialize the aggregate using copy initialization ({ initializer-list }), which consequently calls the deleted PendingList copy constructor. This is a compiler bug; according to the c++14 standard (8.5.1/7 and 8.5.4/3.4), the object should be value-initialized in this case as the initializer list has no elements.

Thanks for discovering the problem and the discussion that led to this solution.  I've added that fix to the PR.  In case any readers are interested, the failure was encountered with gcc 8.2.  No idea of the actual version range with the problem.  I spent some time perusing the gcc bug database but didn't find a match there, though that could easily be a failure to find the right search terms.

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

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


From ccheung at openjdk.java.net  Mon Jan 31 23:57:57 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 31 Jan 2022 23:57:57 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
Message-ID: <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>

> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
> 
> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
> 
> Preliminary HelloWorld startup perf. improvement:
> 
> instr delta =    -68813432    -49.7140%
> time  delta =      -14.720 ms -20.3599%

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  code cleanup and added a test case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7223/files
  - new: https://git.openjdk.java.net/jdk/pull/7223/files/5ac98ba1..5a3ce9a4

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

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

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