From mli at openjdk.java.net  Wed Sep  1 03:18:48 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 1 Sep 2021 03:18:48 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v4]
In-Reply-To: <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <2rdaiC7TDwMQiq035XVEhD0kbYXiOc9EL3ZxogYI21o=.b1965f40-0ac7-4f2c-aec5-07bf2207d583@github.com>
 <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
Message-ID: <EUHQu1ZbcwoWw7NxgC42PZdIf_OnC0ZKUydlDHThxpg=.6697ae7f-0809-409b-8070-9c5d1c8ec8d9@github.com>

On Tue, 31 Aug 2021 15:31:03 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 five commits:
>> 
>>  - merge from master
>>  - Fix missing header files
>>  - reuse original bitmap rather than CHT
>>  - merge with existing classes
>>  - Initial commit
>
> src/hotspot/share/gc/g1/g1EvacuationFailureRegions.cpp line 51:
> 
>> 49:                                              HeapRegionClaimer* _hrclaimer,
>> 50:                                              uint worker_id) {
>> 51:   assert_at_safepoint();
> 
> As far as I can see this is a verbatim copy of `G1CollectionSet::iterate_part_from` (with some minor simplifications). Not really happy about that, need to think more about how/if we can avoid this.

Agree. I think the reason is that we have mixed iteration itself with the logic in hrm/cset/evac failure regions.
One option to do might be to extract the iteration logic separately, should we do this in a separate issue?

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

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


From mli at openjdk.java.net  Wed Sep  1 03:40:22 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 1 Sep 2021 03:40:22 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v5]
In-Reply-To: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
Message-ID: <xxEiob0lrNMj00ko6TfHxPS7Qmh9PaJVloBPSSbyNQY=.1fff5f47-a7b9-4fb5-b83b-40756e547687@github.com>

> This is another try to optimize evcuation failure for regions.
> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
> 
> I have 2 implementations:
> 
> - 1) CHT (Initial version)
> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
> 
> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
> 
> I will attach the perf data in JBS.

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

  Modify as review comments suggested.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5272/files
  - new: https://git.openjdk.java.net/jdk/pull/5272/files/6f0c796a..7fa8496d

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

  Stats: 356 lines in 11 files changed: 170 ins; 172 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5272/head:pull/5272

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


From mli at openjdk.java.net  Wed Sep  1 05:35:50 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 1 Sep 2021 05:35:50 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v4]
In-Reply-To: <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <2rdaiC7TDwMQiq035XVEhD0kbYXiOc9EL3ZxogYI21o=.b1965f40-0ac7-4f2c-aec5-07bf2207d583@github.com>
 <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
Message-ID: <79nzpwdAR-G8YLOL4ZFEMtyvora1k76QkNimqWm9ZfM=.cda74e37-5589-41fd-a6ca-de94fdafc33f@github.com>

On Tue, 31 Aug 2021 15:08:55 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 five commits:
>> 
>>  - merge from master
>>  - Fix missing header files
>>  - reuse original bitmap rather than CHT
>>  - merge with existing classes
>>  - Initial commit
>
> src/hotspot/share/gc/g1/g1EvacuationFailureRegions.cpp line 1:
> 
>> 1: /*
> 
> It's a bit weird that all other similar files start with "g1EvacFailure" and this one with "g1EvacuationFailure" - please change according to existing style (or rename all others first in a separate CR).

Sure. I created JDK-8273218 to modify just g1EvacuationInfo.hpp and related class name, as it's more simple than modify every EvacXxx to EvacuationXxx.

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

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


From mli at openjdk.java.net  Wed Sep  1 05:45:09 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 1 Sep 2021 05:45:09 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo
Message-ID: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>

This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

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

Commit messages:
 - Rename g1EvacuationInfo.hpp to g1EvacInfo.hpp, and related class names

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

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


From fmatte at openjdk.java.net  Wed Sep  1 05:56:10 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 1 Sep 2021 05:56:10 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v2]
In-Reply-To: <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <GsSAnYhVkwpl-361QO1GIyhm5xVdgX-sybAC_SkI3xg=.1c0e93e5-1b7c-4af4-af8e-ef32340b0e56@github.com>
Message-ID: <3s5tEfAOoagk3KUNawQSUcD8XC0KFHaJliJ9coABlTs=.40ec1088-4aaa-4808-943e-3f69ea0ac82a@github.com>

On Tue, 31 Aug 2021 14:54:56 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

Thanks, updated the patch.

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

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


From fmatte at openjdk.java.net  Wed Sep  1 05:56:09 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 1 Sep 2021 05:56:09 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v3]
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <q0pUoYDQXxC6_YTflFscrV8XKd8Qqrj7z12IpmCHeTc=.f140da9c-2df2-4c3b-ae2a-39105dca3bc1@github.com>

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:

  8272563: Possible assertion failure in CardTableBarrierSetC1

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5164/files
  - new: https://git.openjdk.java.net/jdk/pull/5164/files/c023f4bc..5c1e1d49

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

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

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


From iveresov at openjdk.java.net  Wed Sep  1 06:55:45 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 1 Sep 2021 06:55:45 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v3]
In-Reply-To: <q0pUoYDQXxC6_YTflFscrV8XKd8Qqrj7z12IpmCHeTc=.f140da9c-2df2-4c3b-ae2a-39105dca3bc1@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <q0pUoYDQXxC6_YTflFscrV8XKd8Qqrj7z12IpmCHeTc=.f140da9c-2df2-4c3b-ae2a-39105dca3bc1@github.com>
Message-ID: <BX3tAGrrpdSNbVpOUhSUsmPuyGOH9QY9nhuyAJSXrdc=.0bd63862-3fe3-41c0-a0e0-935947688f65@github.com>

On Wed, 1 Sep 2021 05:56:09 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp line 72:

> 70:     LIR_Opr addr_opr = LIR_OprFact::address(new LIR_Address(addr, addr->type()));
> 71:     __ leal(addr_opr, tmp);
> 72:     __ move(addr, tmp);

You don't need the move anymore.

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

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


From fmatte at openjdk.java.net  Wed Sep  1 06:55:45 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 1 Sep 2021 06:55:45 GMT
Subject: RFR: 8272563: Possible assertion failure in CardTableBarrierSetC1
 [v3]
In-Reply-To: <BX3tAGrrpdSNbVpOUhSUsmPuyGOH9QY9nhuyAJSXrdc=.0bd63862-3fe3-41c0-a0e0-935947688f65@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <q0pUoYDQXxC6_YTflFscrV8XKd8Qqrj7z12IpmCHeTc=.f140da9c-2df2-4c3b-ae2a-39105dca3bc1@github.com>
 <BX3tAGrrpdSNbVpOUhSUsmPuyGOH9QY9nhuyAJSXrdc=.0bd63862-3fe3-41c0-a0e0-935947688f65@github.com>
Message-ID: <PUWQfpOUt0Ho20HnViu8Z6K9CkDBFM2Thy0u1SCsLxw=.aa25642f-8764-4ee0-acdc-41598bde6833@github.com>

On Wed, 1 Sep 2021 06:49:47 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8272563: Possible assertion failure in CardTableBarrierSetC1
>
> src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp line 72:
> 
>> 70:     LIR_Opr addr_opr = LIR_OprFact::address(new LIR_Address(addr, addr->type()));
>> 71:     __ leal(addr_opr, tmp);
>> 72:     __ move(addr, tmp);
> 
> You don't need the move anymore.

ok, will remove that.

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

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


From iveresov at openjdk.java.net  Wed Sep  1 07:10:07 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 1 Sep 2021 07:10:07 GMT
Subject: RFR: 8272563: assert(is_double_stack() && !is_virtual()) failed:
 type check [v4]
In-Reply-To: <h8u5LGTNQduUWk3KFrQ4XQ5tPVtsJq8XaAgQULA_xaQ=.d832a5a1-10f3-4ae7-81cb-845267fd99ef@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <h8u5LGTNQduUWk3KFrQ4XQ5tPVtsJq8XaAgQULA_xaQ=.d832a5a1-10f3-4ae7-81cb-845267fd99ef@github.com>
Message-ID: <inUfriT7os13lC-3P4r6xp7J2MetFALwlQB7y-mtQpM=.795c375e-2300-41e5-9709-a01ef131d749@github.com>

On Wed, 1 Sep 2021 07:06:21 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

Marked as reviewed by iveresov (Reviewer).

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

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


From fmatte at openjdk.java.net  Wed Sep  1 07:10:07 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 1 Sep 2021 07:10:07 GMT
Subject: RFR: 8272563: assert(is_double_stack() && !is_virtual()) failed:
 type check [v4]
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <h8u5LGTNQduUWk3KFrQ4XQ5tPVtsJq8XaAgQULA_xaQ=.d832a5a1-10f3-4ae7-81cb-845267fd99ef@github.com>

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:

  8272563: Possible assertion failure in CardTableBarrierSetC1

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5164/files
  - new: https://git.openjdk.java.net/jdk/pull/5164/files/5c1e1d49..359cbf3d

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

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

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


From iveresov at openjdk.java.net  Wed Sep  1 07:10:08 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 1 Sep 2021 07:10:08 GMT
Subject: RFR: 8272563: assert(is_double_stack() && !is_virtual()) failed:
 type check [v3]
In-Reply-To: <q0pUoYDQXxC6_YTflFscrV8XKd8Qqrj7z12IpmCHeTc=.f140da9c-2df2-4c3b-ae2a-39105dca3bc1@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <q0pUoYDQXxC6_YTflFscrV8XKd8Qqrj7z12IpmCHeTc=.f140da9c-2df2-4c3b-ae2a-39105dca3bc1@github.com>
Message-ID: <mSaIFvqMNnH6adRIe5ExT0-c9kPbH4QGBAUGHE9jmu4=.86f2965d-b6c2-4391-b273-8eb19c324168@github.com>

On Wed, 1 Sep 2021 05:56:09 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

Looks good!

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

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


From tschatzl at openjdk.java.net  Wed Sep  1 08:14:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Sep 2021 08:14:47 GMT
Subject: RFR: 8273140: Replace usages of Enum.class.getEnumConstants()
 with Enum.values() where possible [v4]
In-Reply-To: <eXT8epUJ68N-HvoGsaee3FySbKKe9u5MpRxs4LjeOsM=.055ec55e-c535-4c25-960f-f628136e2733@github.com>
References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com>
 <eXT8epUJ68N-HvoGsaee3FySbKKe9u5MpRxs4LjeOsM=.055ec55e-c535-4c25-960f-f628136e2733@github.com>
Message-ID: <sZdTQPyJfnO2H8KJ0S5anfcx8QCEpr0-8TLuDVkSCDE=.f017808f-82f0-476b-8fec-a95871183266@github.com>

On Tue, 31 Aug 2021 20:04:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Just a very tiny clean-up.
>> 
>> There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access:
>> 
>> public T[] getEnumConstants() {
>>     T[] values = getEnumConstantsShared();
>>     return (values != null) ? values.clone() : null;
>> }
>> 
>> private transient volatile T[] enumConstants;
>> 
>> T[] getEnumConstantsShared() {
>>     T[] constants = enumConstants;
>>     if (constants == null) { /* ... */ }
>>     return constants;
>> }
>> 
>> Calling values() method is slightly faster:
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class EnumBenchmark {
>> 
>>   @Benchmark
>>   public Enum[] values() {
>>     return Enum.values();
>>   }
>> 
>>   @Benchmark
>>   public Enum[] getEnumConstants() {
>>     return Enum.class.getEnumConstants();
>>   }
>> 
>>   private enum Enum {
>>     A,
>>     B
>>   }
>> }
>> 
>> 
>> Benchmark                                                        Mode  Cnt     Score     Error   Units
>> EnumBenchmark.getEnumConstants                                   avgt   15     6,265 ?   0,051   ns/op
>> EnumBenchmark.getEnumConstants:?gc.alloc.rate                    avgt   15  2434,075 ?  19,568  MB/sec
>> EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm               avgt   15    24,002 ?   0,001    B/op
>> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space           avgt   15  2433,709 ?  70,216  MB/sec
>> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm      avgt   15    23,998 ?   0,659    B/op
>> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space       avgt   15     0,009 ?   0,003  MB/sec
>> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm  avgt   15    ? 10??              B/op
>> EnumBenchmark.getEnumConstants:?gc.count                         avgt   15   210,000            counts
>> EnumBenchmark.getEnumConstants:?gc.time                          avgt   15   119,000                ms
>> 
>> EnumBenchmark.values                                             avgt   15     4,164 ?   0,134   ns/op
>> EnumBenchmark.values:?gc.alloc.rate                              avgt   15  3665,341 ? 120,721  MB/sec
>> EnumBenchmark.values:?gc.alloc.rate.norm                         avgt   15    24,002 ?   0,001    B/op
>> EnumBenchmark.values:?gc.churn.G1_Eden_Space                     avgt   15  3660,512 ? 137,250  MB/sec
>> EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm                avgt   15    23,972 ?   0,529    B/op
>> EnumBenchmark.values:?gc.churn.G1_Survivor_Space                 avgt   15     0,017 ?   0,003  MB/sec
>> EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm            avgt   15    ? 10??              B/op
>> EnumBenchmark.values:?gc.count                                   avgt   15   262,000            counts
>> EnumBenchmark.values:?gc.time                                    avgt   15   155,000                ms
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273140: Fix copyright year

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep  1 08:15:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Sep 2021 08:15:47 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo
In-Reply-To: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
Message-ID: <hYtL65O5fsyvzcMoYH4rcXO2fTM4QKE5TEGBjWDr7AE=.749ec5b2-44dd-44de-aa2d-cfb26b51d369@github.com>

On Wed, 1 Sep 2021 05:37:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

Lgtm.

Note that because you were so fast posting this, I do not know what others think about the name change in this direction, but I think it's okay. Please wait for further feedback.

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

> 27: #include "gc/g1/g1AllocRegion.inline.hpp"
> 28: #include "gc/g1/g1EvacStats.inline.hpp"
> 29: #include "gc/g1/g1EvacInfo.hpp"

Alphabetical order changed.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 39:

> 37: #include "gc/g1/g1EvacFailure.hpp"
> 38: #include "gc/g1/g1EvacStats.hpp"
> 39: #include "gc/g1/g1EvacInfo.hpp"

Include order

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Wed Sep  1 08:31:05 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 1 Sep 2021 08:31:05 GMT
Subject: RFR: 8273221: Guard GCIdMark against nested calls
Message-ID: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>

Simple change of forbidding nested GC ids.

Test: tier1-6

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

Commit messages:
 - gcid

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

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


From ayang at openjdk.java.net  Wed Sep  1 08:38:43 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 1 Sep 2021 08:38:43 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo
In-Reply-To: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
Message-ID: <hKEg4Dqy0WZeY25BrW37U15r6WhugrIAVXlPsNgq1uQ=.186ccbd6-7869-42b4-8fdb-cffc8cd657c8@github.com>

On Wed, 1 Sep 2021 05:37:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

Marked as reviewed by ayang (Reviewer).

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

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


From thartmann at openjdk.java.net  Wed Sep  1 10:12:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 1 Sep 2021 10:12:50 GMT
Subject: RFR: 8272563: assert(is_double_stack() && !is_virtual()) failed:
 type check [v4]
In-Reply-To: <h8u5LGTNQduUWk3KFrQ4XQ5tPVtsJq8XaAgQULA_xaQ=.d832a5a1-10f3-4ae7-81cb-845267fd99ef@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
 <h8u5LGTNQduUWk3KFrQ4XQ5tPVtsJq8XaAgQULA_xaQ=.d832a5a1-10f3-4ae7-81cb-845267fd99ef@github.com>
Message-ID: <DKcvtWjq4zzldjVh5nhcd-j_m-juTEjsf8lDpUSfdJA=.89b0af19-5584-40e8-8313-67e3b04df399@github.com>

On Wed, 1 Sep 2021 07:10:07 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

>> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
>> 
>> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>>> __ move(addr, tmp);
>> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
>> The fix is to check if it is is_oop() and call the mov appropriately.
>> 
>> No issues found in local testing and Mach5 tier1-3
>
> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8272563: Possible assertion failure in CardTableBarrierSetC1

Looks good to me too!

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

Marked as reviewed by thartmann (Reviewer).

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


From fmatte at openjdk.java.net  Wed Sep  1 10:15:52 2021
From: fmatte at openjdk.java.net (Fairoz Matte)
Date: Wed, 1 Sep 2021 10:15:52 GMT
Subject: Integrated: 8272563: assert(is_double_stack() && !is_virtual())
 failed: type check
In-Reply-To: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
References: <6X_l0Bp30HEmNGg9L3ov-n68XuRo9JrW9uvj6pSwqjk=.46f88a66-7256-4647-a74f-27b976c1200e@github.com>
Message-ID: <nNnb8W2YvFkKlYBsgN93sdIiBRJbaSJyQtOgscM6V0o=.400fc17d-67e0-4a04-b070-888afee5b816@github.com>

On Wed, 18 Aug 2021 12:37:00 GMT, Fairoz Matte <fmatte at openjdk.org> wrote:

> This patch is proposed by the submitter of the bug - ugawa at ci.i.u-tokyo.ac.jp
> 
> The method CardTableBarrierSetC1::post_barrier generates a move LIR when TwoOperandLIRForm flag is true to move the address to be marked in the card table to a temporary register.
>> __ move(addr, tmp);
> However, this code only guarantees that `addr` is a valid register for LIR, which can be a virtual register. If the virtual register for `addr` is spilled to the stack by chance, the `move(addr, tmp)` is compiled to a memory-to-register which causes an assertion failure because a memory-to-register move requires their arguments to have the same size. 
> The fix is to check if it is is_oop() and call the mov appropriately.
> 
> No issues found in local testing and Mach5 tier1-3

This pull request has now been integrated.

Changeset: a58cf165
Author:    Fairoz Matte <fmatte at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a58cf16509f3120d69fc18bd4c2c49e9ad590f73
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8272563: assert(is_double_stack() && !is_virtual()) failed: type check

Reviewed-by: thartmann, iveresov

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

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


From tschatzl at openjdk.java.net  Wed Sep  1 14:21:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Sep 2021 14:21:53 GMT
Subject: RFR: 8273221: Guard GCIdMark against nested calls
In-Reply-To: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>
References: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>
Message-ID: <Paa8_waYxDpq6H0w7R_hthz6-5Oucza4qxrO3D9mh30=.72ff9f33-34f2-47c3-b11d-5251a84fded8@github.com>

On Wed, 1 Sep 2021 08:23:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of forbidding nested GC ids.
> 
> Test: tier1-6

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep  1 15:13:21 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 1 Sep 2021 15:13:21 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap
Message-ID: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>

Hi all,

  can I have reviews for this change that moves the G1 young collection algorithm containing the collection part out of `G1CollectedHeap` into a new `G1YoungCollector` class.

This change is mostly limited to moving the young collection specific code out; data structures are mostly kept in `G1CollectedHeap` for one reason or another, most of the time just to decrease the amount of code changes.

That will be fixed by upcoming (smaller) changes.

Other random comments:
  * I am aware that the class forward definitions in `g1CollectedHeap.hpp` are unsorted, but they were already and I will fix that later.
  * there will be some cleanup of `G1CollecteHeap` interface: at the moment, to reduce changes, I moved only code that was easy to move, and added back-references to `G1CollectedHeap`. There is a large list of getters for those in `G1YoungCollector`. These will be investigated one by one whether they can be removed by moving other code to `G1YoungCollector`.
  * what I would like to move is at least data like the heap region attribute table, evacuation failure temporary information and others
  * some data will likely move from `G1CollectedHeap` to some class that contains long term state specific to the young collection (e.g. evacuation failure injector, evacuation failure final result?, _bytes_used_during_gc, _gc_timer_stw, _gc_tracer_stw, stw reference processor and related closures) 

So lots of changes ahead, but this is a significant first step to avoid me doing tricky merges over and over again.

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - Minor cleanup
 - Merge master

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

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


From mli at openjdk.java.net  Thu Sep  2 01:30:07 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 2 Sep 2021 01:30:07 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v2]
In-Reply-To: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
Message-ID: <lHjfMSoUDZHvILDlcWbLv7eFHJL6BBi80d3QLiPFDFI=.cfb49572-05ee-4b5a-b253-4ca1098a1f02@github.com>

> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

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

  Fix include order.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5325/files
  - new: https://git.openjdk.java.net/jdk/pull/5325/files/75a2cfeb..6989e6b2

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

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

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


From mli at openjdk.java.net  Thu Sep  2 01:30:09 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 2 Sep 2021 01:30:09 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v2]
In-Reply-To: <hYtL65O5fsyvzcMoYH4rcXO2fTM4QKE5TEGBjWDr7AE=.749ec5b2-44dd-44de-aa2d-cfb26b51d369@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
 <hYtL65O5fsyvzcMoYH4rcXO2fTM4QKE5TEGBjWDr7AE=.749ec5b2-44dd-44de-aa2d-cfb26b51d369@github.com>
Message-ID: <fecx1uXKkHnBrm_eT51fWi0yVdCIDYaVDtkkkt1AMeU=.b5c3ec4d-1499-4707-a1e9-63db713d2317@github.com>

On Wed, 1 Sep 2021 08:13:10 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Lgtm.
> 
> Note that because you were so fast posting this, I do not know what others think about the name change in this direction, but I think it's okay. Please wait for further feedback.

Sure, I will wait for a while before push.
Thanks for your reviews, @tschatzl @albertnetymk

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

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


From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 03:39:27 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 03:39:27 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
Message-ID: <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>

On Tue, 31 Aug 2021 13:27:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
>> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
>> 
>> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
>> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
>> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
>> 
>> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
>> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
>> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579
>
> I think forwardee installation is better done with `acq_rel`, given that two GC threads may try to install it, and the failing thread should consume/acquire the other forwardee. Not sure the `OrderAccess::release` provides the same semantics. I have updated #2496 with more discussion and implementation.

@shipilev Here is the specjbb2015 result. opt1 is `acq_rel`, opt2 is `OrderAccess::release`

baseline_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31247, max-jOPS = 30168, critical-jOPS = 20319
baseline_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 20986
baseline_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 30168, critical-jOPS = 21053
opt1_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29140, critical-jOPS = 16247
opt1_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29140, critical-jOPS = 18131
opt1_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29483, critical-jOPS = 15928
opt2_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32788, max-jOPS = 30168, critical-jOPS = 22622
opt2_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22462
opt2_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 33186, max-jOPS = 30168, critical-jOPS = 22845

It seems `OrderAccess::release` performs better than `acq_rel`.
I notice that you have implemented `acquire` in getting forwardee in https://github.com/openjdk/jdk/pull/2496/, so I guess the `acq` here in `acq_rel` of forwardee installation is redundant? Given the specjbb result, I prefer to use `OrderAccess::release` here in forwardee installation. It only serves as storestore barrier on AArch64 and it doesn't provide the same semantics as you have mentioned above about consume/acquire the other forwardee.

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

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


From github.com+7947546+tanghaoth90 at openjdk.java.net  Thu Sep  2 03:48:32 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Thu, 2 Sep 2021 03:48:32 GMT
Subject: RFR: 8273122: ZGC: Load forwarding entries without acquire
 semantics
In-Reply-To: <__3vd0zHPnyiWG9EX51xHkw1mQUeRvBY3iKgq6TwkJs=.0db5ad5d-f5d1-467b-bf42-739dc061c8cd@github.com>
References: <r6mfMSZPlJJXC0TyvRFfLXrGSYsRTLS0nwJ7XFG6xN8=.d2879052-3ee6-49bd-9bf9-dedf1b81093a@github.com>
 <3nrIWFtGqAtEPkMyhl-UzPzJak-RCDG7-b-Bn8OJ6ys=.2af5cf5c-dd8b-4210-96e6-abaf97f74179@github.com>
 <__3vd0zHPnyiWG9EX51xHkw1mQUeRvBY3iKgq6TwkJs=.0db5ad5d-f5d1-467b-bf42-739dc061c8cd@github.com>
Message-ID: <5ZBY04XMMGXfCQrH4ROWWCw7i-3x9_o0nquwa0e38Dc=.70c5e708-df1d-4998-b7a5-af7468f5ea5e@github.com>

On Tue, 31 Aug 2021 11:25:46 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> As far as I know, Hotspot does not consistently use C++ atomics, so whether the compiler implements consume-as-acquire or any other aspect of the C++ memory model not does not really matter. Consequently, the code is full of undefined data races as far as the compiler is concerned. Compiler writers are aware of that and generally avoid optimizations that would break this memory-model-in-a-library approach (although there is of course no language specification that actually guarantees this).
>> 
>> I think that historically, the approach has been that when compiler optimizations make things go wrong, some sort of compiler barrier is added to the code. I assume the same thing could be done to implement an approximation to consume semantics.
>
>> As far as I know, Hotspot does not consistently use C++ atomics, so whether the compiler implements consume-as-acquire or any other aspect of the C++ memory model not does not really matter. Consequently, the code is full of undefined data races as far as the compiler is concerned. Compiler writers are aware of that and generally avoid optimizations that would break this memory-model-in-a-library approach (although there is of course no language specification that actually guarantees this).
>> 
>> I think that historically, the approach has been that when compiler optimizations make things go wrong, some sort of compiler barrier is added to the code. I assume the same thing could be done to implement an approximation to consume semantics.
> 
> We have not had access to C++ atomics for a long time. It's only rather recently that we upgraded past C++11. So I don't think the question of consume or acquire is irrelevant. If consume was to magically do what we want, in a way that is more standards compliant, then it would be a compelling reason to start upgrading our atomics. Given of course, that consume actually does do something other than to just bind to acquire.

@fisk @shipilev @fweimer-rh Thanks for your suggestions!

`load_consume` is better while simple `load` cannot retain the dependency. However, `load_consume` is unrealistic for now.

> #2496 also tries to optimize the Shenandoah paths that are penalized by acquires unnecessarily: heap updates after relocations are done. Maybe a similar partial relaxation would be possible for ZGC, e.g. for concurrent mark that does fixups.

Yes. ZGC also does fixups duration mutator-only phase. I am going to try using `load_acquire` during relocation phase and using `load` after relocations.

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

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


From mli at openjdk.java.net  Thu Sep  2 06:21:31 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 2 Sep 2021 06:21:31 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v5]
In-Reply-To: <xxEiob0lrNMj00ko6TfHxPS7Qmh9PaJVloBPSSbyNQY=.1fff5f47-a7b9-4fb5-b83b-40756e547687@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <xxEiob0lrNMj00ko6TfHxPS7Qmh9PaJVloBPSSbyNQY=.1fff5f47-a7b9-4fb5-b83b-40756e547687@github.com>
Message-ID: <117xFml4BMG8xZfVI_TkPaMnGmeQumJf7UYgklPm1AA=.f270f4f6-8118-4900-be9f-8ba547ac00bc@github.com>

On Wed, 1 Sep 2021 03:40:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is another try to optimize evcuation failure for regions.
>> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
>> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
>> 
>> I have 2 implementations:
>> 
>> - 1) CHT (Initial version)
>> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
>> 
>> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
>> 
>> I will attach the perf data in JBS.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modify as review comments suggested.

The rerun of presubmit test show that it passed all tests, except of java/util/regex/NegativeArraySize.java which I think it's irrelevant to this patch, as I saw it in several different pr.
latest presumt test result is here: https://github.com/Hamlin-Li/jdk/actions/runs/1188690717

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

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


From github.com+10835776+stsypanov at openjdk.java.net  Thu Sep  2 08:13:37 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 2 Sep 2021 08:13:37 GMT
Subject: Integrated: 8273140: Replace usages of Enum.class.getEnumConstants()
 with Enum.values() where possible
In-Reply-To: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com>
References: <4N-BgoVLVgZk_uPkRLoY-427bF-kKKwDr1zRHI7o1PI=.dcdbec6e-f3f8-48e4-94ce-a88d7e494c41@github.com>
Message-ID: <43jcu3pT9PMTk266WJaSVQ_4Yyv1FV3rhR6efbpxjPA=.5e1cec47-2d47-4b27-a5a6-8e6cd2467b48@github.com>

On Mon, 30 Aug 2021 14:26:56 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Just a very tiny clean-up.
> 
> There are some places in JDK code base where we call `Enum.class.getEnumConstants()` to get all the values of the referenced `enum`. This is excessive, less-readable and slower than just calling `Enum.values()` as in `getEnumConstants()` we have volatile access:
> 
> public T[] getEnumConstants() {
>     T[] values = getEnumConstantsShared();
>     return (values != null) ? values.clone() : null;
> }
> 
> private transient volatile T[] enumConstants;
> 
> T[] getEnumConstantsShared() {
>     T[] constants = enumConstants;
>     if (constants == null) { /* ... */ }
>     return constants;
> }
> 
> Calling values() method is slightly faster:
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class EnumBenchmark {
> 
>   @Benchmark
>   public Enum[] values() {
>     return Enum.values();
>   }
> 
>   @Benchmark
>   public Enum[] getEnumConstants() {
>     return Enum.class.getEnumConstants();
>   }
> 
>   private enum Enum {
>     A,
>     B
>   }
> }
> 
> 
> Benchmark                                                        Mode  Cnt     Score     Error   Units
> EnumBenchmark.getEnumConstants                                   avgt   15     6,265 ?   0,051   ns/op
> EnumBenchmark.getEnumConstants:?gc.alloc.rate                    avgt   15  2434,075 ?  19,568  MB/sec
> EnumBenchmark.getEnumConstants:?gc.alloc.rate.norm               avgt   15    24,002 ?   0,001    B/op
> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space           avgt   15  2433,709 ?  70,216  MB/sec
> EnumBenchmark.getEnumConstants:?gc.churn.G1_Eden_Space.norm      avgt   15    23,998 ?   0,659    B/op
> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space       avgt   15     0,009 ?   0,003  MB/sec
> EnumBenchmark.getEnumConstants:?gc.churn.G1_Survivor_Space.norm  avgt   15    ? 10??              B/op
> EnumBenchmark.getEnumConstants:?gc.count                         avgt   15   210,000            counts
> EnumBenchmark.getEnumConstants:?gc.time                          avgt   15   119,000                ms
> 
> EnumBenchmark.values                                             avgt   15     4,164 ?   0,134   ns/op
> EnumBenchmark.values:?gc.alloc.rate                              avgt   15  3665,341 ? 120,721  MB/sec
> EnumBenchmark.values:?gc.alloc.rate.norm                         avgt   15    24,002 ?   0,001    B/op
> EnumBenchmark.values:?gc.churn.G1_Eden_Space                     avgt   15  3660,512 ? 137,250  MB/sec
> EnumBenchmark.values:?gc.churn.G1_Eden_Space.norm                avgt   15    23,972 ?   0,529    B/op
> EnumBenchmark.values:?gc.churn.G1_Survivor_Space                 avgt   15     0,017 ?   0,003  MB/sec
> EnumBenchmark.values:?gc.churn.G1_Survivor_Space.norm            avgt   15    ? 10??              B/op
> EnumBenchmark.values:?gc.count                                   avgt   15   262,000            counts
> EnumBenchmark.values:?gc.time                                    avgt   15   155,000                ms

This pull request has now been integrated.

Changeset: 152e6692
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/152e66923dc36cfd83cdfe18e96631abc06b9199
Stats:     13 lines in 4 files changed: 0 ins; 2 del; 11 mod

8273140: Replace usages of Enum.class.getEnumConstants() with Enum.values() where possible

Reviewed-by: tschatzl

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

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


From tschatzl at openjdk.java.net  Thu Sep  2 08:14:31 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 2 Sep 2021 08:14:31 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v4]
In-Reply-To: <EUHQu1ZbcwoWw7NxgC42PZdIf_OnC0ZKUydlDHThxpg=.6697ae7f-0809-409b-8070-9c5d1c8ec8d9@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <2rdaiC7TDwMQiq035XVEhD0kbYXiOc9EL3ZxogYI21o=.b1965f40-0ac7-4f2c-aec5-07bf2207d583@github.com>
 <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
 <EUHQu1ZbcwoWw7NxgC42PZdIf_OnC0ZKUydlDHThxpg=.6697ae7f-0809-409b-8070-9c5d1c8ec8d9@github.com>
Message-ID: <P56wjMFPaL2GtSNBBJANjIOrGa4oRwVI6h4q1Y1wF7c=.292cc936-4873-409c-8f8c-6c2548863a8d@github.com>

On Wed, 1 Sep 2021 03:15:42 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1EvacuationFailureRegions.cpp line 51:
>> 
>>> 49:                                              HeapRegionClaimer* _hrclaimer,
>>> 50:                                              uint worker_id) {
>>> 51:   assert_at_safepoint();
>> 
>> As far as I can see this is a verbatim copy of `G1CollectionSet::iterate_part_from` (with some minor simplifications). Not really happy about that, need to think more about how/if we can avoid this.
>
> Agree. I think the reason is that we have mixed iteration itself with the logic in hrm/cset/evac failure regions.
> One option to do might be to extract the iteration logic separately, should we do this in a separate issue?

Either that, or provide a data structure that encapsulates an array that items can be atomically added to including the iteration.

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

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


From ayang at openjdk.java.net  Thu Sep  2 09:43:54 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 2 Sep 2021 09:43:54 GMT
Subject: RFR: 8273147: Update and restructure TestGCLogMessages log
 message list [v4]
In-Reply-To: <Nl4Crn30rNXTselMsVPFKhh1ImOxLsKq7yblkx3zcEw=.986dce5c-961c-4dc4-94a7-e1b00ddac6a0@github.com>
References: <lxyi0RI0eWFoQRbskn2kZTZUx-SxkeW-z7AHca4r03g=.32e098f8-1927-4195-a1ae-1c3ae65f3584@github.com>
 <Nl4Crn30rNXTselMsVPFKhh1ImOxLsKq7yblkx3zcEw=.986dce5c-961c-4dc4-94a7-e1b00ddac6a0@github.com>
Message-ID: <M8zR0bsSimTOq91Xyf0nnLi2ubyNQy3lvgS6hY4T0Jg=.042a75a7-8116-4a33-8a87-43f2e9bafbc5@github.com>

On Thu, 2 Sep 2021 09:40:54 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that updates the TestGCLogMessages file for more or less recently added log messages.
>> 
>> Test: executing test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move ext root scan subphases to proper location

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Sep  2 09:43:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 2 Sep 2021 09:43:53 GMT
Subject: RFR: 8273147: Update and restructure TestGCLogMessages log
 message list [v4]
In-Reply-To: <lxyi0RI0eWFoQRbskn2kZTZUx-SxkeW-z7AHca4r03g=.32e098f8-1927-4195-a1ae-1c3ae65f3584@github.com>
References: <lxyi0RI0eWFoQRbskn2kZTZUx-SxkeW-z7AHca4r03g=.32e098f8-1927-4195-a1ae-1c3ae65f3584@github.com>
Message-ID: <Nl4Crn30rNXTselMsVPFKhh1ImOxLsKq7yblkx3zcEw=.986dce5c-961c-4dc4-94a7-e1b00ddac6a0@github.com>

> Hi all,
> 
>   please review this change that updates the TestGCLogMessages file for more or less recently added log messages.
> 
> Test: executing test case
> 
> Thanks,
>   Thomas

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

  Move ext root scan subphases to proper location

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5306/files
  - new: https://git.openjdk.java.net/jdk/pull/5306/files/a8f27ca1..59fccb02

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

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

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


From tschatzl at openjdk.java.net  Thu Sep  2 12:01:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 2 Sep 2021 12:01:33 GMT
Subject: RFR: 8273147: Update and restructure TestGCLogMessages log
 message list [v4]
In-Reply-To: <M8zR0bsSimTOq91Xyf0nnLi2ubyNQy3lvgS6hY4T0Jg=.042a75a7-8116-4a33-8a87-43f2e9bafbc5@github.com>
References: <lxyi0RI0eWFoQRbskn2kZTZUx-SxkeW-z7AHca4r03g=.32e098f8-1927-4195-a1ae-1c3ae65f3584@github.com>
 <Nl4Crn30rNXTselMsVPFKhh1ImOxLsKq7yblkx3zcEw=.986dce5c-961c-4dc4-94a7-e1b00ddac6a0@github.com>
 <M8zR0bsSimTOq91Xyf0nnLi2ubyNQy3lvgS6hY4T0Jg=.042a75a7-8116-4a33-8a87-43f2e9bafbc5@github.com>
Message-ID: <bMWe9aONWJXR8VoRBEg1MtkzTpKCwWWzZVq414zhOE8=.25a7aaea-f3de-48b2-b99e-6c64994c99e2@github.com>

On Thu, 2 Sep 2021 09:39:08 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:
>> 
>>   Move ext root scan subphases to proper location
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @walulyai for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Sep  2 12:01:35 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 2 Sep 2021 12:01:35 GMT
Subject: Integrated: 8273147: Update and restructure TestGCLogMessages log
 message list
In-Reply-To: <lxyi0RI0eWFoQRbskn2kZTZUx-SxkeW-z7AHca4r03g=.32e098f8-1927-4195-a1ae-1c3ae65f3584@github.com>
References: <lxyi0RI0eWFoQRbskn2kZTZUx-SxkeW-z7AHca4r03g=.32e098f8-1927-4195-a1ae-1c3ae65f3584@github.com>
Message-ID: <szVnvRLv6RIXn5zuDbUf7UnIhkzaMusABlQJlBptj3U=.ab9c7b19-fa7a-4560-a028-9e8e14f54988@github.com>

On Mon, 30 Aug 2021 17:01:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that updates the TestGCLogMessages file for more or less recently added log messages.
> 
> Test: executing test case
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 5245c1cf
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5245c1cf0260a78ca5f8ab4e7d13107f21faf071
Stats:     82 lines in 1 file changed: 47 ins; 28 del; 7 mod

8273147: Update and restructure TestGCLogMessages log message list

Reviewed-by: iwalulya, ayang

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

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


From mli at openjdk.java.net  Thu Sep  2 12:39:31 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 2 Sep 2021 12:39:31 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v4]
In-Reply-To: <P56wjMFPaL2GtSNBBJANjIOrGa4oRwVI6h4q1Y1wF7c=.292cc936-4873-409c-8f8c-6c2548863a8d@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <2rdaiC7TDwMQiq035XVEhD0kbYXiOc9EL3ZxogYI21o=.b1965f40-0ac7-4f2c-aec5-07bf2207d583@github.com>
 <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
 <EUHQu1ZbcwoWw7NxgC42PZdIf_OnC0ZKUydlDHThxpg=.6697ae7f-0809-409b-8070-9c5d1c8ec8d9@github.com>
 <P56wjMFPaL2GtSNBBJANjIOrGa4oRwVI6h4q1Y1wF7c=.292cc936-4873-409c-8f8c-6c2548863a8d@github.com>
Message-ID: <ltsZXPVVxRNyQ1IoCki7Vk7bu-bFjALNTJKhKmj87Wg=.29585dde-4a40-4d1f-89db-22ca9e78a9b3@github.com>

On Thu, 2 Sep 2021 08:11:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Agree. I think the reason is that we have mixed iteration itself with the logic in hrm/cset/evac failure regions.
>> One option to do might be to extract the iteration logic separately, should we do this in a separate issue?
>
> Either that, or provide a data structure that encapsulates an array that items can be atomically added to including the iteration.

Do you mean to just do some refactoring for G1EvacuationFailureRegions or for hrm/cset together?

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

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


From tschatzl at openjdk.java.net  Thu Sep  2 13:25:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 2 Sep 2021 13:25:38 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v4]
In-Reply-To: <ltsZXPVVxRNyQ1IoCki7Vk7bu-bFjALNTJKhKmj87Wg=.29585dde-4a40-4d1f-89db-22ca9e78a9b3@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <2rdaiC7TDwMQiq035XVEhD0kbYXiOc9EL3ZxogYI21o=.b1965f40-0ac7-4f2c-aec5-07bf2207d583@github.com>
 <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
 <EUHQu1ZbcwoWw7NxgC42PZdIf_OnC0ZKUydlDHThxpg=.6697ae7f-0809-409b-8070-9c5d1c8ec8d9@github.com>
 <P56wjMFPaL2GtSNBBJANjIOrGa4oRwVI6h4q1Y1wF7c=.292cc936-4873-409c-8f8c-6c2548863a8d@github.com>
 <ltsZXPVVxRNyQ1IoCki7Vk7bu-bFjALNTJKhKmj87Wg=.29585dde-4a40-4d1f-89db-22ca9e78a9b3@github.com>
Message-ID: <h4zl4ncKpNCRhGNEj74l_w3gVBD7-ZUupYuN37kllqc=.682ef31d-ac07-47d8-a084-2ff9db3ec8ff@github.com>

On Thu, 2 Sep 2021 11:08:51 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Either that, or provide a data structure that encapsulates an array that items can be atomically added to including the iteration.
>
> Do you mean to just do some refactoring for G1EvacuationFailureRegions or for hrm/cset together?

Actually, the collection set does not need the atomicity of addition to the array. So, probably it's best for this change to factor out the iteration over an array of heap region indexes into a `G1CollectedHeap`(probably the best place for now?) method which you pass the array information too - to be used in both places.

There is imho no point in delaying this into a separate CR, it's just one method and two uses afaict.

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

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


From ayang at openjdk.java.net  Thu Sep  2 14:24:06 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 2 Sep 2021 14:24:06 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap
In-Reply-To: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
Message-ID: <06wZ6VhLFjs7oKe50UxpxhA95Ec1as4z3UfdgX8WYrk=.6d2d6e78-72ff-46c1-8c50-d5d549f99dcd@github.com>

On Wed, 1 Sep 2021 14:53:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves the G1 young collection algorithm containing the collection part out of `G1CollectedHeap` into a new `G1YoungCollector` class.
> 
> This change is mostly limited to moving the young collection specific code out; data structures are mostly kept in `G1CollectedHeap` for one reason or another, most of the time just to decrease the amount of code changes.
> 
> That will be fixed by upcoming (smaller) changes.
> 
> Other random comments:
>   * I am aware that the class forward definitions in `g1CollectedHeap.hpp` are unsorted, but they were already and I will fix that later.
>   * there will be some cleanup of `G1CollecteHeap` interface: at the moment, to reduce changes, I moved only code that was easy to move, and added back-references to `G1CollectedHeap`. There is a large list of getters for those in `G1YoungCollector`. These will be investigated one by one whether they can be removed by moving other code to `G1YoungCollector`.
>   * what I would like to move is at least data like the heap region attribute table, evacuation failure temporary information and others
>   * some data will likely move from `G1CollectedHeap` to some class that contains long term state specific to the young collection (e.g. evacuation failure injector, evacuation failure final result?, _bytes_used_during_gc, _gc_timer_stw, _gc_tracer_stw, stw reference processor and related closures) 
> 
> So lots of changes ahead, but this is a significant first step to avoid me doing tricky merges over and over again.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From shade at openjdk.java.net  Thu Sep  2 16:40:21 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 16:40:21 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
 <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>
Message-ID: <asVE-SiNkfTBH-YeXdjTk6vitxcmI02jFcpncwrMqSg=.d50837af-c07f-465a-b39d-d1c92a6e8eb3@github.com>

On Thu, 2 Sep 2021 03:36:05 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> It seems `OrderAccess::release` performs better than `acq_rel`.

Interesting result, thanks. I think that's because on current ARM 8.2 `acq_rel` is effectively `seq_cst`, which is stronger than `release`. ARM 8.3 introduces the RCpc atomics that are weaker, but we are not there yet. Anyhow, in #2496, I tried to do the acquire conditionally now, leaving only `release` CAS to hopefully avoid this pitfall.

I also think that PR now subsumes this one: it does conditionally relaxed heap updates, while leaving "release" for self-healing paths that might run concurrently during evacuation. Would you mind testing #2496 instead? Maybe also #2496 + `OrderAccess::release` variant to see if we even need it now performance-wise? If you agree, I would suggest closing this PR and moving the rest of the work under #2496.

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

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


From mli at openjdk.java.net  Fri Sep  3 03:19:57 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 3 Sep 2021 03:19:57 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v6]
In-Reply-To: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
Message-ID: <U_gXtDrBvjjrvcCMj52DnKG-gLb72WXEtTMop1nfk4s=.1d76982f-3721-4313-bd40-4aeb393fe4c0@github.com>

> This is another try to optimize evcuation failure for regions.
> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
> 
> I have 2 implementations:
> 
> - 1) CHT (Initial version)
> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
> 
> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
> 
> I will attach the perf data in JBS.

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

  Refactor par iteration for regions of cset and evac failure.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5272/files
  - new: https://git.openjdk.java.net/jdk/pull/5272/files/7fa8496d..3b5543f5

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

  Stats: 98 lines in 5 files changed: 39 ins; 42 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5272/head:pull/5272

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


From mli at openjdk.java.net  Fri Sep  3 03:19:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 3 Sep 2021 03:19:59 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v4]
In-Reply-To: <h4zl4ncKpNCRhGNEj74l_w3gVBD7-ZUupYuN37kllqc=.682ef31d-ac07-47d8-a084-2ff9db3ec8ff@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <2rdaiC7TDwMQiq035XVEhD0kbYXiOc9EL3ZxogYI21o=.b1965f40-0ac7-4f2c-aec5-07bf2207d583@github.com>
 <Ryt75yHGUjSj8kv03b9UObpfApuKmkeurpDtXmMYRqM=.d7c701aa-a38e-48cf-af1f-3e81428b660f@github.com>
 <EUHQu1ZbcwoWw7NxgC42PZdIf_OnC0ZKUydlDHThxpg=.6697ae7f-0809-409b-8070-9c5d1c8ec8d9@github.com>
 <P56wjMFPaL2GtSNBBJANjIOrGa4oRwVI6h4q1Y1wF7c=.292cc936-4873-409c-8f8c-6c2548863a8d@github.com>
 <ltsZXPVVxRNyQ1IoCki7Vk7bu-bFjALNTJKhKmj87Wg=.29585dde-4a40-4d1f-89db-22ca9e78a9b3@github.com>
 <h4zl4ncKpNCRhGNEj74l_w3gVBD7-ZUupYuN37kllqc=.682ef31d-ac07-47d8-a084-2ff9db3ec8ff@github.com>
Message-ID: <zl7GY3QNYQ87Z6gUGgD9gyetgH456DIyg2NSRLlyknc=.dfb25f66-0e55-4a4c-9db0-6ec4ab94f02b@github.com>

On Thu, 2 Sep 2021 13:22:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Do you mean to just do some refactoring for G1EvacuationFailureRegions or for hrm/cset together?
>
> Actually, the collection set does not need the atomicity of addition to the array. So, probably it's best for this change to factor out the iteration over an array of heap region indexes into a `G1CollectedHeap`(probably the best place for now?) method which you pass the array information too - to be used in both places.
> 
> There is imho no point in delaying this into a separate CR, it's just one method and two uses afaict.

I see your point. 
Did a very simple refactoring to move the iteration from G1CollectionSet  to G1CollectedHeap, and reuse this in both G1CollectionSet  and G1EvacFailureRegions.

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

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


From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 03:41:31 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 03:41:31 GMT
Subject: Withdrawn: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
Message-ID: <hq4bwAmuK2SgV0we1uGgUy7vvu-hI-ZPPT8_Uihu87o=.0828b06d-9b69-4aff-95d8-f5a7a63b4be0@github.com>

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

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

This pull request has been closed without being integrated.

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

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


From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 03:41:31 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 03:41:31 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <asVE-SiNkfTBH-YeXdjTk6vitxcmI02jFcpncwrMqSg=.d50837af-c07f-465a-b39d-d1c92a6e8eb3@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>
 <H-llh1pgmF6hXnWPD4q1xSp3Bbr81htoksTD2g-oQb0=.70888aa7-0ac3-402e-a306-32599a9bddd8@github.com>
 <asVE-SiNkfTBH-YeXdjTk6vitxcmI02jFcpncwrMqSg=.d50837af-c07f-465a-b39d-d1c92a6e8eb3@github.com>
Message-ID: <A8Q2PA-MpNg7cYcWKTRby8ihioeGzeeFmO5PJp9-2UY=.6db8881d-39b6-4487-bd9e-683dfa7fdce5@github.com>

On Thu, 2 Sep 2021 16:28:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev Here is the specjbb2015 result. opt1 is `acq_rel`, opt2 is `OrderAccess::release`
>> 
>> baseline_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31247, max-jOPS = 30168, critical-jOPS = 20319
>> baseline_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29825, critical-jOPS = 20986
>> baseline_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 30168, critical-jOPS = 21053
>> opt1_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29140, critical-jOPS = 16247
>> opt1_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32419, max-jOPS = 29140, critical-jOPS = 18131
>> opt1_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29483, critical-jOPS = 15928
>> opt2_1:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 32788, max-jOPS = 30168, critical-jOPS = 22622
>> opt2_2:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 31780, max-jOPS = 29825, critical-jOPS = 22462
>> opt2_3:RUN RESULT: hbIR (max attempted) = 34282, hbIR (settled) = 33186, max-jOPS = 30168, critical-jOPS = 22845
>> 
>> It seems `OrderAccess::release` performs better than `acq_rel`.
>> I notice that you have implemented `acquire` in getting forwardee in https://github.com/openjdk/jdk/pull/2496/, so I guess the `acq` here in `acq_rel` of forwardee installation is redundant? Given the specjbb result, I prefer to use `OrderAccess::release` here in forwardee installation. It only serves as storestore barrier on AArch64 and it doesn't provide the same semantics as you have mentioned above about consume/acquire the other forwardee.
>
>> It seems `OrderAccess::release` performs better than `acq_rel`.
> 
> Interesting result, thanks. I think that's because on current ARM 8.2 `acq_rel` is effectively `seq_cst`, which is stronger than `release`. ARM 8.3 introduces the RCpc atomics that are weaker, but we are not there yet. Anyhow, in #2496, I tried to do the acquire conditionally now, leaving only `release` CAS to hopefully avoid this pitfall.
> 
> I also think that PR now subsumes this one: it does conditionally relaxed heap updates, while leaving "release" for self-healing paths that might run concurrently during evacuation. Would you mind testing #2496 instead? Maybe also #2496 + `OrderAccess::release` variant to see if we even need it now performance-wise? If you agree, I would suggest closing this PR and moving the rest of the work under #2496.

@shipilev Sure, let's discuss under https://github.com/openjdk/jdk/pull/2496 and I will try testing its performance. Thanks for your suggestions.

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

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


From github.com+3094961+buddyliao at openjdk.java.net  Fri Sep  3 04:04:29 2021
From: github.com+3094961+buddyliao at openjdk.java.net (Bin Liao)
Date: Fri, 3 Sep 2021 04:04:29 GMT
Subject: RFR: 8272611: Use parallel heap inspection when print classhisto
 info in gc log [v3]
In-Reply-To: <eX_HSdayvyeX3fovv7kM_8ajuPPjiMRCVRz3Z80B2Ns=.996b2b8a-b6d0-4454-b766-8e968786d968@github.com>
References: <eX_HSdayvyeX3fovv7kM_8ajuPPjiMRCVRz3Z80B2Ns=.996b2b8a-b6d0-4454-b766-8e968786d968@github.com>
Message-ID: <o8fu4Bgi34vSArzRDL7MS5bnwqC7tzsyLHaYZu3h3J4=.212db499-a893-46c5-af37-12b3f73828dd@github.com>

> This patch helps to enhance the heap inspection with parallel threads when print classhisto info in gc log.
> 
> I have built it on linux x86_64 and run test-tier1 successfully
> 
> ---------
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> 
> 
> ### Reviewing
> <details><summary>Using <code>git</code></summary>
> 
> Checkout this PR locally: \
> `$ git fetch https://git.openjdk.java.net/jdk pull/5158/head:pull/5158` \
> `$ git checkout pull/5158`
> 
> Update a local copy of the PR: \
> `$ git checkout pull/5158` \
> `$ git pull https://git.openjdk.java.net/jdk pull/5158/head`
> 
> </details>
> <details><summary>Using Skara CLI tools</summary>
> 
> Checkout this PR locally: \
> `$ git pr checkout 5158`
> 
> View PR using the GUI difftool: \
> `$ git pr show -t 5158`
> 
> </details>
> <details><summary>Using diff file</summary>
> 
> Download this PR as a diff file: \
> <a href="https://git.openjdk.java.net/jdk/pull/5158.diff">https://git.openjdk.java.net/jdk/pull/5158.diff</a>
> 
> </details>

Bin Liao has updated the pull request incrementally with one additional commit since the last revision:

  8272611: change heapInspection thread num in ClassHistogramDCmd::execute

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5158/files
  - new: https://git.openjdk.java.net/jdk/pull/5158/files/6ae1b554..fa7dbc32

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

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

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


From ayang at openjdk.java.net  Fri Sep  3 12:03:22 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 3 Sep 2021 12:03:22 GMT
Subject: RFR: 8272985: Reference discovery is confused about atomicity and
 degree of parallelism [v2]
In-Reply-To: <brhgr3tyJkRDOqbjArnRZwS52lIla5rm2UO46VEgsJc=.01d65a93-f851-420a-b7f7-6795561dd595@github.com>
References: <yDky4mUCs7e-4DvDO3D7r8UT1HxBnDx2U2xJBOrd-G8=.b9c6add3-1cd6-4ebf-ab8d-b19e2c96ef2c@github.com>
 <brhgr3tyJkRDOqbjArnRZwS52lIla5rm2UO46VEgsJc=.01d65a93-f851-420a-b7f7-6795561dd595@github.com>
Message-ID: <0iJG8TDLg8VURVEDRktSX90FvnPoMEDHjK1HUbEjkCQ=.4d673ccc-c40f-4032-b9fe-ee3a816ea683@github.com>

On Tue, 31 Aug 2021 11:36:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes some (apparent) confusion between atomicity (of the discovery in the `ReferenceProcessor` sense) vs. the currently selected degree of parallelism?
>> 
>> For all four different combinations of atomicity and parallelism the `discovered` link in the `java.lang.ref.Reference` needs to be updated differently using a different kind of access, instead of just two based on atomicity.
>> 
>> I'll fix the use of `atomic` in `ReferenceProcessor` in a separate CR to hopefully remove the confusion for the reader too.
>> 
>> Testing: tier1-5, internal perf benchmarks without regressions
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some more refactorng

Marked as reviewed by ayang (Reviewer).

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

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


From kbarrett at openjdk.java.net  Fri Sep  3 15:38:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 3 Sep 2021 15:38:28 GMT
Subject: RFR: 8272905: Consolidate discovered lists processing [v2]
In-Reply-To: <jTE90-ZfY8y3Wc0TYfwfaVENSjBN3H-1QSschN5BtYc=.bd433389-52b1-4bfe-84c9-e91f80169d84@github.com>
References: <-BaizreVcGJ9jz4D2W5ETKOW93gquYosYjmOayyRmX8=.6c21108b-7ce0-4270-b4c1-10d16928dea9@github.com>
 <jTE90-ZfY8y3Wc0TYfwfaVENSjBN3H-1QSschN5BtYc=.bd433389-52b1-4bfe-84c9-e91f80169d84@github.com>
Message-ID: <vx0DF8u-ntBWwPq0cZSiaFkto6brq9aXwrrx8SKrxRg=.6afba71e-8015-4a8e-b1a9-aa82bae6fe1c@github.com>

On Tue, 31 Aug 2021 14:11:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging discovered list processing for four kinds of non-strong refs and some general cleanup around.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.  Just a couple very minor nits.  I re-examined the discussion and change for JDK-8202845 as part of examining this.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 427:

> 425:   ReferenceProcessor::RefProcSubPhases subphase;
> 426:   DiscoveredList* dl;
> 427:   switch(ref_type) {

Missing space after "switch" per style guide.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 448:

> 446:   }
> 447: 
> 448:   // Only Final refs are not enqueued.

s/enqueued./enqueued and cleared here./

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Fri Sep  3 16:13:03 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 3 Sep 2021 16:13:03 GMT
Subject: RFR: 8272905: Consolidate discovered lists processing [v3]
In-Reply-To: <-BaizreVcGJ9jz4D2W5ETKOW93gquYosYjmOayyRmX8=.6c21108b-7ce0-4270-b4c1-10d16928dea9@github.com>
References: <-BaizreVcGJ9jz4D2W5ETKOW93gquYosYjmOayyRmX8=.6c21108b-7ce0-4270-b4c1-10d16928dea9@github.com>
Message-ID: <E6QMw6UsaBERVHnhm5hpokYv_VBc52ryE16uXie4Nag=.58eedbb4-1ad8-4b53-bddb-3f504284e367@github.com>

> Simple change of merging discovered list processing for four kinds of non-strong refs and some general cleanup around.
> 
> Test: tier1-3

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/5242/files
  - new: https://git.openjdk.java.net/jdk/pull/5242/files/3650b5d6..dbbfff4d

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

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

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


From ayang at openjdk.java.net  Fri Sep  3 16:56:30 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 3 Sep 2021 16:56:30 GMT
Subject: RFR: 8272905: Consolidate discovered lists processing [v3]
In-Reply-To: <E6QMw6UsaBERVHnhm5hpokYv_VBc52ryE16uXie4Nag=.58eedbb4-1ad8-4b53-bddb-3f504284e367@github.com>
References: <-BaizreVcGJ9jz4D2W5ETKOW93gquYosYjmOayyRmX8=.6c21108b-7ce0-4270-b4c1-10d16928dea9@github.com>
 <E6QMw6UsaBERVHnhm5hpokYv_VBc52ryE16uXie4Nag=.58eedbb4-1ad8-4b53-bddb-3f504284e367@github.com>
Message-ID: <dgkraBzDKwLu2wrR2LuM-X19rL-LBRWNVD4nNJMPsXQ=.6c24a34a-8530-47ae-9796-983c74d5423b@github.com>

On Fri, 3 Sep 2021 16:13:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging discovered list processing for four kinds of non-strong refs and some general cleanup around.
>> 
>> Test: tier1-3
>
> 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/5242


From ayang at openjdk.java.net  Fri Sep  3 16:56:31 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 3 Sep 2021 16:56:31 GMT
Subject: Integrated: 8272905: Consolidate discovered lists processing
In-Reply-To: <-BaizreVcGJ9jz4D2W5ETKOW93gquYosYjmOayyRmX8=.6c21108b-7ce0-4270-b4c1-10d16928dea9@github.com>
References: <-BaizreVcGJ9jz4D2W5ETKOW93gquYosYjmOayyRmX8=.6c21108b-7ce0-4270-b4c1-10d16928dea9@github.com>
Message-ID: <ZIotZfZXPtzvW3otNkkdW_Y6ddzMtopLgar2PsJryGE=.9378f5d5-b455-4d57-9882-6d683d959e14@github.com>

On Tue, 24 Aug 2021 17:50:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging discovered list processing for four kinds of non-strong refs and some general cleanup around.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: 23fa0dcf
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23fa0dcff062803d249c863b90a00744e3477656
Stats:     121 lines in 3 files changed: 38 ins; 51 del; 32 mod

8272905: Consolidate discovered lists processing

Reviewed-by: tschatzl, kbarrett

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

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


From kbarrett at openjdk.java.net  Fri Sep  3 20:55:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 3 Sep 2021 20:55:07 GMT
Subject: RFR: 8272985: Reference discovery is confused about atomicity and
 degree of parallelism [v2]
In-Reply-To: <brhgr3tyJkRDOqbjArnRZwS52lIla5rm2UO46VEgsJc=.01d65a93-f851-420a-b7f7-6795561dd595@github.com>
References: <yDky4mUCs7e-4DvDO3D7r8UT1HxBnDx2U2xJBOrd-G8=.b9c6add3-1cd6-4ebf-ab8d-b19e2c96ef2c@github.com>
 <brhgr3tyJkRDOqbjArnRZwS52lIla5rm2UO46VEgsJc=.01d65a93-f851-420a-b7f7-6795561dd595@github.com>
Message-ID: <TWWOe4wzf0tlLjfrN43CK3fq0Ko6oDZM5qCtVSBr3LQ=.06a26305-5efc-4923-b9c0-f871f5dc7cb0@github.com>

On Tue, 31 Aug 2021 11:36:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that fixes some (apparent) confusion between atomicity (of the discovery in the `ReferenceProcessor` sense) vs. the currently selected degree of parallelism?
>> 
>> For all four different combinations of atomicity and parallelism the `discovered` link in the `java.lang.ref.Reference` needs to be updated differently using a different kind of access, instead of just two based on atomicity.
>> 
>> I'll fix the use of `atomic` in `ReferenceProcessor` in a separate CR to hopefully remove the confusion for the reader too.
>> 
>> Testing: tier1-5, internal perf benchmarks without regressions
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some more refactorng

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Fri Sep  3 20:58:13 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 3 Sep 2021 20:58:13 GMT
Subject: RFR: 8273221: Guard GCIdMark against nested calls
In-Reply-To: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>
References: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>
Message-ID: <Ds9rCi9z43SicJR0CJObPzEIkixL_RRKA1QDYrPSr6s=.1269eb96-9335-4064-8daf-23d69bce3aa8@github.com>

On Wed, 1 Sep 2021 08:23:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of forbidding nested GC ids.
> 
> Test: tier1-6

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Mon Sep  6 02:08:49 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 6 Sep 2021 02:08:49 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap
In-Reply-To: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
Message-ID: <0PR4__XoTpuaJSa462nv7Jit9z0Bf2lisasrk2KK1Ho=.06a58412-7fc4-40df-8e4d-d803b1370bbe@github.com>

On Wed, 1 Sep 2021 14:53:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves the G1 young collection algorithm containing the collection part out of `G1CollectedHeap` into a new `G1YoungCollector` class.
> 
> This change is mostly limited to moving the young collection specific code out; data structures are mostly kept in `G1CollectedHeap` for one reason or another, most of the time just to decrease the amount of code changes.
> 
> That will be fixed by upcoming (smaller) changes.
> 
> Other random comments:
>   * I am aware that the class forward definitions in `g1CollectedHeap.hpp` are unsorted, but they were already and I will fix that later.
>   * there will be some cleanup of `G1CollecteHeap` interface: at the moment, to reduce changes, I moved only code that was easy to move, and added back-references to `G1CollectedHeap`. There is a large list of getters for those in `G1YoungCollector`. These will be investigated one by one whether they can be removed by moving other code to `G1YoungCollector`.
>   * what I would like to move is at least data like the heap region attribute table, evacuation failure temporary information and others
>   * some data will likely move from `G1CollectedHeap` to some class that contains long term state specific to the young collection (e.g. evacuation failure injector, evacuation failure final result?, _bytes_used_during_gc, _gc_timer_stw, _gc_tracer_stw, stw reference processor and related closures) 
> 
> So lots of changes ahead, but this is a significant first step to avoid me doing tricky merges over and over again.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Seems g1YoungCollector.inline.hpp is an empty file and not referenced anywhere.

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

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


From ayang at openjdk.java.net  Mon Sep  6 08:14:11 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 6 Sep 2021 08:14:11 GMT
Subject: Integrated: 8273221: Guard GCIdMark against nested calls
In-Reply-To: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>
References: <Tzs7IuIN5sBCpcTANeTxr_gMnMPZUSgKxFVhHZILS-A=.40a27399-848a-4323-935e-f0759e4dd2fb@github.com>
Message-ID: <Z4KNn-mPsKbwBT2HsQ8bGSfv5o48RYTv-xC37VRZR28=.05a64c20-1358-4118-a84f-f35f4de9dd8f@github.com>

On Wed, 1 Sep 2021 08:23:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of forbidding nested GC ids.
> 
> Test: tier1-6

This pull request has now been integrated.

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

8273221: Guard GCIdMark against nested calls

Reviewed-by: tschatzl, kbarrett

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

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


From ayang at openjdk.java.net  Mon Sep  6 08:35:02 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 6 Sep 2021 08:35:02 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor
Message-ID: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>

Simple change of moving `ResourceMark` closer to where it is actually required.

Test: tier1-6

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

Commit messages:
 - resource-mark

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 09:11:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 09:11:42 GMT
Subject: RFR: 8272985: Reference discovery is confused about atomicity and
 degree of parallelism [v2]
In-Reply-To: <TWWOe4wzf0tlLjfrN43CK3fq0Ko6oDZM5qCtVSBr3LQ=.06a26305-5efc-4923-b9c0-f871f5dc7cb0@github.com>
References: <yDky4mUCs7e-4DvDO3D7r8UT1HxBnDx2U2xJBOrd-G8=.b9c6add3-1cd6-4ebf-ab8d-b19e2c96ef2c@github.com>
 <brhgr3tyJkRDOqbjArnRZwS52lIla5rm2UO46VEgsJc=.01d65a93-f851-420a-b7f7-6795561dd595@github.com>
 <TWWOe4wzf0tlLjfrN43CK3fq0Ko6oDZM5qCtVSBr3LQ=.06a26305-5efc-4923-b9c0-f871f5dc7cb0@github.com>
Message-ID: <kF-pc_SA1KAoE6es2RmpWLG7hGk8jr9hqhwxSHkEUTM=.d509e500-7407-46a3-a616-c95fa70f70bb@github.com>

On Fri, 3 Sep 2021 20:52:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some more refactorng
>
> Looks good.

Thanks @kimbarrett @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 09:11:42 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 09:11:42 GMT
Subject: Integrated: 8272985: Reference discovery is confused about atomicity
 and degree of parallelism
In-Reply-To: <yDky4mUCs7e-4DvDO3D7r8UT1HxBnDx2U2xJBOrd-G8=.b9c6add3-1cd6-4ebf-ab8d-b19e2c96ef2c@github.com>
References: <yDky4mUCs7e-4DvDO3D7r8UT1HxBnDx2U2xJBOrd-G8=.b9c6add3-1cd6-4ebf-ab8d-b19e2c96ef2c@github.com>
Message-ID: <9u5tDuMTi5yRfdClc5Vs-iiYhiwfAXl4pbbDk2fbros=.2b416b15-fdda-417c-96c0-c4e296e8471b@github.com>

On Tue, 31 Aug 2021 09:19:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that fixes some (apparent) confusion between atomicity (of the discovery in the `ReferenceProcessor` sense) vs. the currently selected degree of parallelism?
> 
> For all four different combinations of atomicity and parallelism the `discovered` link in the `java.lang.ref.Reference` needs to be updated differently using a different kind of access, instead of just two based on atomicity.
> 
> I'll fix the use of `atomic` in `ReferenceProcessor` in a separate CR to hopefully remove the confusion for the reader too.
> 
> Testing: tier1-5, internal perf benchmarks without regressions
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: fb5b144e
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb5b144eca761d4b4c667efe05ca638536c065ac
Stats:     82 lines in 3 files changed: 44 ins; 20 del; 18 mod

8272985: Reference discovery is confused about atomicity and degree of parallelism

Reviewed-by: ayang, kbarrett

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 09:41:31 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 09:41:31 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap [v2]
In-Reply-To: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
Message-ID: <Teft49M9J2h1xoU0sK2bZ_UJ0r0PT1y5bTxuMizeO-s=.4ccf15fc-d022-4da5-af30-e811ffb8ab84@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves the G1 young collection algorithm containing the collection part out of `G1CollectedHeap` into a new `G1YoungCollector` class.
> 
> This change is mostly limited to moving the young collection specific code out; data structures are mostly kept in `G1CollectedHeap` for one reason or another, most of the time just to decrease the amount of code changes.
> 
> That will be fixed by upcoming (smaller) changes.
> 
> Other random comments:
>   * I am aware that the class forward definitions in `g1CollectedHeap.hpp` are unsorted, but they were already and I will fix that later.
>   * there will be some cleanup of `G1CollecteHeap` interface: at the moment, to reduce changes, I moved only code that was easy to move, and added back-references to `G1CollectedHeap`. There is a large list of getters for those in `G1YoungCollector`. These will be investigated one by one whether they can be removed by moving other code to `G1YoungCollector`.
>   * what I would like to move is at least data like the heap region attribute table, evacuation failure temporary information and others
>   * some data will likely move from `G1CollectedHeap` to some class that contains long term state specific to the young collection (e.g. evacuation failure injector, evacuation failure final result?, _bytes_used_during_gc, _gc_timer_stw, _gc_tracer_stw, stw reference processor and related closures) 
> 
> So lots of changes ahead, but this is a significant first step to avoid me doing tricky merges over and over again.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

  Removed obsolete file

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5333/files
  - new: https://git.openjdk.java.net/jdk/pull/5333/files/4c4d5177..c2122611

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

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 09:41:32 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 09:41:32 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap
In-Reply-To: <0PR4__XoTpuaJSa462nv7Jit9z0Bf2lisasrk2KK1Ho=.06a58412-7fc4-40df-8e4d-d803b1370bbe@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
 <0PR4__XoTpuaJSa462nv7Jit9z0Bf2lisasrk2KK1Ho=.06a58412-7fc4-40df-8e4d-d803b1370bbe@github.com>
Message-ID: <eFchK52c32J6NYb2aOFjgeiesm0ofQp8HjRorWvGdYY=.1e0f2668-a2a1-44b2-a93b-ad31576416df@github.com>

On Mon, 6 Sep 2021 02:06:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Seems g1YoungCollector.inline.hpp is an empty file and not referenced anywhere.

It got empty after the latest merge. Removed.

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 09:53:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 09:53:48 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v6]
In-Reply-To: <U_gXtDrBvjjrvcCMj52DnKG-gLb72WXEtTMop1nfk4s=.1d76982f-3721-4313-bd40-4aeb393fe4c0@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <U_gXtDrBvjjrvcCMj52DnKG-gLb72WXEtTMop1nfk4s=.1d76982f-3721-4313-bd40-4aeb393fe4c0@github.com>
Message-ID: <GvoolWE23Jg_9_Vtj9tsAz-oGPbjxYumOkvWwagZq0A=.fe2fe508-5bc3-4253-8f49-d72c40a71226@github.com>

On Fri, 3 Sep 2021 03:19:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is another try to optimize evcuation failure for regions.
>> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
>> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
>> 
>> I have 2 implementations:
>> 
>> - 1) CHT (Initial version)
>> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
>> 
>> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
>> 
>> I will attach the perf data in JBS.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor par iteration for regions of cset and evac failure.

Some minor issues remain. Sorry for not noticing some of them earlier.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2318:

> 2316: 
> 2317: void G1CollectedHeap::par_iterate_regions_array_part_from(HeapRegionClosure* cl,
> 2318:                                         HeapRegionClaimer* hr_claimer,

Indentation.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1210:

> 1208:   }
> 1209:   void collection_set_iterate_increment_from(HeapRegionClosure *blk, HeapRegionClaimer* hr_claimer, uint worker_id);
> 1210:   // Iterate the part of a regions array given by the offset and length applying the given

Iterate part of an array of region indexes given by offset and length, applying the given HeapRegionClosure on each region. The worker_id....

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1214:

> 1212:   // to allow for more efficient parallel iteration.
> 1213:   void par_iterate_regions_array_part_from(HeapRegionClosure* cl,
> 1214:                                    HeapRegionClaimer* hr_claimer,

Indentation - parameters should line up vertically.

src/hotspot/share/gc/g1/g1EvacFailure.cpp line 275:

> 273:   RemoveSelfForwardPtrHRClosure rsfp_cl(_rdcqs, worker_id, &_num_failed_regions);
> 274: 
> 275:   // Iterates through only the regions recorded as evacuation failure.

I would write something like:

// Iterate through all regions that failed evacuation during the entire collection.

But the code is kind of obvious to me now; the previous long-ish comment has only been there because to not over-optimize like has been done before. Your call.

src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp line 53:

> 51:                                        uint worker_id) {
> 52:   G1CollectedHeap::heap()->par_iterate_regions_array_part_from(closure,
> 53:                                                         _hrclaimer,

Indentation.

src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp line 28:

> 26: #define SHARE_GC_G1_G1EVACFAILUREREGIONS_HPP
> 27: 
> 28: #include "utilities/bitMap.inline.hpp"

need "runtime/atomic.hpp" too (or so) for the `Atomic` operations uses.

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 09:53:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 09:53:49 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v6]
In-Reply-To: <GvoolWE23Jg_9_Vtj9tsAz-oGPbjxYumOkvWwagZq0A=.fe2fe508-5bc3-4253-8f49-d72c40a71226@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <U_gXtDrBvjjrvcCMj52DnKG-gLb72WXEtTMop1nfk4s=.1d76982f-3721-4313-bd40-4aeb393fe4c0@github.com>
 <GvoolWE23Jg_9_Vtj9tsAz-oGPbjxYumOkvWwagZq0A=.fe2fe508-5bc3-4253-8f49-d72c40a71226@github.com>
Message-ID: <WG0zYUifkYwBqnigvvJlHZKR9qfGsoFthEOyagrGlLk=.a32006da-3fc8-47d4-a2d1-d12b9a2f15ab@github.com>

On Mon, 6 Sep 2021 09:48:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor par iteration for regions of cset and evac failure.
>
> src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp line 28:
> 
>> 26: #define SHARE_GC_G1_G1EVACFAILUREREGIONS_HPP
>> 27: 
>> 28: #include "utilities/bitMap.inline.hpp"
> 
> need "runtime/atomic.hpp" too (or so) for the `Atomic` operations uses.

We do not allow includes of `.inline.hpp` files in `.hpp` files to avoid issues with circular dependencies. The `record` method needs to be put into an `.inline.hpp` file due to the use of `par_set_bit`.

Sorry for not noticing earlier.

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

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


From sjohanss at openjdk.java.net  Mon Sep  6 14:06:40 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 6 Sep 2021 14:06:40 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap [v2]
In-Reply-To: <Teft49M9J2h1xoU0sK2bZ_UJ0r0PT1y5bTxuMizeO-s=.4ccf15fc-d022-4da5-af30-e811ffb8ab84@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
 <Teft49M9J2h1xoU0sK2bZ_UJ0r0PT1y5bTxuMizeO-s=.4ccf15fc-d022-4da5-af30-e811ffb8ab84@github.com>
Message-ID: <qTMOgKYiHjhr58o2Bpq_XtkKAZGPi4lUOgUezy0jo7U=.f731acc2-3af9-4734-8e26-cfb7334962ef@github.com>

On Mon, 6 Sep 2021 09:41:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves the G1 young collection algorithm containing the collection part out of `G1CollectedHeap` into a new `G1YoungCollector` class.
>> 
>> This change is mostly limited to moving the young collection specific code out; data structures are mostly kept in `G1CollectedHeap` for one reason or another, most of the time just to decrease the amount of code changes.
>> 
>> That will be fixed by upcoming (smaller) changes.
>> 
>> Other random comments:
>>   * I am aware that the class forward definitions in `g1CollectedHeap.hpp` are unsorted, but they were already and I will fix that later.
>>   * there will be some cleanup of `G1CollecteHeap` interface: at the moment, to reduce changes, I moved only code that was easy to move, and added back-references to `G1CollectedHeap`. There is a large list of getters for those in `G1YoungCollector`. These will be investigated one by one whether they can be removed by moving other code to `G1YoungCollector`.
>>   * what I would like to move is at least data like the heap region attribute table, evacuation failure temporary information and others
>>   * some data will likely move from `G1CollectedHeap` to some class that contains long term state specific to the young collection (e.g. evacuation failure injector, evacuation failure final result?, _bytes_used_during_gc, _gc_timer_stw, _gc_tracer_stw, stw reference processor and related closures) 
>> 
>> So lots of changes ahead, but this is a significant first step to avoid me doing tricky merges over and over again.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed obsolete file

Looks good to me.

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

Marked as reviewed by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Sep  6 14:29:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 14:29:38 GMT
Subject: RFR: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap [v2]
In-Reply-To: <qTMOgKYiHjhr58o2Bpq_XtkKAZGPi4lUOgUezy0jo7U=.f731acc2-3af9-4734-8e26-cfb7334962ef@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
 <Teft49M9J2h1xoU0sK2bZ_UJ0r0PT1y5bTxuMizeO-s=.4ccf15fc-d022-4da5-af30-e811ffb8ab84@github.com>
 <qTMOgKYiHjhr58o2Bpq_XtkKAZGPi4lUOgUezy0jo7U=.f731acc2-3af9-4734-8e26-cfb7334962ef@github.com>
Message-ID: <BqjsTuUUilxdrefHFnxum2vDStq2PI14hCO4ujXMWDc=.85d39a33-168d-45f9-95ec-9d91dc749a75@github.com>

On Mon, 6 Sep 2021 14:03:20 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed obsolete file
>
> Looks good to me.

Thanks @kstefanj @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 14:32:45 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 14:32:45 GMT
Subject: Integrated: 8253343: Extract G1 Young GC algorithm related code from
 G1CollectedHeap
In-Reply-To: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
References: <-VyqqZ96HE2MtmFU1JO3JCbuOa6b348OGkRfQdb9fpg=.1d13f2bc-47e3-4895-aaf9-a6b0b2466df7@github.com>
Message-ID: <oq5NVmy7-SnXrGtarpqpIk_rCf4Z4xTrxUS0TwVT1pw=.c2575a14-c90f-4342-a13e-08f833ab1225@github.com>

On Wed, 1 Sep 2021 14:53:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves the G1 young collection algorithm containing the collection part out of `G1CollectedHeap` into a new `G1YoungCollector` class.
> 
> This change is mostly limited to moving the young collection specific code out; data structures are mostly kept in `G1CollectedHeap` for one reason or another, most of the time just to decrease the amount of code changes.
> 
> That will be fixed by upcoming (smaller) changes.
> 
> Other random comments:
>   * I am aware that the class forward definitions in `g1CollectedHeap.hpp` are unsorted, but they were already and I will fix that later.
>   * there will be some cleanup of `G1CollecteHeap` interface: at the moment, to reduce changes, I moved only code that was easy to move, and added back-references to `G1CollectedHeap`. There is a large list of getters for those in `G1YoungCollector`. These will be investigated one by one whether they can be removed by moving other code to `G1YoungCollector`.
>   * what I would like to move is at least data like the heap region attribute table, evacuation failure temporary information and others
>   * some data will likely move from `G1CollectedHeap` to some class that contains long term state specific to the young collection (e.g. evacuation failure injector, evacuation failure final result?, _bytes_used_during_gc, _gc_timer_stw, _gc_tracer_stw, stw reference processor and related closures) 
> 
> So lots of changes ahead, but this is a significant first step to avoid me doing tricky merges over and over again.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 2cabec8d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2cabec8ddc19dd66495957e7ef553990a502e993
Stats:     2353 lines in 6 files changed: 1292 ins; 1048 del; 13 mod

8253343: Extract G1 Young GC algorithm related code from G1CollectedHeap

Reviewed-by: ayang, sjohanss

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

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


From kbarrett at openjdk.java.net  Mon Sep  6 15:02:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 6 Sep 2021 15:02:50 GMT
Subject: RFR: 8273386: Remove duplicated code in
 G1DCQS::abandon_completed_buffers
Message-ID: <cE1Yyj3vEGmCACKy7w2ZXRnwEcXvNFatGCQaA9u29p0=.07191e88-6d4c-4ba2-90c9-46e1ddfdb521@github.com>

Please review this small change to remove some redundant code in
G1DirtyCardQueueSet::abandon_completed_buffers.  After the two removed lines
it calls take_all_completed_buffers, which begins with those same two lines.

Testing:
Local (linux-x64) hotspot:tier1 with -XX:+UseG1GC.

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

Commit messages:
 - remove redundant code

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

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


From tschatzl at openjdk.java.net  Mon Sep  6 16:13:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 6 Sep 2021 16:13:37 GMT
Subject: RFR: 8273386: Remove duplicated code in
 G1DCQS::abandon_completed_buffers
In-Reply-To: <cE1Yyj3vEGmCACKy7w2ZXRnwEcXvNFatGCQaA9u29p0=.07191e88-6d4c-4ba2-90c9-46e1ddfdb521@github.com>
References: <cE1Yyj3vEGmCACKy7w2ZXRnwEcXvNFatGCQaA9u29p0=.07191e88-6d4c-4ba2-90c9-46e1ddfdb521@github.com>
Message-ID: <V76xK_aCuaFIxMrHc_A-_Ha1hE5imA3bJJdI8b3vohs=.59090c79-9357-4e1b-bd18-b4b5e131781f@github.com>

On Mon, 6 Sep 2021 14:54:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small change to remove some redundant code in
> G1DirtyCardQueueSet::abandon_completed_buffers.  After the two removed lines
> it calls take_all_completed_buffers, which begins with those same two lines.
> 
> Testing:
> Local (linux-x64) hotspot:tier1 with -XX:+UseG1GC.

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

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


From duke at openjdk.java.net  Mon Sep  6 16:29:39 2021
From: duke at openjdk.java.net (duke)
Date: Mon, 6 Sep 2021 16:29:39 GMT
Subject: Withdrawn: 8269870: PS: Membar in
 PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed
In-Reply-To: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
References: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
Message-ID: <MrxW4XG9jxWhRabjrBcOhqm_d415EkcE0YnkAuqizY8=.f6353376-8be7-42a9-8dfb-b0d17c64a964@github.com>

On Mon, 12 Jul 2021 02:43:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Membar in PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed.
> ( Please also refer to the similar membar relaxed in G1ParScanThreadState::do_copy_to_survivor_space )
> 
> Per the specjbb2015 test results, it has about 8% improvement in critical.
> https://bugs.openjdk.java.net/secure/attachment/95445/jdk17_default_options.v2.png

This pull request has been closed without being integrated.

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

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


From kbarrett at openjdk.java.net  Mon Sep  6 18:23:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 6 Sep 2021 18:23:40 GMT
Subject: RFR: 8273386: Remove duplicated code in
 G1DCQS::abandon_completed_buffers
In-Reply-To: <V76xK_aCuaFIxMrHc_A-_Ha1hE5imA3bJJdI8b3vohs=.59090c79-9357-4e1b-bd18-b4b5e131781f@github.com>
References: <cE1Yyj3vEGmCACKy7w2ZXRnwEcXvNFatGCQaA9u29p0=.07191e88-6d4c-4ba2-90c9-46e1ddfdb521@github.com>
 <V76xK_aCuaFIxMrHc_A-_Ha1hE5imA3bJJdI8b3vohs=.59090c79-9357-4e1b-bd18-b4b5e131781f@github.com>
Message-ID: <wefstzxhKmnwZ5GgHHlEfk0UJZyZxsCvXIlQ0AZ9lZ0=.ac89adde-58e0-4381-b530-fbc756410f78@github.com>

On Mon, 6 Sep 2021 16:11:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Lgtm and trivial.

Thanks for review @tschatzl .  Agree this is trivial, so integrating now.

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

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


From kbarrett at openjdk.java.net  Mon Sep  6 18:23:41 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 6 Sep 2021 18:23:41 GMT
Subject: Integrated: 8273386: Remove duplicated code in
 G1DCQS::abandon_completed_buffers
In-Reply-To: <cE1Yyj3vEGmCACKy7w2ZXRnwEcXvNFatGCQaA9u29p0=.07191e88-6d4c-4ba2-90c9-46e1ddfdb521@github.com>
References: <cE1Yyj3vEGmCACKy7w2ZXRnwEcXvNFatGCQaA9u29p0=.07191e88-6d4c-4ba2-90c9-46e1ddfdb521@github.com>
Message-ID: <lYI8zgy27wQBFKPIz_WFY4sUrCKS-ADXWgDaPNBa6uA=.febd8488-5601-454f-a9b5-376e3897c76b@github.com>

On Mon, 6 Sep 2021 14:54:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small change to remove some redundant code in
> G1DirtyCardQueueSet::abandon_completed_buffers.  After the two removed lines
> it calls take_all_completed_buffers, which begins with those same two lines.
> 
> Testing:
> Local (linux-x64) hotspot:tier1 with -XX:+UseG1GC.

This pull request has now been integrated.

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

8273386: Remove duplicated code in G1DCQS::abandon_completed_buffers

Reviewed-by: tschatzl

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

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


From mli at openjdk.java.net  Tue Sep  7 02:07:51 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 7 Sep 2021 02:07:51 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v7]
In-Reply-To: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
Message-ID: <CeX5f3fGR6u_sbLjs250ZHcz2Ym_FYkCo-MdMYy-NYY=.9975bdd9-0fb1-414b-bfe0-b484d80d38d5@github.com>

> This is another try to optimize evcuation failure for regions.
> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
> 
> I have 2 implementations:
> 
> - 1) CHT (Initial version)
> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
> 
> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
> 
> I will attach the perf data in JBS.

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

  Fix misc issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5272/files
  - new: https://git.openjdk.java.net/jdk/pull/5272/files/3b5543f5..b9cf480c

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

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

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


From mli at openjdk.java.net  Tue Sep  7 02:07:52 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 7 Sep 2021 02:07:52 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v6]
In-Reply-To: <U_gXtDrBvjjrvcCMj52DnKG-gLb72WXEtTMop1nfk4s=.1d76982f-3721-4313-bd40-4aeb393fe4c0@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <U_gXtDrBvjjrvcCMj52DnKG-gLb72WXEtTMop1nfk4s=.1d76982f-3721-4313-bd40-4aeb393fe4c0@github.com>
Message-ID: <lwAsDKx2WAVRvkkmRihHh-wdGXNp1mtIcMiwdIMxmBE=.b262cf9e-2364-4f55-8706-069b0ce33dce@github.com>

On Fri, 3 Sep 2021 03:19:57 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is another try to optimize evcuation failure for regions.
>> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
>> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
>> 
>> I have 2 implementations:
>> 
>> - 1) CHT (Initial version)
>> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
>> 
>> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
>> 
>> I will attach the perf data in JBS.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor par iteration for regions of cset and evac failure.

Thanks a lot for the detailed review, I should have noticed some of the issues.

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

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


From mli at openjdk.java.net  Tue Sep  7 02:27:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 7 Sep 2021 02:27:59 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v8]
In-Reply-To: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
Message-ID: <zf26TR152Q2RDGT7sJ-JGnBgzKrZOpg_3gDSo3VhjWQ=.9c9cd5f1-a6d6-4752-a045-4156bc6631cf@github.com>

> This is another try to optimize evcuation failure for regions.
> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
> 
> I have 2 implementations:
> 
> - 1) CHT (Initial version)
> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
> 
> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
> 
> I will attach the perf data in JBS.

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
 - Fix misc issues
 - Refactor par iteration for regions of cset and evac failure.
 - Modify as review comments suggested.
 - merge from master
 - Fix missing header files
 - reuse original bitmap rather than CHT
 - merge with existing classes
 - Initial commit

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

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

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


From mli at openjdk.java.net  Tue Sep  7 04:27:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 7 Sep 2021 04:27:01 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
Message-ID: <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>

> This is another try to optimize evcuation failure for regions.
> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
> 
> I have 2 implementations:
> 
> - 1) CHT (Initial version)
> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
> 
> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
> 
> I will attach the perf data in JBS.

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

  Fix merging issues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5272/files
  - new: https://git.openjdk.java.net/jdk/pull/5272/files/2c13f46c..59bdc614

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

  Stats: 128 lines in 11 files changed: 54 ins; 27 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5272/head:pull/5272

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


From tschatzl at openjdk.java.net  Tue Sep  7 08:05:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 08:05:50 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
Message-ID: <wEHR27-GPcDersmpHaYqn5B1WRcZyY1LM79f4LEsGJQ=.846fc241-04a5-4967-b7b4-7f37b1ea91ca@github.com>

On Tue, 7 Sep 2021 04:27:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is another try to optimize evcuation failure for regions.
>> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
>> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
>> 
>> I have 2 implementations:
>> 
>> - 1) CHT (Initial version)
>> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
>> 
>> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
>> 
>> I will attach the perf data in JBS.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merging issues

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Sep  7 09:36:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 09:36:37 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <7dgpl3XA92YhSdC0GdEJk2vR7AYBOvpBTgtyyJd8KZg=.f68a1af0-ba95-491c-9c56-9003c04b224a@github.com>

On Mon, 6 Sep 2021 08:26:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

I did some looking whether there are similar places to look out for, but found nothing.

Also, I would not be opposed to completely remove that trace message: while trace messages may slow down the garbage collection significantly, this message probably does so way too much to be useful for any kind of output; I understand that this message is enabled in development builds only too, but the other collectors do not have similar messages anyway. Additionally, even when debugging it helps much more to have some a bit more targeted log message; this is kind of a last resort to dump *everything*. At that point during debugging adding just another log message is probably not too much of a bother (as you probably have exhausted all other options and littered the code with such messages already. I "know" because I just went through that exercise with another issue in g1, and that single one message wouldn't have helped me in any significant way).

So long story short, if you want to remove that message fine with me, but it might be a good idea to consider other opinions too.

So lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Tue Sep  7 10:11:41 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 7 Sep 2021 10:11:41 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <vIqlGO5Va6mMOxxuNRHkt7nLh_yuUfXlrB9kPxup4wU=.8af0ef21-98ee-4e58-a623-c57375d87ffa@github.com>

On Mon, 6 Sep 2021 08:26:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

Log tag, `scavenge`, only has `develop_trace` level logs. If they are rarely useful, they should be removed. (I used `scavenge)` to see locate them.)

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

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


From tschatzl at openjdk.java.net  Tue Sep  7 11:25:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 11:25:38 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <U-IpXuFjvWokWM7tMKO1M_vb4cGg2CeJjkTImgnFJsY=.2cf3e33c-3416-4d54-a026-510e19ec141f@github.com>

On Mon, 6 Sep 2021 08:26:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

Looking at it a bit more, probably all of these `gc, scavenge` log messages should get the same treatment with the local `ResourceMark`. They will otherwise eat tons of memory as every string for every object will be newly allocated in the resource area.

That does not preclude just removing these, but my opinion stands: at the point when you need those, you'll have likely exhausted lots of other avenues already. However maybe this is just my feeling because G1 does not have these, and there you'll need to add messages always. An alternative could be to add similar messages to G1?

It would be good if somebody else could give his opinion.

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

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


From tschatzl at openjdk.java.net  Tue Sep  7 12:03:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 12:03:51 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v7]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <kySqy7ua1JbozEp2n_ZecnOEaYpBmm98Q49fOVdqN-k=.f9d47e48-e053-4781-b4c9-a50a3e673c02@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> 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 10 commits:

 - Add enqueue callback
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - ayang comments; note that the mentioned crash is still not fixed.
 - Merge master
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - More updates to comment
 - Clarify comment
 - ayang review
 - Some random changes
 - No scan during self forward

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

Changes: https://git.openjdk.java.net/jdk/pull/5037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=06
  Stats: 280 lines in 21 files changed: 145 ins; 77 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5037/head:pull/5037

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


From tschatzl at openjdk.java.net  Tue Sep  7 12:40:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 12:40:55 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v8]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <OZxTYRxAopdhdU2AJXF79SgwHDrWrJ8ME50ySKjByi4=.76acf854-5ea0-4ee8-a77f-d7f8a442812c@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> 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 11 commits:

 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Add enqueue callback
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - ayang comments; note that the mentioned crash is still not fixed.
 - Merge master
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - More updates to comment
 - Clarify comment
 - ayang review
 - Some random changes
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/377b1867...4133f3e3

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

Changes: https://git.openjdk.java.net/jdk/pull/5037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=07
  Stats: 280 lines in 22 files changed: 145 ins; 77 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5037/head:pull/5037

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


From tschatzl at openjdk.java.net  Tue Sep  7 13:26:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 13:26:04 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v9]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <R5kEKsDG7MzWvEWeKeWH-k_-ZIEKrOASPOm8F8BEZIU=.2e788514-8e72-4e05-82f5-14eb7bfdec70@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> Thanks,
>   Thomas

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

  Fix compilation after merge

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5037/files
  - new: https://git.openjdk.java.net/jdk/pull/5037/files/4133f3e3..4e8add13

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

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

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


From tschatzl at openjdk.java.net  Tue Sep  7 13:34:36 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 13:34:36 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v9]
In-Reply-To: <R5kEKsDG7MzWvEWeKeWH-k_-ZIEKrOASPOm8F8BEZIU=.2e788514-8e72-4e05-82f5-14eb7bfdec70@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <R5kEKsDG7MzWvEWeKeWH-k_-ZIEKrOASPOm8F8BEZIU=.2e788514-8e72-4e05-82f5-14eb7bfdec70@github.com>
Message-ID: <f6SHuJ1xZeyfTinhFHHqNOI9scHtCd4LtjPXykeEtmQ=.4ea8d37b-4819-4d54-8263-398dfad2b952@github.com>

On Tue, 7 Sep 2021 13:26:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation after merge

The recent change fixes the remaining issue mentioned earlier by introducing a GC specific closure that makes the `ReferenceProcessor::enqueue` method configurable by GC (type).

This fixes the issue (note that the change introduced in [JDK-8270842](https://bugs.openjdk.java.net/browse/JDK-8270842) introduced the same issue, just much less common I believe).

Passes tier1-5, a closed test that failed with around 3% failures with these changes now passes always.

>From a performance POV I tested and analyzed reference processing performance on G1 so far with no particular regressions at both our test suite as well as some detailed look at discovery (i.e. the time spent per discovery/enqueue seems to be the same as before). Currently looking into Parallel GC differences.

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

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


From tschatzl at openjdk.java.net  Tue Sep  7 17:27:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 7 Sep 2021 17:27:48 GMT
Subject: RFR: 8273439: Fix G1CollectedHeap includes and forward declarations
Message-ID: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>

Hi all,

  can I have reviews for this change that
  * removes unnecessary includes (just one actually)
  * removes unnecessary forwards (either not used, or already covered by the #include declaration)
  * sorts the forward declarations
  * adds necessary forwards that were not directly included

Testing: building on various platforms

Thanks,
  Thomas

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

Commit messages:
 - Fix forward declarations and includes

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

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


From ayang at openjdk.java.net  Tue Sep  7 17:40:36 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 7 Sep 2021 17:40:36 GMT
Subject: RFR: 8273439: Fix G1CollectedHeap includes and forward
 declarations
In-Reply-To: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
References: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
Message-ID: <5fvz1aCLN41ns29h9N892ltzmhk0UrgEhCYbM8QSnzE=.814e039e-3bc7-48a1-b84b-75483617ea58@github.com>

On Tue, 7 Sep 2021 15:40:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that
>   * removes unnecessary includes (just one actually)
>   * removes unnecessary forwards (either not used, or already covered by the #include declaration)
>   * sorts the forward declarations
>   * adds necessary forwards that were not directly included
> 
> Testing: building on various platforms
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From ayang at openjdk.java.net  Tue Sep  7 18:35:36 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 7 Sep 2021 18:35:36 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
Message-ID: <ucjzMlN1Xe7owXHL1Lclzyi2up_BZFJcbvmVg1R3m7c=.4fb804ed-5988-48d1-8189-cb1dba1babfc@github.com>

On Tue, 7 Sep 2021 04:27:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is another try to optimize evcuation failure for regions.
>> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
>> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
>> 
>> I have 2 implementations:
>> 
>> - 1) CHT (Initial version)
>> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
>> 
>> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
>> 
>> I will attach the perf data in JBS.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merging issues

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2329:

> 2327: }
> 2328: 
> 2329: void G1CollectedHeap::par_iterate_regions_array_part_from(HeapRegionClosure* cl,

This method essentially apply a closure to all elements in `[offset, length)` of `regions`. I wonder if we can pass `&regions[offset]` and `length-offset` to this method. Then this method can work on the whole array, and figuring out the starting index for each worker becomes trivial, `worker_id * array_len / #workers`. It's not obvious to me why the calculation in this patch guarantees balanced start index.

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

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


From mli at openjdk.java.net  Wed Sep  8 01:43:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 01:43:08 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <ucjzMlN1Xe7owXHL1Lclzyi2up_BZFJcbvmVg1R3m7c=.4fb804ed-5988-48d1-8189-cb1dba1babfc@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
 <ucjzMlN1Xe7owXHL1Lclzyi2up_BZFJcbvmVg1R3m7c=.4fb804ed-5988-48d1-8189-cb1dba1babfc@github.com>
Message-ID: <QeC0xDCgdKn2LUbFKNOy2sFH9exdFoaMann92ns0cKw=.37ffc564-10a7-4bfd-921a-89d7d0c11363@github.com>

On Tue, 7 Sep 2021 18:24:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merging issues
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2329:
> 
>> 2327: }
>> 2328: 
>> 2329: void G1CollectedHeap::par_iterate_regions_array_part_from(HeapRegionClosure* cl,
> 
> This method essentially apply a closure to all elements in `[offset, length)` of `regions`. I wonder if we can pass `&regions[offset]` and `length-offset` to this method. Then this method can work on the whole array, and figuring out the starting index for each worker becomes trivial, `worker_id * array_len / #workers`. It's not obvious to me why the calculation in this patch guarantees balanced start index.

In fact, this method is just moved from G1CollectionSet::iterate_part_from which is deleted, the movement is to simply reuse its logic in both G1CollectionSet and G1EvacFailureRegions.

Your suggestion seems reasonable to me, thanks for catching this.  
As this is an refinement to existing code, I wonder if we could do this in another issue? And as I know Thomas is starting another refactoring in G1's related code, so I hope this can be pushed eariler to avoid further merge conflicting in either pr. 
How do you think about it? I'll create an issue to track this code refinement if you agree.

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

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


From ayang at openjdk.java.net  Wed Sep  8 07:20:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 8 Sep 2021 07:20:12 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <QeC0xDCgdKn2LUbFKNOy2sFH9exdFoaMann92ns0cKw=.37ffc564-10a7-4bfd-921a-89d7d0c11363@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
 <ucjzMlN1Xe7owXHL1Lclzyi2up_BZFJcbvmVg1R3m7c=.4fb804ed-5988-48d1-8189-cb1dba1babfc@github.com>
 <QeC0xDCgdKn2LUbFKNOy2sFH9exdFoaMann92ns0cKw=.37ffc564-10a7-4bfd-921a-89d7d0c11363@github.com>
Message-ID: <kh-Qzu-W5HwdUjYwv1TAucqldJ1MV9Ik3p7f0gklPbI=.e4f8a7a2-3127-4c12-828d-1651150d1260@github.com>

On Wed, 8 Sep 2021 01:39:58 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this method is just moved from

Yes, you are right; I didn't realize it.

> How do you think about it? I'll create an issue to track this code refinement if you agree.

Sure; thank you.

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

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


From ayang at openjdk.java.net  Wed Sep  8 07:20:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 8 Sep 2021 07:20:12 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
Message-ID: <WCb9gcebJ2MXmhSYUj7kBLepu5MwTgDXErhuGSfrevc=.10b32329-6674-480f-b1aa-48fbf332e4f0@github.com>

On Tue, 7 Sep 2021 04:27:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is another try to optimize evcuation failure for regions.
>> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
>> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
>> 
>> I have 2 implementations:
>> 
>> - 1) CHT (Initial version)
>> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
>> 
>> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
>> 
>> I will attach the perf data in JBS.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merging issues

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Sep  8 07:41:25 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 07:41:25 GMT
Subject: RFR: 8273185: Rename the term "atomic" in ReferenceProcessor
Message-ID: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>

Hi all,

  please review this suggestion to rename the term "atomic" in the `ReferenceProcessor` class to "concurrent"/"stw" to avoid the confusion with Atomic operations.

It's a smaller change than expected, which is good, but also might question the need for this change. I grepped for "atomic" in the reference processor sources and hopefully got everything.

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - Rename atomic to concurrent/stw

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

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


From ayang at openjdk.java.net  Wed Sep  8 07:50:07 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 8 Sep 2021 07:50:07 GMT
Subject: RFR: 8273185: Rename the term "atomic" in ReferenceProcessor
In-Reply-To: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
References: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
Message-ID: <cgWOHG0f2t7k09MF68RsoO_3NBFyrm5rN5cJdjPDHAA=.a17eeca9-36ca-4ea0-8898-969b949a53dc@github.com>

On Tue, 7 Sep 2021 18:58:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this suggestion to rename the term "atomic" in the `ReferenceProcessor` class to "concurrent"/"stw" to avoid the confusion with Atomic operations.
> 
> It's a smaller change than expected, which is good, but also might question the need for this change. I grepped for "atomic" in the reference processor sources and hopefully got everything.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From mli at openjdk.java.net  Wed Sep  8 08:05:10 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 08:05:10 GMT
Subject: RFR: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration [v9]
In-Reply-To: <wEHR27-GPcDersmpHaYqn5B1WRcZyY1LM79f4LEsGJQ=.846fc241-04a5-4967-b7b4-7f37b1ea91ca@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
 <zbBm72Epq1pS067YbFjmN97tEWM3xWGdkqiS5Un97ZM=.dcdd88fa-3c60-4648-85a1-a40cf8f1d5a1@github.com>
 <wEHR27-GPcDersmpHaYqn5B1WRcZyY1LM79f4LEsGJQ=.846fc241-04a5-4967-b7b4-7f37b1ea91ca@github.com>
Message-ID: <Xtrz0W6cVDTwAeXAaJu5VWisGXBwGwuGkLJ-YQ1NsmE=.d36c82c4-aa31-4272-934d-5f1c8c25dafb@github.com>

On Tue, 7 Sep 2021 08:02: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:
>> 
>>   Fix merging issues
>
> Lgtm.

Thanks for your reviews @tschatzl @albertnetymk 

I created to https://bugs.openjdk.java.net/browse/JDK-8273476 to track the issue caught by Albert.

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

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


From mli at openjdk.java.net  Wed Sep  8 08:05:11 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 08:05:11 GMT
Subject: Integrated: 8254167 G1: Record regions where evacuation failed to
 provide targeted iteration
In-Reply-To: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
References: <Oy2mmyecTy9ijP5TZwDGhn2emFPoyrbi58cbzO171QY=.02d31fbc-489f-403d-91b0-ef39e55c94ef@github.com>
Message-ID: <Vw4ODosdlReiTES-wF4EQxDptd6ZvBXrRiBoqMuy-y8=.70eef5c4-7cef-45f6-82f8-6e7255d72da1@github.com>

On Fri, 27 Aug 2021 04:09:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is another try to optimize evcuation failure for regions.
> I record evacuation failed regions, and iterate these regions directly rather than iterate the whole cset.
> The implementation reuses and refactors some of the existing data in g1CollectedHeap (_regions_failed_evacuation, _num_regions_failed_evacuation), and records these regions in an array, and iterate this array later in post evacuation phase.
> 
> I have 2 implementations:
> 
> - 1) CHT (Initial version)
> - 2) bitmap (latest version, reuse _regions_failed_evacuation in g1CollectedHeap)
> 
> This implementation does not consider work distribution as mentioned in JDK-8254167 yet. But seems it already get better&stable performance gain than origin. We could improve it further later if work distribution is necessary.
> 
> I will attach the perf data in JBS.

This pull request has now been integrated.

Changeset: a66629a4
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a66629a464b97176bcdc2ca1150d12df6241dc1c
Stats:     417 lines in 16 files changed: 283 ins; 65 del; 69 mod

8254167: G1: Record regions where evacuation failed to provide targeted iteration

Reviewed-by: tschatzl, ayang

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

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


From shade at openjdk.java.net  Wed Sep  8 08:31:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 08:31:10 GMT
Subject: RFR: 8273185: Rename the term "atomic" in ReferenceProcessor
In-Reply-To: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
References: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
Message-ID: <8ofGUpVPnUdS1CwwexqKaQRyTqcfTq48qrTLfrh5zX8=.d3898f3c-923e-4493-a6aa-8fd075ae1541@github.com>

On Tue, 7 Sep 2021 18:58:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this suggestion to rename the term "atomic" in the `ReferenceProcessor` class to "concurrent"/"stw" to avoid the confusion with Atomic operations.
> 
> It's a smaller change than expected, which is good, but also might question the need for this change. I grepped for "atomic" in the reference processor sources and hopefully got everything.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This looks fine to me, with one nit.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 905:

> 903:          "Bad referent " INTPTR_FORMAT " found in Reference "
> 904:          INTPTR_FORMAT " during %sconcurrent discovery ",
> 905:          p2i(referent), p2i(obj), concurrent ? "non-" : "");

This seems backwards, shouldn't it be `concurrent ? "" : "non-"`?

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

Marked as reviewed by shade (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep  8 08:36:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 08:36:33 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v10]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <C2NQVPSZtVi27JRvjjUqzBjrDvsBQjoCcvGg0frgo2s=.c90f70c3-b8f3-48b6-9c87-cb16cdcb6a77@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> 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 13 commits:

 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Fix compilation after merge
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Add enqueue callback
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - ayang comments; note that the mentioned crash is still not fixed.
 - Merge master
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - More updates to comment
 - Clarify comment
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/a66629a4...c70d2a75

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

Changes: https://git.openjdk.java.net/jdk/pull/5037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=09
  Stats: 290 lines in 23 files changed: 147 ins; 83 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5037/head:pull/5037

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


From tschatzl at openjdk.java.net  Wed Sep  8 08:38:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 08:38:38 GMT
Subject: RFR: 8273185: Rename the term "atomic" in ReferenceProcessor [v2]
In-Reply-To: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
References: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
Message-ID: <Oam6IN8oihWLlwULwjbJF3Ld5livaciOaQvqMaQbKPM=.eabe9484-8f50-4436-aac4-818460f216bf@github.com>

> Hi all,
> 
>   please review this suggestion to rename the term "atomic" in the `ReferenceProcessor` class to "concurrent"/"stw" to avoid the confusion with Atomic operations.
> 
> It's a smaller change than expected, which is good, but also might question the need for this change. I grepped for "atomic" in the reference processor sources and hopefully got everything.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

  shade review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5397/files
  - new: https://git.openjdk.java.net/jdk/pull/5397/files/bab3b91e..18843569

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

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

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


From mli at openjdk.java.net  Wed Sep  8 09:06:24 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 09:06:24 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v3]
In-Reply-To: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
Message-ID: <2pGQBBCp20w9gB0iKyknrB1tlJy4mqTGV8ReJ3GtztE=.298bdf91-174a-4c72-a5fa-a2aa4a40c6ae@github.com>

> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

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
 - Fix include order.
 - Rename g1EvacuationInfo.hpp to g1EvacInfo.hpp, and related class names

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

Changes: https://git.openjdk.java.net/jdk/pull/5325/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5325&range=02
  Stats: 146 lines in 10 files changed: 1 ins; 107 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5325.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5325/head:pull/5325

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


From mli at openjdk.java.net  Wed Sep  8 10:59:27 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 10:59:27 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v4]
In-Reply-To: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
Message-ID: <JM6OEEDxKor4iuednuz-JVQ3DBgJ_igIJF9z26MsH4E=.8cec8822-df1f-4e0f-8884-df821f077a39@github.com>

> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

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

  Fix merge issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5325/files
  - new: https://git.openjdk.java.net/jdk/pull/5325/files/ea3636be..8234dcd5

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

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

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


From ayang at openjdk.java.net  Wed Sep  8 10:59:27 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 8 Sep 2021 10:59:27 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v4]
In-Reply-To: <fecx1uXKkHnBrm_eT51fWi0yVdCIDYaVDtkkkt1AMeU=.b5c3ec4d-1499-4707-a1e9-63db713d2317@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
 <hYtL65O5fsyvzcMoYH4rcXO2fTM4QKE5TEGBjWDr7AE=.749ec5b2-44dd-44de-aa2d-cfb26b51d369@github.com>
 <fecx1uXKkHnBrm_eT51fWi0yVdCIDYaVDtkkkt1AMeU=.b5c3ec4d-1499-4707-a1e9-63db713d2317@github.com>
Message-ID: <dGDRQzZykL9M3nCsjWAcYY6nm8uXjk3uFWKLRZCXRnA=.34cac336-cca8-42b4-be25-17051f5f9572@github.com>

On Thu, 2 Sep 2021 01:26:58 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Lgtm.
>> 
>> Note that because you were so fast posting this, I do not know what others think about the name change in this direction, but I think it's okay. Please wait for further feedback.
>
>> Lgtm.
>> 
>> Note that because you were so fast posting this, I do not know what others think about the name change in this direction, but I think it's okay. Please wait for further feedback.
> 
> Sure, I will wait for a while before push.
> Thanks for your reviews, @tschatzl @albertnetymk

Some code seems removed by accident in the latest commit. @Hamlin-Li

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

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


From pliden at openjdk.java.net  Wed Sep  8 11:06:26 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 8 Sep 2021 11:06:26 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang
Message-ID: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>

JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.

As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().

Testing:
 - Passed Tier1-3
 - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
 - Manually ran jcmd GC.heap_dump with various GCs enabled

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

Commit messages:
 - 8273482: Remove "foreground work" concept from WorkGang

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

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


From mli at openjdk.java.net  Wed Sep  8 11:50:09 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 11:50:09 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v4]
In-Reply-To: <JM6OEEDxKor4iuednuz-JVQ3DBgJ_igIJF9z26MsH4E=.8cec8822-df1f-4e0f-8884-df821f077a39@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
 <JM6OEEDxKor4iuednuz-JVQ3DBgJ_igIJF9z26MsH4E=.8cec8822-df1f-4e0f-8884-df821f077a39@github.com>
Message-ID: <dgVhQX37MIhRFy7XtoE2d7EuR7ojHEmC5jkXypqbfH8=.c814e9d8-9682-408d-b31e-a559b439672c@github.com>

On Wed, 8 Sep 2021 10:59:27 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge issue

Thanks for reminding, I've fixed the issue.
Yes. I'm not sure how this happened, I generated a patch from one machine, then applied the patch in another one, some source code was missing.

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

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


From mli at openjdk.java.net  Wed Sep  8 12:03:16 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 8 Sep 2021 12:03:16 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from
Message-ID: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>

G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
The parameters and logic of this method could be refined a bit to make it more straight.

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

Commit messages:
 - refine par_iterate_regions_array_part_from

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

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


From tschatzl at openjdk.java.net  Wed Sep  8 12:07:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 12:07:04 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v4]
In-Reply-To: <JM6OEEDxKor4iuednuz-JVQ3DBgJ_igIJF9z26MsH4E=.8cec8822-df1f-4e0f-8884-df821f077a39@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
 <JM6OEEDxKor4iuednuz-JVQ3DBgJ_igIJF9z26MsH4E=.8cec8822-df1f-4e0f-8884-df821f077a39@github.com>
Message-ID: <G-XLLRFehzDQQEDQUaaa6XWKUwziWB58qIp-IJeEsFY=.c61e6535-d084-42c9-8a9c-2b6284db6ba3@github.com>

On Wed, 8 Sep 2021 10:59:27 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix merge issue

Since nobody objected for a week, this seems good to go.

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

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


From ayang at openjdk.java.net  Wed Sep  8 12:21:08 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 8 Sep 2021 12:21:08 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <9X5QX3Zh9GZ9CY9vn2KN9Wgm9I9zYKxdsLy2qHGA4T0=.ddad6723-525d-4cae-bfbc-c9759f260290@github.com>

On Wed, 8 Sep 2021 11:56:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1161:

> 1159:   // the given HeapRegionClosure on each region. The worker_id will determine where
> 1160:   // in the part to start the iteration to allow for more efficient parallel iteration.
> 1161:   void par_iterate_regions_array_part_from(HeapRegionClosure* cl,

The comment needs to be updated as well. `const uint* regions` can be written as `const uint regions[]` to make the concept clearer, IMO.

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

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


From tschatzl at openjdk.java.net  Wed Sep  8 12:29:03 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 12:29:03 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <KpsNuhQ5RWtVvF3vlT0i49kXs_4GVAQuGtfAboTzBng=.f6d5c4df-bba4-4f60-8782-c25bc44024b5@github.com>

On Wed, 8 Sep 2021 11:56:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1CollectionSet.cpp line 239:

> 237:                                             hr_claimer,
> 238:                                             &_collection_set_regions[offset],
> 239:                                             length-offset,

please add spaces around the `-` operator.

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

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


From tschatzl at openjdk.java.net  Wed Sep  8 14:36:16 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 14:36:16 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang
In-Reply-To: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
Message-ID: <zNPqyz-6R-2X-kPt7nRqxsBW9nlUCBoTjHrVg15UY5Y=.371d2b11-e10d-4272-9e61-1e7c72e18247@github.com>

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden <pliden at openjdk.org> wrote:

> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
> 
> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
> 
> Testing:
>  - Passed Tier1-3
>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>  - Manually ran jcmd GC.heap_dump with various GCs enabled

Lgtm. Thanks a lot for looking into this.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep  8 15:32:19 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 15:32:19 GMT
Subject: RFR: 8273492: Move evacuation failure handling into G1YoungCollector
Message-ID: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>

Hi all,

  can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.

Testing: tier1-3

Thanks,
  Thomas

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

Commit messages:
 - Move evac failure handling to young gc

Changes: https://git.openjdk.java.net/jdk/pull/5419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5419&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273492
  Stats: 161 lines in 13 files changed: 57 ins; 48 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5419/head:pull/5419

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


From ioi.lam at oracle.com  Wed Sep  8 18:14:35 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 8 Sep 2021 11:14:35 -0700
Subject: Prepopulated SerialGC old gen causes slow GC verification
Message-ID: <5bb24c67-fcb8-f4d8-ddd8-05c4d7983699@oracle.com>

I am trying to implement JDK-8273508 - Support archived heap objects in 
SerialGC

https://github.com/openjdk/jdk/compare/master...iklam:8273508-archived-heap-objects-for-serial-gc?expand=1

My initial implementation copies the archived objects into 
SerialHeap::old_gen(). However, this causes very slow GC verification:

 ??? $ java -Xlog:gc+verify -XX:+UseSerialGC -version
 ??? [2.446s][info][gc,verify] Verifying? 1891.996ms
 ??? [4.316s][info][gc,verify] Verifying? 1864.602ms
 ??? [6.209s][info][gc,verify] Verifying? 1890.085ms
 ??? [8.090s][info][gc,verify] Verifying? 1878.792ms
 ??? [9.981s][info][gc,verify] Verifying? 1873.986ms
 ??? [11.872s][info][gc,verify] Verifying? 1887.524ms
 ??? [13.766s][info][gc,verify] Verifying? 1880.724ms
 ??? [15.609s][info][gc,verify] Verifying? 1841.357ms
 ??? [17.476s][info][gc,verify] Verifying? 1865.397ms
 ??? [19.345s][info][gc,verify] Verifying? 1865.539ms
 ??? [21.243s][info][gc,verify] Verifying? 1894.178ms
 ??? [23.116s][info][gc,verify] Verifying? 1871.097ms
 ??? [24.966s][info][gc,verify] Verifying? 1848.107ms
 ??? [26.816s][info][gc,verify] Verifying? 1848.846ms
 ??? [28.698s][info][gc,verify] Verifying? 1876.097ms
 ??? [30.609s][info][gc,verify] Verifying? 1909.611ms
 ??? java version "18-internal" 2022-03-15
 ??? Java(TM) SE Runtime Environment (fastdebug build 
18-internal+0-adhoc.iklam.open)
 ??? Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
18-internal+0-adhoc.iklam.open, mixed mode, sharing)
 ??? [32.503s][info][gc,verify] Verifying? 1879.452ms

So in my current revision, I allocate from SerialHeap::young_gen() 
instead (See the "#if 1" in serialHeap.cpp)

 ??? $ java -Xlog:gc+verify -XX:+UseSerialGC -version
 ??? [0.569s][info][gc,verify] Verifying? 10.830ms
 ??? [0.577s][info][gc,verify] Verifying? 7.724ms
 ??? [0.587s][info][gc,verify] Verifying? 7.941ms
 ??? [0.595s][info][gc,verify] Verifying? 7.937ms
 ??? [0.617s][info][gc,verify] Verifying? 10.125ms
 ??? [0.627s][info][gc,verify] Verifying? 8.932ms
 ??? [0.649s][info][gc,verify] Verifying? 9.737ms
 ??? [0.659s][info][gc,verify] Verifying? 9.194ms
 ??? [0.670s][info][gc,verify] Verifying? 8.889ms
 ??? [0.680s][info][gc,verify] Verifying? 8.752ms
 ??? [0.692s][info][gc,verify] Verifying? 9.067ms
 ??? [0.703s][info][gc,verify] Verifying? 9.924ms
 ??? [0.715s][info][gc,verify] Verifying? 9.874ms
 ??? [0.725s][info][gc,verify] Verifying? 9.164ms
 ??? [0.740s][info][gc,verify] Verifying? 9.282ms
 ??? [0.751s][info][gc,verify] Verifying? 9.383ms
 ??? java version "18-internal" 2022-03-15
 ??? Java(TM) SE Runtime Environment (fastdebug build 
18-internal+0-adhoc.iklam.open)
 ??? Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
18-internal+0-adhoc.iklam.open, mixed mode, sharing)
 ??? [0.767s][info][gc,verify] Verifying? 10.270ms

Does anyone know how to fix this properly?

Thanks
- Ioi



From thomas.schatzl at oracle.com  Wed Sep  8 19:05:04 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 8 Sep 2021 21:05:04 +0200
Subject: Prepopulated SerialGC old gen causes slow GC verification
In-Reply-To: <5bb24c67-fcb8-f4d8-ddd8-05c4d7983699@oracle.com>
References: <5bb24c67-fcb8-f4d8-ddd8-05c4d7983699@oracle.com>
Message-ID: <df11e15e-f90e-7f32-5bff-02eb4aad82a1@oracle.com>

Hi,

On 08.09.21 20:14, Ioi Lam wrote:
> I am trying to implement JDK-8273508 - Support archived heap objects in 
> SerialGC
> 
> https://github.com/openjdk/jdk/compare/master...iklam:8273508-archived-heap-objects-for-serial-gc?expand=1 
> 
> 
> My initial implementation copies the archived objects into 
> SerialHeap::old_gen(). However, this causes very slow GC verification:

Maybe the verification does odd things that need a good BOT (that it 
does not do in young gen)? Just a guess.

Thanks,
   Thomas


From tschatzl at openjdk.java.net  Wed Sep  8 19:15:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 19:15:56 GMT
Subject: RFR: 8273185: Rename the term "atomic" in ReferenceProcessor [v2]
In-Reply-To: <Oam6IN8oihWLlwULwjbJF3Ld5livaciOaQvqMaQbKPM=.eabe9484-8f50-4436-aac4-818460f216bf@github.com>
References: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
 <Oam6IN8oihWLlwULwjbJF3Ld5livaciOaQvqMaQbKPM=.eabe9484-8f50-4436-aac4-818460f216bf@github.com>
Message-ID: <SMMGknQUBHlm3InBrUDOUGo9n3R_gFijhxi2H9MiUwQ=.9807b4fc-e6b5-40cb-b2b5-4c7b9cc5be4b@github.com>

On Wed, 8 Sep 2021 08:38:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this suggestion to rename the term "atomic" in the `ReferenceProcessor` class to "concurrent"/"stw" to avoid the confusion with Atomic operations.
>> 
>> It's a smaller change than expected, which is good, but also might question the need for this change. I grepped for "atomic" in the reference processor sources and hopefully got everything.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   shade review

I looked through the GHA failures, none of that related to this change.

Thanks @shipilev @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Sep  8 19:16:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 8 Sep 2021 19:16:05 GMT
Subject: Integrated: 8273185: Rename the term "atomic" in ReferenceProcessor
In-Reply-To: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
References: <7kRmpwBFNkieRgEt8BnpK6WT-n3A1Ra9a-mA-HDiGCs=.645329f2-8b9a-48e6-ad88-5e13056d0d63@github.com>
Message-ID: <plaAsBZU17vIIXQwUcAiKTFOspmhgBWhDPedmfXtW9c=.6f4b7085-5859-46c0-8adb-abf94a189774@github.com>

On Tue, 7 Sep 2021 18:58:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this suggestion to rename the term "atomic" in the `ReferenceProcessor` class to "concurrent"/"stw" to avoid the confusion with Atomic operations.
> 
> It's a smaller change than expected, which is good, but also might question the need for this change. I grepped for "atomic" in the reference processor sources and hopefully got everything.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: e6805032
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e6805032ff328773eafe8b94e9f1b3b196f52196
Stats:     36 lines in 4 files changed: 1 ins; 2 del; 33 mod

8273185: Rename the term "atomic" in ReferenceProcessor

Reviewed-by: ayang, shade

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

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


From ioi.lam at oracle.com  Wed Sep  8 20:33:08 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Wed, 8 Sep 2021 13:33:08 -0700
Subject: Prepopulated SerialGC old gen causes slow GC verification
In-Reply-To: <df11e15e-f90e-7f32-5bff-02eb4aad82a1@oracle.com>
References: <5bb24c67-fcb8-f4d8-ddd8-05c4d7983699@oracle.com>
 <df11e15e-f90e-7f32-5bff-02eb4aad82a1@oracle.com>
Message-ID: <70fc4f6a-c493-0de4-de84-b9d98320d386@oracle.com>



On 9/8/21 12:05 PM, Thomas Schatzl wrote:
> Hi,
>
> On 08.09.21 20:14, Ioi Lam wrote:
>> I am trying to implement JDK-8273508 - Support archived heap objects 
>> in SerialGC
>>
>> https://github.com/openjdk/jdk/compare/master...iklam:8273508-archived-heap-objects-for-serial-gc?expand=1 
>>
>>
>> My initial implementation copies the archived objects into 
>> SerialHeap::old_gen(). However, this causes very slow GC verification:
>
> Maybe the verification does odd things that need a good BOT (that it 
> does not do in young gen)? Just a guess.
>

What is a BOT? :-)

I noticed that after a GC has happened, then the verification would be 
much faster. A GC could be triggered by specifying 
-XX:+VerifyArchivedFields. See? verify_the_heap() in heapShared.cpp.

So can I get a BOT without triggering a GC?

    $ java -XX:+UseSerialGC -Xlog:gc+verify -XX:+VerifyArchivedFields
    -version
    [2.547s][info][gc,verify] Verifying 1997.929ms
    [4.398s][info][gc,verify] Verifying 1844.962ms
    [6.280s][info][gc,verify] Verifying 1879.111ms
    [8.185s][info][gc,verify] Verifying 1903.419ms
    [10.070s][info][gc,verify] Verifying 1870.905ms
    [11.937s][info][gc,verify] Verifying 1863.947ms
    [13.810s][info][gc,verify] Verifying 1854.141ms
    <GC triggered by -XX:+VerifyArchivedFields>
    [15.650s][info][gc,verify] GC(0) Verifying Before GC 1837.002ms
    [15.691s][info][gc,verify] GC(0) Verifying After GC 16.058ms
    [15.709s][info][gc,verify] Verifying 15.269ms
    [15.724s][info][gc,verify] GC(1) Verifying Before GC 14.672ms
    [15.755s][info][gc,verify] GC(1) Verifying After GC 16.056ms
    [15.771s][info][gc,verify] Verifying 16.212ms
    ....

Thanks
- Ioi


From kbarrett at openjdk.java.net  Wed Sep  8 23:45:02 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 8 Sep 2021 23:45:02 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang
In-Reply-To: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
Message-ID: <R4_iDo97fM8gCp7-8ycVTJoqJNlB6wQZIPvPYZww4R4=.cce31328-c2ca-4c03-8785-498197a8d405@github.com>

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden <pliden at openjdk.org> wrote:

> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
> 
> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
> 
> Testing:
>  - Passed Tier1-3
>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>  - Manually ran jcmd GC.heap_dump with various GCs enabled

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Wed Sep  8 23:48:58 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 8 Sep 2021 23:48:58 GMT
Subject: RFR: 8273439: Fix G1CollectedHeap includes and forward
 declarations
In-Reply-To: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
References: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
Message-ID: <nfjNufpC22QDdlN9GXgLWZwICjJWIsP933_iDpMZFU4=.979d4125-e1a1-46d6-a799-ed37bb45f96d@github.com>

On Tue, 7 Sep 2021 15:40:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that
>   * removes unnecessary includes (just one actually)
>   * removes unnecessary forwards (either not used, or already covered by the #include declaration)
>   * sorts the forward declarations
>   * adds necessary forwards that were not directly included
> 
> Testing: building on various platforms
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From zgu at openjdk.java.net  Thu Sep  9 00:07:23 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 9 Sep 2021 00:07:23 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah
Message-ID: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>

To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.

I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.

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

Commit messages:
 - 8271834: TestStringDeduplicationAgeThreshold intermittent failures on Shenandoah

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

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


From mli at openjdk.java.net  Thu Sep  9 00:44:06 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 00:44:06 GMT
Subject: RFR: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo [v4]
In-Reply-To: <G-XLLRFehzDQQEDQUaaa6XWKUwziWB58qIp-IJeEsFY=.c61e6535-d084-42c9-8a9c-2b6284db6ba3@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
 <JM6OEEDxKor4iuednuz-JVQ3DBgJ_igIJF9z26MsH4E=.8cec8822-df1f-4e0f-8884-df821f077a39@github.com>
 <G-XLLRFehzDQQEDQUaaa6XWKUwziWB58qIp-IJeEsFY=.c61e6535-d084-42c9-8a9c-2b6284db6ba3@github.com>
Message-ID: <aBkNAhJFck2eglFzj7402J0iIP0DKNg8nTk426guH-U=.2e3f9ce0-3b6e-44d9-9053-df876ae8802a@github.com>

On Wed, 8 Sep 2021 12:03:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix merge issue
>
> Since nobody objected for a week, this seems good to go.

Thanks for your reviews, @tschatzl @albertnetymk

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

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


From mli at openjdk.java.net  Thu Sep  9 00:44:08 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 00:44:08 GMT
Subject: Integrated: 8273218: G1: Rename g1EvacuationInfo to g1EvacInfo
In-Reply-To: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
References: <lVxSiNkgFdkV-IlHDBp3Xr_iDuMPSBOcVrvOqnfVPNY=.bde5bc5a-7903-4498-b71f-220b39fcd21d@github.com>
Message-ID: <FUiGz1ZMOWb-iKH9BIcsrcZCm1Mh6Qyiq86OkTTiEm0=.61d01f4a-a1c0-405f-9176-1f60c6a4993c@github.com>

On Wed, 1 Sep 2021 05:37:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor cleanup to rename g1EvacuationInfo to g1EvacInfo, as other similar files are named as EvacXxx.

This pull request has now been integrated.

Changeset: 5df26480
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5df26480864f1efd16eb5800833bf7106371b97a
Stats:     41 lines in 9 files changed: 1 ins; 1 del; 39 mod

8273218: G1: Rename g1EvacuationInfo to g1EvacInfo

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Thu Sep  9 01:10:37 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 01:10:37 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v2]
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <lLO-PlgzXUHbujOYNkShUb4VN-iuOEJWzNnvncvSDwI=.aa330484-d8e3-41ab-87ac-2648c0276626@github.com>

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

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

  refine comments and code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5414/files
  - new: https://git.openjdk.java.net/jdk/pull/5414/files/6292fd20..78da4ce7

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

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

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


From mli at openjdk.java.net  Thu Sep  9 01:10:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 01:10:41 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v2]
In-Reply-To: <9X5QX3Zh9GZ9CY9vn2KN9Wgm9I9zYKxdsLy2qHGA4T0=.ddad6723-525d-4cae-bfbc-c9759f260290@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <9X5QX3Zh9GZ9CY9vn2KN9Wgm9I9zYKxdsLy2qHGA4T0=.ddad6723-525d-4cae-bfbc-c9759f260290@github.com>
Message-ID: <QoAgKH02Tat3oQe-4YxoYIN1ZCkC9jyqZhH3hCZkGFQ=.531f29fe-87f6-483f-8dd4-05e6155278c5@github.com>

On Wed, 8 Sep 2021 12:17:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   refine comments and code
>
> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1161:
> 
>> 1159:   // the given HeapRegionClosure on each region. The worker_id will determine where
>> 1160:   // in the part to start the iteration to allow for more efficient parallel iteration.
>> 1161:   void par_iterate_regions_array_part_from(HeapRegionClosure* cl,
> 
> The comment needs to be updated as well. `const uint* regions` can be written as `const uint regions[]` to make the concept clearer, IMO.

I have modified the function name too.

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

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


From mli at openjdk.java.net  Thu Sep  9 04:12:26 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 04:12:26 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v3]
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <qbHUjZKzCxf7JMLybO21Wu9xhPLsmOi_xkDtcbOTSZY=.6531e693-e2e8-43f2-b7e9-335bbf469637@github.com>

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

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

  Fix assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5414/files
  - new: https://git.openjdk.java.net/jdk/pull/5414/files/78da4ce7..489947ad

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

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

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


From mli at openjdk.java.net  Thu Sep  9 06:47:26 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 06:47:26 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

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

  Fix issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5414/files
  - new: https://git.openjdk.java.net/jdk/pull/5414/files/489947ad..46d5a3cc

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

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

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


From tschatzl at openjdk.java.net  Thu Sep  9 07:31:01 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 07:31:01 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
Message-ID: <SaGHv-YloGmVl29xE_V9gF21uPUYMFAktJJMOU5R3GU=.3720d91f-cdcb-40ce-b177-7637886bd1df@github.com>

On Thu, 9 Sep 2021 06:47:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
>> The parameters and logic of this method could be refined a bit to make it more straight.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Sep  9 07:32:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 07:32:09 GMT
Subject: RFR: 8273439: Fix G1CollectedHeap includes and forward
 declarations
In-Reply-To: <nfjNufpC22QDdlN9GXgLWZwICjJWIsP933_iDpMZFU4=.979d4125-e1a1-46d6-a799-ed37bb45f96d@github.com>
References: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
 <nfjNufpC22QDdlN9GXgLWZwICjJWIsP933_iDpMZFU4=.979d4125-e1a1-46d6-a799-ed37bb45f96d@github.com>
Message-ID: <2N44qkjqXF-hSSocQ3ilmxxrXWSqaaTWyRLpMy4m8fg=.0d903b25-a2fe-430c-b263-94bdd67c1ec0@github.com>

On Wed, 8 Sep 2021 23:46:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that
>>   * removes unnecessary includes (just one actually)
>>   * removes unnecessary forwards (either not used, or already covered by the #include declaration)
>>   * sorts the forward declarations
>>   * adds necessary forwards that were not directly included
>> 
>> Testing: building on various platforms
>> 
>> Thanks,
>>   Thomas
>
> Looks good.

Thanks @kimbarrett @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Sep  9 07:32:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 07:32:09 GMT
Subject: Integrated: 8273439: Fix G1CollectedHeap includes and forward
 declarations
In-Reply-To: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
References: <pj0LEEeDi6g2OhyCT-s1OSEsqjjjcdXjh8jFqLgswRs=.ced579db-747b-42c4-aedc-52f0ee87458e@github.com>
Message-ID: <q3HhQBkwkATEXWQO0ZncArtpZujEV3vh3n5fscFG-Q4=.2f8c1d60-01ef-4cab-89bc-d2942f886156@github.com>

On Tue, 7 Sep 2021 15:40:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that
>   * removes unnecessary includes (just one actually)
>   * removes unnecessary forwards (either not used, or already covered by the #include declaration)
>   * sorts the forward declarations
>   * adds necessary forwards that were not directly included
> 
> Testing: building on various platforms
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 5b1dfe4e
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5b1dfe4e358d249aef9330e39b6404a13b4ebc0e
Stats:     38 lines in 1 file changed: 7 ins; 23 del; 8 mod

8273439: Fix G1CollectedHeap includes and forward declarations

Reviewed-by: ayang, kbarrett

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

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


From thomas.schatzl at oracle.com  Thu Sep  9 08:09:11 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 9 Sep 2021 10:09:11 +0200
Subject: Prepopulated SerialGC old gen causes slow GC verification
In-Reply-To: <70fc4f6a-c493-0de4-de84-b9d98320d386@oracle.com>
References: <5bb24c67-fcb8-f4d8-ddd8-05c4d7983699@oracle.com>
 <df11e15e-f90e-7f32-5bff-02eb4aad82a1@oracle.com>
 <70fc4f6a-c493-0de4-de84-b9d98320d386@oracle.com>
Message-ID: <f4e46fab-b4c2-ecf8-5af0-3886d68d4ec8@oracle.com>

Hi,

On 08.09.21 22:33, Ioi Lam wrote:
> 
> 
> On 9/8/21 12:05 PM, Thomas Schatzl wrote:
>> Hi,
>>
>> On 08.09.21 20:14, Ioi Lam wrote:
>>> I am trying to implement JDK-8273508 - Support archived heap objects 
>>> in SerialGC
>>>
>>> https://github.com/openjdk/jdk/compare/master...iklam:8273508-archived-heap-objects-for-serial-gc?expand=1 
>>>
>>>
>>> My initial implementation copies the archived objects into 
>>> SerialHeap::old_gen(). However, this causes very slow GC verification:
>>
>> Maybe the verification does odd things that need a good BOT (that it 
>> does not do in young gen)? Just a guess.
>>
> 
> What is a BOT? :-)

Block offset table :) It's a shortcut table recording for every card 
(512 byte area) where in the previous card the next object start is. 
I.e. if you have just a HeapWord* and want to know what object is there 
or walk the heap from that location, the GC looks in the corresponding 
BOT table entry where the next object start is, and then walks to that 
HeapWord* from there.

Otherwise it needs to start walking to that location from the start of 
the generation because it does not know. That might take a while... 
(considering you need to do this for *every* object).

But a quick hack showed that this is not the issue here (if I got it right).

Thomas


From tschatzl at openjdk.java.net  Thu Sep  9 08:09:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 08:09:06 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
Message-ID: <s_e-GiVt_N_-48zaVJray-mPb27NApn20gjqNdS-sIY=.b4a9f718-7988-4648-8201-eaa4228b90a3@github.com>

On Thu, 9 Sep 2021 06:47:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
>> The parameters and logic of this method could be refined a bit to make it more straight.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1CollectionSet.cpp line 238:

> 236:                                   hr_claimer,
> 237:                                   &_collection_set_regions[offset],
> 238:                                   length,

This should be `length - offset`, shouldn't it?

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

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


From ayang at openjdk.java.net  Thu Sep  9 08:14:01 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 9 Sep 2021 08:14:01 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
Message-ID: <A15rR1BpuZExqFRubvo_8Fu9yof0SToUqOos8UXoaUQ=.f181f786-cecd-48de-858b-a3765ac5aafe@github.com>

On Thu, 9 Sep 2021 06:47:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
>> The parameters and logic of this method could be refined a bit to make it more straight.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1158:

> 1156:   }
> 1157:   void collection_set_iterate_increment_from(HeapRegionClosure *blk, HeapRegionClaimer* hr_claimer, uint worker_id);
> 1158:   // Iterate an array of region indexes given by offset and length, applying

Since there's no `offset` in the signature, how about "Iterate over the array, `uint regions[length]`, applying ..."?

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

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


From mli at openjdk.java.net  Thu Sep  9 09:13:58 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 09:13:58 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <A15rR1BpuZExqFRubvo_8Fu9yof0SToUqOos8UXoaUQ=.f181f786-cecd-48de-858b-a3765ac5aafe@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
 <A15rR1BpuZExqFRubvo_8Fu9yof0SToUqOos8UXoaUQ=.f181f786-cecd-48de-858b-a3765ac5aafe@github.com>
Message-ID: <ndbvlWW2_Vgmstahgbgze3HN4wlcJq9EszukIrkBcEs=.4cc954f7-52a7-4ab6-83fc-049af6fe1650@github.com>

On Thu, 9 Sep 2021 08:11:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue
>
> src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1158:
> 
>> 1156:   }
>> 1157:   void collection_set_iterate_increment_from(HeapRegionClosure *blk, HeapRegionClaimer* hr_claimer, uint worker_id);
>> 1158:   // Iterate an array of region indexes given by offset and length, applying
> 
> Since there's no `offset` in the signature, how about "Iterate over the array, `uint regions[length]`, applying ..."?

Sure.

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

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


From tschatzl at openjdk.java.net  Thu Sep  9 09:13:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 09:13:59 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <s_e-GiVt_N_-48zaVJray-mPb27NApn20gjqNdS-sIY=.b4a9f718-7988-4648-8201-eaa4228b90a3@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
 <s_e-GiVt_N_-48zaVJray-mPb27NApn20gjqNdS-sIY=.b4a9f718-7988-4648-8201-eaa4228b90a3@github.com>
Message-ID: <igancGsSvEi7WnlYELB9z44hKNq9W_kzJMx_gX5h-A0=.f0c00a48-704c-44cf-a382-4ec648f3414f@github.com>

On Thu, 9 Sep 2021 08:05:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue
>
> src/hotspot/share/gc/g1/g1CollectionSet.cpp line 238:
> 
>> 236:                                   hr_claimer,
>> 237:                                   &_collection_set_regions[offset],
>> 238:                                   length,
> 
> This should be `length - offset`, shouldn't it?

Suggestion:

                                  length - offset,


Untested :)

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

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


From mli at openjdk.java.net  Thu Sep  9 09:14:00 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 09:14:00 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <igancGsSvEi7WnlYELB9z44hKNq9W_kzJMx_gX5h-A0=.f0c00a48-704c-44cf-a382-4ec648f3414f@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
 <s_e-GiVt_N_-48zaVJray-mPb27NApn20gjqNdS-sIY=.b4a9f718-7988-4648-8201-eaa4228b90a3@github.com>
 <igancGsSvEi7WnlYELB9z44hKNq9W_kzJMx_gX5h-A0=.f0c00a48-704c-44cf-a382-4ec648f3414f@github.com>
Message-ID: <wp4MwcTpXykcVwFELJKmo2-aSb9be3bOntGRqga1gko=.43aca569-e43e-4f4c-871b-d7ca4c58b50c@github.com>

On Thu, 9 Sep 2021 09:06:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectionSet.cpp line 238:
>> 
>>> 236:                                   hr_claimer,
>>> 237:                                   &_collection_set_regions[offset],
>>> 238:                                   length,
>> 
>> This should be `length - offset`, shouldn't it?
>
> Suggestion:
> 
>                                   length - offset,
> 
> 
> Untested :)

I thought so too at first, but seems it's not.
The passed in length in both G1CollectionSet::par_iterate/iterate_incremental_part_from are both the length of the "sub" array already. ( increment_length() is passed as length in iterate_incremental_part_from)
How do you think about it?

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

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


From tschatzl at openjdk.java.net  Thu Sep  9 09:19:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 09:19:07 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
Message-ID: <eX9Op15le-r9YgAQ_Ki0BcVd-_z_Exu_J_5EflOk_hM=.fe6dad35-e855-4862-a75b-ac2656baa2e4@github.com>

On Thu, 9 Sep 2021 06:47:26 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
>> The parameters and logic of this method could be refined a bit to make it more straight.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix issue

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Sep  9 09:19:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 9 Sep 2021 09:19:07 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <wp4MwcTpXykcVwFELJKmo2-aSb9be3bOntGRqga1gko=.43aca569-e43e-4f4c-871b-d7ca4c58b50c@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
 <s_e-GiVt_N_-48zaVJray-mPb27NApn20gjqNdS-sIY=.b4a9f718-7988-4648-8201-eaa4228b90a3@github.com>
 <igancGsSvEi7WnlYELB9z44hKNq9W_kzJMx_gX5h-A0=.f0c00a48-704c-44cf-a382-4ec648f3414f@github.com>
 <wp4MwcTpXykcVwFELJKmo2-aSb9be3bOntGRqga1gko=.43aca569-e43e-4f4c-871b-d7ca4c58b50c@github.com>
Message-ID: <3FNN8tvHvVGkmXapMoJPFFy1Xx4fH54_zmtj0edsSCs=.f31b6492-d0a5-492d-ab4f-d0373a9bf271@github.com>

On Thu, 9 Sep 2021 09:10:01 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Suggestion:
>> 
>>                                   length - offset,
>> 
>> 
>> Untested :)
>
> I thought so too at first, but seems it's not.
> The passed in length in both G1CollectionSet::par_iterate/iterate_incremental_part_from are both the length of the "sub" array already. ( increment_length() is passed as length in iterate_incremental_part_from)
> How do you think about it?

You are right.

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

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


From mli at openjdk.java.net  Thu Sep  9 09:28:23 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 09:28:23 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v5]
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <lFcHpRab-b4TitSAo67vePBTioJF2Uohx6_w-V7m1uc=.b9d7fa47-abdf-4896-af8e-6f446b90a0b1@github.com>

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

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

  Refine comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5414/files
  - new: https://git.openjdk.java.net/jdk/pull/5414/files/46d5a3cc..af020d67

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

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

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


From mli at openjdk.java.net  Thu Sep  9 09:37:07 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 09:37:07 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v5]
In-Reply-To: <lFcHpRab-b4TitSAo67vePBTioJF2Uohx6_w-V7m1uc=.b9d7fa47-abdf-4896-af8e-6f446b90a0b1@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <lFcHpRab-b4TitSAo67vePBTioJF2Uohx6_w-V7m1uc=.b9d7fa47-abdf-4896-af8e-6f446b90a0b1@github.com>
Message-ID: <f6Fjcoku7OYn_RRkmISRit872HHjR7dSJaxNU0W8tSE=.d1107450-ae31-4228-86cc-46f899bd8bf1@github.com>

On Thu, 9 Sep 2021 09:28:23 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
>> The parameters and logic of this method could be refined a bit to make it more straight.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine comments

I cancel the pre-submit tests for "Refine comments", the last successful run is at here https://github.com/Hamlin-Li/jdk/actions/runs/1216226352

Please kindly let me know if you have other comments, else I will push this later.

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

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


From per.liden at oracle.com  Thu Sep  9 09:48:57 2021
From: per.liden at oracle.com (Per Liden)
Date: Thu, 9 Sep 2021 11:48:57 +0200
Subject: Shenandoah: Question about asserts
Message-ID: <62b8cbe3-93b2-fc79-a417-1d768a8584ec@oracle.com>

Hi Shenandoah-folks,

When doing some random testing of 
https://github.com/openjdk/jdk/pull/5410 I noticed that Shenandoah ran 
into a few asserts during heap dumping. The asserts check that we're 
executing in the VM thread. However, I wonder if these asserts might be 
a bit too aggressive, or if there's a reason these functions must only 
be executed by the VM thread? I couldn't see any obvious reason, so I 
simply removed the offending asserts (see patch below) and nothing 
obvious seems to break (heap dumping tests now pass, etc).

So, would you mind if I remove these asserts, or are they really needed 
for some reason I've missed?

cheers,
Per


diff --git a/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp 
b/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
index ca9afd7ad4f..623ca9574a2 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
@@ -355,7 +355,6 @@ 
ShenandoahCodeRootsIterator::ShenandoahCodeRootsIterator() :
          _par_iterator(CodeCache::heaps()),
          _table_snapshot(NULL) {
    assert(SafepointSynchronize::is_at_safepoint(), "Must be at safepoint");
-  assert(!Thread::current()->is_Worker_thread(), "Should not be 
acquired by workers");
    CodeCache_lock->lock_without_safepoint_check();
    _table_snapshot = 
ShenandoahCodeRoots::table()->snapshot_for_iteration();
  }
diff --git a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp 
b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
index c0469a71d7b..261920a9d7a 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
@@ -258,7 +258,6 @@ 
ShenandoahHeapIterationRootScanner::ShenandoahHeapIterationRootScanner() :
   }

   void ShenandoahHeapIterationRootScanner::roots_do(OopClosure* oops) {
-   assert(Thread::current()->is_VM_thread(), "Only by VM thread");
     // Must use _claim_none to avoid interfering with concurrent CLDG 
iteration
     CLDToOopClosure clds(oops, ClassLoaderData::_claim_none);
     MarkingCodeBlobClosure code(oops, 
!CodeBlobToOopClosure::FixRelocations);
diff --git 
a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp 
b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
index 3f614d1e208..b2897d380aa 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
@@ -86,9 +86,8 @@ ShenandoahClassLoaderDataRoots<CONCURRENT, 
SINGLE_THREADED>::ShenandoahClassLoad
      ClassLoaderDataGraph_lock->lock();
    }

-  // Non-concurrent mode only runs at safepoints by VM thread
+  // Non-concurrent mode only runs at safepoints
    assert(CONCURRENT || SafepointSynchronize::is_at_safepoint(), "Must 
be at a safepoint");
-  assert(CONCURRENT || Thread::current()->is_VM_thread(), "Can only be 
done by VM thread");
  }

  template <bool CONCURRENT, bool SINGLE_THREADED>


From ayang at openjdk.java.net  Thu Sep  9 09:59:00 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 9 Sep 2021 09:59:00 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v5]
In-Reply-To: <lFcHpRab-b4TitSAo67vePBTioJF2Uohx6_w-V7m1uc=.b9d7fa47-abdf-4896-af8e-6f446b90a0b1@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <lFcHpRab-b4TitSAo67vePBTioJF2Uohx6_w-V7m1uc=.b9d7fa47-abdf-4896-af8e-6f446b90a0b1@github.com>
Message-ID: <IYNTsGbUdcbmw8xpSp-7bf_s_tt7OQilRsbR07Lx6Ho=.0a13ebeb-a154-44f1-b174-9f336d4dc36b@github.com>

On Thu, 9 Sep 2021 09:28:23 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
>> The parameters and logic of this method could be refined a bit to make it more straight.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refine comments

Marked as reviewed by ayang (Reviewer).

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

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


From mli at openjdk.java.net  Thu Sep  9 10:45:02 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 10:45:02 GMT
Subject: RFR: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from [v4]
In-Reply-To: <eX9Op15le-r9YgAQ_Ki0BcVd-_z_Exu_J_5EflOk_hM=.fe6dad35-e855-4862-a75b-ac2656baa2e4@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
 <V7n-j6RF9k9-RuteEwdN5sD0rW43BzBKn4r3LT2WX4c=.a8c1fa0b-7ab9-470b-9e73-f9d4a746efaa@github.com>
 <eX9Op15le-r9YgAQ_Ki0BcVd-_z_Exu_J_5EflOk_hM=.fe6dad35-e855-4862-a75b-ac2656baa2e4@github.com>
Message-ID: <trI1LejlM-y9NgRbjdi1muyG79Wog7YGk3jIRyxdvyc=.57c6333d-57bd-45ba-9eb7-dd55f2d751d3@github.com>

On Thu, 9 Sep 2021 09:16:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix issue
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for your reviews, @tschatzl @albertnetymk

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

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


From mli at openjdk.java.net  Thu Sep  9 10:45:03 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 9 Sep 2021 10:45:03 GMT
Subject: Integrated: 8273476: G1: refine
 G1CollectedHeap::par_iterate_regions_array_part_from
In-Reply-To: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
References: <CF-bePTEeJRyKRwx7PVlxpiPCziO2qbZwptRZFe5ZH8=.5ff29edf-e016-4d76-8ea7-fd18eca3cd0a@github.com>
Message-ID: <fyhIq7MRCc66kKGxqcA2ByYDfMZeCtr_ayUzdmm3eMs=.dc9cbf64-6151-4982-8e7f-fb381a72215f@github.com>

On Wed, 8 Sep 2021 11:56:14 GMT, Hamlin Li <mli at openjdk.org> wrote:

> G1CollectedHeap::par_iterate_regions_array_part_from is moved from G1CollectionSet::iterate_part_from in JDK-8254167.
> The parameters and logic of this method could be refined a bit to make it more straight.

This pull request has now been integrated.

Changeset: 9690df7f
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9690df7fb9843bdc4775a34d94b2ca81f40aea0a
Stats:     26 lines in 4 files changed: 4 ins; 3 del; 19 mod

8273476: G1: refine G1CollectedHeap::par_iterate_regions_array_part_from

Reviewed-by: ayang, tschatzl

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

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


From zgu at redhat.com  Thu Sep  9 14:22:10 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 9 Sep 2021 10:22:10 -0400
Subject: Shenandoah: Question about asserts
In-Reply-To: <62b8cbe3-93b2-fc79-a417-1d768a8584ec@oracle.com>
References: <62b8cbe3-93b2-fc79-a417-1d768a8584ec@oracle.com>
Message-ID: <aca6778f-3829-327e-71c2-8a36cb446d53@redhat.com>

Hi Per,

Shenandoah heap dump was designed to be single-threaded. It looks like 
that JDK-8237354 breaks that.

Feel free to remove the assertions to unblock your work. I will file a 
bug to fix Shenandoah heap dump.

Thanks,

-Zhengyu

On 9/9/21 5:48 AM, Per Liden wrote:
> Hi Shenandoah-folks,
> 
> When doing some random testing of 
> https://github.com/openjdk/jdk/pull/5410 I noticed that Shenandoah ran 
> into a few asserts during heap dumping. The asserts check that we're 
> executing in the VM thread. However, I wonder if these asserts might be 
> a bit too aggressive, or if there's a reason these functions must only 
> be executed by the VM thread? I couldn't see any obvious reason, so I 
> simply removed the offending asserts (see patch below) and nothing 
> obvious seems to break (heap dumping tests now pass, etc).
> 
> So, would you mind if I remove these asserts, or are they really needed 
> for some reason I've missed?
> 
> cheers,
> Per
> 
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp 
> b/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
> index ca9afd7ad4f..623ca9574a2 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
> @@ -355,7 +355,6 @@ 
> ShenandoahCodeRootsIterator::ShenandoahCodeRootsIterator() :
>  ???????? _par_iterator(CodeCache::heaps()),
>  ???????? _table_snapshot(NULL) {
>  ?? assert(SafepointSynchronize::is_at_safepoint(), "Must be at 
> safepoint");
> -? assert(!Thread::current()->is_Worker_thread(), "Should not be 
> acquired by workers");
>  ?? CodeCache_lock->lock_without_safepoint_check();
>  ?? _table_snapshot = 
> ShenandoahCodeRoots::table()->snapshot_for_iteration();
>  ?}
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp 
> b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
> index c0469a71d7b..261920a9d7a 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
> @@ -258,7 +258,6 @@ 
> ShenandoahHeapIterationRootScanner::ShenandoahHeapIterationRootScanner() :
>  ? }
> 
>  ? void ShenandoahHeapIterationRootScanner::roots_do(OopClosure* oops) {
> -?? assert(Thread::current()->is_VM_thread(), "Only by VM thread");
>  ??? // Must use _claim_none to avoid interfering with concurrent CLDG 
> iteration
>  ??? CLDToOopClosure clds(oops, ClassLoaderData::_claim_none);
>  ??? MarkingCodeBlobClosure code(oops, 
> !CodeBlobToOopClosure::FixRelocations);
> diff --git 
> a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp 
> b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
> index 3f614d1e208..b2897d380aa 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
> @@ -86,9 +86,8 @@ ShenandoahClassLoaderDataRoots<CONCURRENT, 
> SINGLE_THREADED>::ShenandoahClassLoad
>  ???? ClassLoaderDataGraph_lock->lock();
>  ?? }
> 
> -? // Non-concurrent mode only runs at safepoints by VM thread
> +? // Non-concurrent mode only runs at safepoints
>  ?? assert(CONCURRENT || SafepointSynchronize::is_at_safepoint(), "Must 
> be at a safepoint");
> -? assert(CONCURRENT || Thread::current()->is_VM_thread(), "Can only be 
> done by VM thread");
>  ?}
> 
>  ?template <bool CONCURRENT, bool SINGLE_THREADED>
> 



From per.liden at oracle.com  Thu Sep  9 17:07:51 2021
From: per.liden at oracle.com (Per Liden)
Date: Thu, 9 Sep 2021 19:07:51 +0200
Subject: Shenandoah: Question about asserts
In-Reply-To: <aca6778f-3829-327e-71c2-8a36cb446d53@redhat.com>
References: <62b8cbe3-93b2-fc79-a417-1d768a8584ec@oracle.com>
 <aca6778f-3829-327e-71c2-8a36cb446d53@redhat.com>
Message-ID: <568f625f-71d3-ed62-261e-e1c7fbe093ed@oracle.com>

Ok, thanks Zhengyu! I'll update my PR to include the removal of the asserts.

cheers,
Per


On 9/9/21 4:22 PM, Zhengyu Gu wrote:
> Hi Per,
> 
> Shenandoah heap dump was designed to be single-threaded. It looks like 
> that JDK-8237354 breaks that.
> 
> Feel free to remove the assertions to unblock your work. I will file a 
> bug to fix Shenandoah heap dump.
> 
> Thanks,
> 
> -Zhengyu
> 
> On 9/9/21 5:48 AM, Per Liden wrote:
>> Hi Shenandoah-folks,
>>
>> When doing some random testing of 
>> https://github.com/openjdk/jdk/pull/5410 I noticed that Shenandoah ran 
>> into a few asserts during heap dumping. The asserts check that we're 
>> executing in the VM thread. However, I wonder if these asserts might 
>> be a bit too aggressive, or if there's a reason these functions must 
>> only be executed by the VM thread? I couldn't see any obvious reason, 
>> so I simply removed the offending asserts (see patch below) and 
>> nothing obvious seems to break (heap dumping tests now pass, etc).
>>
>> So, would you mind if I remove these asserts, or are they really 
>> needed for some reason I've missed?
>>
>> cheers,
>> Per
>>
>>
>> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp 
>> b/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
>> index ca9afd7ad4f..623ca9574a2 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
>> @@ -355,7 +355,6 @@ 
>> ShenandoahCodeRootsIterator::ShenandoahCodeRootsIterator() :
>> ????????? _par_iterator(CodeCache::heaps()),
>> ????????? _table_snapshot(NULL) {
>> ??? assert(SafepointSynchronize::is_at_safepoint(), "Must be at 
>> safepoint");
>> -? assert(!Thread::current()->is_Worker_thread(), "Should not be 
>> acquired by workers");
>> ??? CodeCache_lock->lock_without_safepoint_check();
>> ??? _table_snapshot = 
>> ShenandoahCodeRoots::table()->snapshot_for_iteration();
>> ??}
>> diff --git 
>> a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp 
>> b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
>> index c0469a71d7b..261920a9d7a 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
>> @@ -258,7 +258,6 @@ 
>> ShenandoahHeapIterationRootScanner::ShenandoahHeapIterationRootScanner() 
>> :
>> ?? }
>>
>> ?? void ShenandoahHeapIterationRootScanner::roots_do(OopClosure* oops) {
>> -?? assert(Thread::current()->is_VM_thread(), "Only by VM thread");
>> ???? // Must use _claim_none to avoid interfering with concurrent CLDG 
>> iteration
>> ???? CLDToOopClosure clds(oops, ClassLoaderData::_claim_none);
>> ???? MarkingCodeBlobClosure code(oops, 
>> !CodeBlobToOopClosure::FixRelocations);
>> diff --git 
>> a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp 
>> b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
>> index 3f614d1e208..b2897d380aa 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
>> @@ -86,9 +86,8 @@ ShenandoahClassLoaderDataRoots<CONCURRENT, 
>> SINGLE_THREADED>::ShenandoahClassLoad
>> ????? ClassLoaderDataGraph_lock->lock();
>> ??? }
>>
>> -? // Non-concurrent mode only runs at safepoints by VM thread
>> +? // Non-concurrent mode only runs at safepoints
>> ??? assert(CONCURRENT || SafepointSynchronize::is_at_safepoint(), 
>> "Must be at a safepoint");
>> -? assert(CONCURRENT || Thread::current()->is_VM_thread(), "Can only 
>> be done by VM thread");
>> ??}
>>
>> ??template <bool CONCURRENT, bool SINGLE_THREADED>
>>
> 


From pliden at openjdk.java.net  Thu Sep  9 20:07:25 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 20:07:25 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]
In-Reply-To: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
Message-ID: <CxJbXxBcUbsq-eVynGaaDBZNLZOKLvXck5m8fWD1Y0o=.a32a5c3d-2d86-4bd4-96c5-4ee2abbf8ec4@github.com>

> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
> 
> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
> 
> Testing:
>  - Passed Tier1-3
>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>  - Manually ran jcmd GC.heap_dump with various GCs enabled

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

  Remove asserts

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5410/files
  - new: https://git.openjdk.java.net/jdk/pull/5410/files/74ab4a07..7a9abf0c

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

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

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


From pliden at openjdk.java.net  Thu Sep  9 20:07:26 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 9 Sep 2021 20:07:26 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang
In-Reply-To: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
Message-ID: <RfCk1pDmKO1nWkKBXHGqvw_b-eZc-Qyaj8YfiS6E9IA=.299857a4-adbd-44ed-8d2d-b0fb2152cd46@github.com>

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden <pliden at openjdk.org> wrote:

> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
> 
> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
> 
> Testing:
>  - Passed Tier1-3
>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>  - Manually ran jcmd GC.heap_dump with various GCs enabled

Patch updated include the removal of a few asserts, as discussed here: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-September/036807.html

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

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


From rschmelter at openjdk.java.net  Fri Sep 10 07:56:06 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Fri, 10 Sep 2021 07:56:06 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]
In-Reply-To: <CxJbXxBcUbsq-eVynGaaDBZNLZOKLvXck5m8fWD1Y0o=.a32a5c3d-2d86-4bd4-96c5-4ee2abbf8ec4@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
 <CxJbXxBcUbsq-eVynGaaDBZNLZOKLvXck5m8fWD1Y0o=.a32a5c3d-2d86-4bd4-96c5-4ee2abbf8ec4@github.com>
Message-ID: <GEddqj2DmJtvLBUtS588Q-QerofV5IbCIio8RHdI7VY=.e9a222d8-9f15-4582-81ca-abfe973ca3f5@github.com>

On Thu, 9 Sep 2021 20:07:25 GMT, Per Liden <pliden at openjdk.org> wrote:

>> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
>> 
>> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
>> 
>> Testing:
>>  - Passed Tier1-3
>>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>>  - Manually ran jcmd GC.heap_dump with various GCs enabled
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove asserts

The reason I've added this was, that for the shenandoah GC the heap iteration would run into assertions if not called from the VM thread. Maybe this has changed in the meantime.

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

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


From pliden at openjdk.java.net  Fri Sep 10 09:37:05 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 10 Sep 2021 09:37:05 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]
In-Reply-To: <GEddqj2DmJtvLBUtS588Q-QerofV5IbCIio8RHdI7VY=.e9a222d8-9f15-4582-81ca-abfe973ca3f5@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
 <CxJbXxBcUbsq-eVynGaaDBZNLZOKLvXck5m8fWD1Y0o=.a32a5c3d-2d86-4bd4-96c5-4ee2abbf8ec4@github.com>
 <GEddqj2DmJtvLBUtS588Q-QerofV5IbCIio8RHdI7VY=.e9a222d8-9f15-4582-81ca-abfe973ca3f5@github.com>
Message-ID: <Jj-yzBg7AndSPdz9j6a0t3VlodS5YEV6kFC1_RSe3lc=.9c5dbe88-b0e3-45bd-aace-46b8f220db57@github.com>

On Fri, 10 Sep 2021 07:52:32 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> The reason I've added this was, that for the shenandoah GC the heap iteration would run into assertions if not called from the VM thread. Maybe this has changed in the meantime.

As mentioned in my previous comment. This PR removes those asserts since they were overly strict.

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

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


From pliden at openjdk.java.net  Fri Sep 10 09:55:03 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 10 Sep 2021 09:55:03 GMT
Subject: RFR: 8273482: Remove "foreground work" concept from WorkGang [v2]
In-Reply-To: <CxJbXxBcUbsq-eVynGaaDBZNLZOKLvXck5m8fWD1Y0o=.a32a5c3d-2d86-4bd4-96c5-4ee2abbf8ec4@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
 <CxJbXxBcUbsq-eVynGaaDBZNLZOKLvXck5m8fWD1Y0o=.a32a5c3d-2d86-4bd4-96c5-4ee2abbf8ec4@github.com>
Message-ID: <5Gehc_iIXLIEYJB8ie3y6EHL41dqz2clJ4FFze4v1pU=.39e87234-42e6-48ac-b546-21e365598623@github.com>

On Thu, 9 Sep 2021 20:07:25 GMT, Per Liden <pliden at openjdk.org> wrote:

>> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
>> 
>> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
>> 
>> Testing:
>>  - Passed Tier1-3
>>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>>  - Manually ran jcmd GC.heap_dump with various GCs enabled
>
> Per Liden has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove asserts

Thanks all for reviewing!

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

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


From pliden at openjdk.java.net  Fri Sep 10 09:55:04 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 10 Sep 2021 09:55:04 GMT
Subject: Integrated: 8273482: Remove "foreground work" concept from WorkGang
In-Reply-To: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
References: <q2JbROj2AMGyC4sBCsE13bECCgRXuC4xpvxgs-KZGsE=.6bfe0965-8653-4b2b-ae55-d4890970c8ef@github.com>
Message-ID: <pJ21J2W--nbdFEwKrAcHYatd9_EjHnTu01kRCPbUpR0=.ea6c2d36-e48d-4379-8fa8-18f253e36256@github.com>

On Wed, 8 Sep 2021 09:56:21 GMT, Per Liden <pliden at openjdk.org> wrote:

> JDK-8237354 introduced the concept of "foreground work" in WorkGang, as a special case for use by the HeapDumper. I propose that we remove this code, since this special use case can be solved without the need for the concept of "foreground work" in WorkGang.
> 
> As far as I can tell, there's no reason why it must be the VM thread that takes on the task of writing the header, iterating over roots, etc. So, in VM_HeapDumper::work(), instead of checking if the current thread is the VM thread we can just check if the worker_id is non-zero. That way, a single worker thread will take on the task of writing the header, iterating over roots, etc, and all other worker threads will continue to call worker_loop().
> 
> Testing:
>  - Passed Tier1-3
>  - Passed multiple runs of test/hotspot/jtreg/serviceability/dcmd/gc/
>  - Manually ran jcmd GC.heap_dump with various GCs enabled

This pull request has now been integrated.

Changeset: c1e39faa
Author:    Per Liden <pliden at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c1e39faaa99ee62ff626ffec9f978ed0f8ffaca1
Stats:     25 lines in 6 files changed: 0 ins; 17 del; 8 mod

8273482: Remove "foreground work" concept from WorkGang

Reviewed-by: tschatzl, kbarrett

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

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


From tschatzl at openjdk.java.net  Fri Sep 10 11:01:19 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 10 Sep 2021 11:01:19 GMT
Subject: RFR: 8273590: Move helper classes in G1 post evacuation sub tasks to
 cpp files
Message-ID: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>

Hi all,

  can I have reviews for this straightforward refactoring, moving helper classes that are not required to .cpp files. The nice side effect of this is that it removes around 100 LOC. No changes to code, except for removal of one unused local variable in
```RemoveSelfForwardPtrsTask::~RemoveSelfForwardPtrsTask`.

Testing: compilation, gha, local jtreg/gc/g1

Thanks,
  Thomas

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

Commit messages:
 - Move post evacuate helper classes to cpp file

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

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


From shade at openjdk.java.net  Fri Sep 10 12:35:07 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Sep 2021 12:35:07 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah
In-Reply-To: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
Message-ID: <GDoq2UTpcqhPcNqIVbwVPby5agS7wKhFBx7K76VVwWk=.efeeb1b8-5376-44e7-9add-31209d18bd26@github.com>

On Wed, 8 Sep 2021 23:59:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
> 
> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.

It looks okay to me, but others need to have a look.

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 102:

> 100:             if (n.getType().equals(GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION)) {
> 101:                 GarbageCollectionNotificationInfo info = GarbageCollectionNotificationInfo.from((CompositeData) n.getUserData());
> 102:                 // Shenandoah GC also report GC pauses, skip them

Suggestion:

                // Shenandoah GC also reports GC pauses, skip them

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 105:

> 103:                 if (info.getGcName().startsWith("Shenandoah")) {
> 104:                     if ("end of GC cycle".equals(info.getGcAction())) {
> 105:                         gcCount ++;

Suggestion:

                        gcCount++;

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 108:

> 106:                     }
> 107:                 } else {
> 108:                     gcCount ++;

Suggestion:

                    gcCount++;

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

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


From zgu at openjdk.java.net  Fri Sep 10 12:44:39 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 10 Sep 2021 12:44:39 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v2]
In-Reply-To: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
Message-ID: <Js4dk2oC1ryXuHerj-4tqmT5LmJX1_Q9dyYefUY6R9k=.e33e19f8-3cc0-400a-9c9b-e9157c9b2d48@github.com>

> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
> 
> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.

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

  Aleksey's comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5428/files
  - new: https://git.openjdk.java.net/jdk/pull/5428/files/75eeb7e2..46170eb3

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

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

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


From tschatzl at openjdk.java.net  Fri Sep 10 12:48:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 10 Sep 2021 12:48:08 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with
 few failed objects [v7]
In-Reply-To: <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
Message-ID: <YOB-Mulmp43htos_qIbvhLr8OhA-ax_SCF-dRhh3BFw=.3e05bca1-fbb5-4f12-9943-4f2b51ef4a2f@github.com>

On Thu, 26 Aug 2021 10:04:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

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

Performance is good as is, particularly the Remove self-forwards phase is much much faster now. I added a figure to the CR [here](https://bugs.openjdk.java.net/secure/attachment/96321/20210902-remove-self-forwards-improvement.png). Really nice.

Although there are a few existing abnormalities with this change (not newly introduced, the old code is as bad), see [JDK-8273309](https://bugs.openjdk.java.net/browse/JDK-8273309).

There are a few things that need to be improved:
* we talked about this before, but I do not think putting `G1EvacuationFailureObjsInHR`, which is something only used in evacuation failure, into `HeapRegion`, should be done. At least at the moment, it is almost never used.
* I do not like the use and the implementation of `G1EvacuationFailureObjsInHR`: it recreates something thatt is done better elsewhere (mark stack, DCQS buffer allocator, and in particular in the remembered set cardset allocator) with less features, in a non-fitting style.
Examples are something like reuse of available chunks, concurrent freeing of chunks, automatic resizing of blocks on demand to decrease allocations and potentially other stuff seems something we would really really want.
* as far as I understand the implementation of `G1EvacuationFailureObjsInHR` ;) - there is zero documentation about the basic structure - it seems to allocate quite a lot of memory that is almost never used. Even in the case of evacuation failure it's likely to be almost empty.
`G1EvacuationFailureObjsInHR` seems to basically be a preallocated `ArrayList` of chunks (the `_array_list` member).
Afaict it uses like 1/256 of total heap size (i.e. 0.3%), that's way way too much ( 1 / (256 * sizeof(HeapWord)) * sizeof(pointer); in `G1EvacuationFailureObjsInHR.cpp:86`; the `Array` constructor in `G1EvacuationFailureObjsInHR.hpp:124)) ). We will also get into trouble about startup time about this, I'm sure. That, tbh, alone makes it a no-go if I did not miscalculate.

Let's work on renaming and reusing the infrastructure provided by the remembered set (`G1CardSetAllocator` etc) in `g1CardSetMemory.hpp`.

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

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


From zgu at openjdk.java.net  Fri Sep 10 12:48:09 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 10 Sep 2021 12:48:09 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v2]
In-Reply-To: <GDoq2UTpcqhPcNqIVbwVPby5agS7wKhFBx7K76VVwWk=.efeeb1b8-5376-44e7-9add-31209d18bd26@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
 <GDoq2UTpcqhPcNqIVbwVPby5agS7wKhFBx7K76VVwWk=.efeeb1b8-5376-44e7-9add-31209d18bd26@github.com>
Message-ID: <6jcn6k17H4U28uxVrVNrhcW0im7GzWiZdRGuIuP_Ntg=.5e229f55-b5fc-4896-8c8a-a0f69e3284cd@github.com>

On Fri, 10 Sep 2021 12:30:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey's comment
>
> test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 102:
> 
>> 100:             if (n.getType().equals(GarbageCollectionNotificationInfo.GARBAGE_COLLECTION_NOTIFICATION)) {
>> 101:                 GarbageCollectionNotificationInfo info = GarbageCollectionNotificationInfo.from((CompositeData) n.getUserData());
>> 102:                 // Shenandoah GC also report GC pauses, skip them
> 
> Suggestion:
> 
>                 // Shenandoah GC also reports GC pauses, skip them

Fixed

> test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 105:
> 
>> 103:                 if (info.getGcName().startsWith("Shenandoah")) {
>> 104:                     if ("end of GC cycle".equals(info.getGcAction())) {
>> 105:                         gcCount ++;
> 
> Suggestion:
> 
>                         gcCount++;

Fixed

> test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 108:
> 
>> 106:                     }
>> 107:                 } else {
>> 108:                     gcCount ++;
> 
> Suggestion:
> 
>                     gcCount++;

Fixed

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

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


From pliden at openjdk.java.net  Fri Sep 10 13:03:01 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 10 Sep 2021 13:03:01 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v2]
In-Reply-To: <Js4dk2oC1ryXuHerj-4tqmT5LmJX1_Q9dyYefUY6R9k=.e33e19f8-3cc0-400a-9c9b-e9157c9b2d48@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
 <Js4dk2oC1ryXuHerj-4tqmT5LmJX1_Q9dyYefUY6R9k=.e33e19f8-3cc0-400a-9c9b-e9157c9b2d48@github.com>
Message-ID: <Wy7kxap_MY_SquHRFX2JzwMNVEQZMq284lHQByRr--M=.c5c3a4aa-5885-465a-8f05-47daa72b8422@github.com>

On Fri, 10 Sep 2021 12:44:39 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
>> 
>> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aleksey's comment

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 106:

> 104:                     if ("end of GC cycle".equals(info.getGcAction())) {
> 105:                         gcCount++;
> 106:                     }

I think you want to do the same thing for ZGC here, which also reports both pauses and cycles.

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

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


From zgu at openjdk.java.net  Fri Sep 10 13:54:34 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 10 Sep 2021 13:54:34 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v3]
In-Reply-To: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
Message-ID: <Jf3TCseLYFm00ro_ghYjnJ_ke_jobkp5wKDsIq9LJhA=.24f7f81f-fd2b-426f-9ac4-ddc07ff6e01d@github.com>

> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
> 
> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.

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

  Per's comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5428/files
  - new: https://git.openjdk.java.net/jdk/pull/5428/files/46170eb3..de99a712

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

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

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


From zgu at openjdk.java.net  Fri Sep 10 13:54:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 10 Sep 2021 13:54:37 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v2]
In-Reply-To: <Wy7kxap_MY_SquHRFX2JzwMNVEQZMq284lHQByRr--M=.c5c3a4aa-5885-465a-8f05-47daa72b8422@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
 <Js4dk2oC1ryXuHerj-4tqmT5LmJX1_Q9dyYefUY6R9k=.e33e19f8-3cc0-400a-9c9b-e9157c9b2d48@github.com>
 <Wy7kxap_MY_SquHRFX2JzwMNVEQZMq284lHQByRr--M=.c5c3a4aa-5885-465a-8f05-47daa72b8422@github.com>
Message-ID: <q5GLYR68v76KLACATPxaHZPsOPI_HzS5ge1Y9bEPSwI=.60540630-9edc-448a-9760-c888baea1a54@github.com>

On Fri, 10 Sep 2021 13:00:05 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey's comment
>
> test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 106:
> 
>> 104:                     if ("end of GC cycle".equals(info.getGcAction())) {
>> 105:                         gcCount++;
>> 106:                     }
> 
> I think you want to do the same thing for ZGC here, which also reports both pauses and cycles.

Fixed. Thanks

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

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


From tschatzl at openjdk.java.net  Fri Sep 10 17:40:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 10 Sep 2021 17:40:08 GMT
Subject: RFR: 8273599: Remove cross_threshold method usage around GC
Message-ID: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>

HI all,

 the cross_threshold() method is used in a few places to update the BOT after major changes to object locations (typically full gc compaction).

It has the following signature:

HeapWord* HeapRegion::cross_threshold(HeapWord* start, HeapWord* end);

to update the BOT for an object from start to end, returning the next (higher) address where there is need to call it again if advancing forward in the heap (i.e. basically after the last BOT entry that has just been written).

So it can be used in a loop to be only called in that case like this:

  _compaction_top += size;
  if (_compaction_top > _threshold) {
    _threshold = _current_region->cross_threshold(_compaction_top - size, _compaction_top);
  }

However the method it calls, alloc_block() does that check to shortcut unnecessary calls to some alloc_block_work() method already:

    if (blk_end > _next_offset_threshold) {
      alloc_block_work(&_next_offset_threshold, blk_start, blk_end);
    }

as cross_threshold() always returns _next_offset_threshold.

So the cross_threshold method and all the machinery to avoid unnecessary calls is... unnecessary. 

No particular performance implications either way.

Testing: tier1-3, gc/g1

Thanks,
  Thomas

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

Commit messages:
 - Remove cross_threshold

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

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


From zgu at openjdk.java.net  Fri Sep 10 18:26:06 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 10 Sep 2021 18:26:06 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support multi-threaded
 heap dump
Message-ID: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>

At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.

 JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.

Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.

Test:

- [x] hotspot_gc_shenandoah
- [x] tier1 with Shenandoah GC

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

Commit messages:
 - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

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

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


From mli at openjdk.java.net  Sat Sep 11 05:02:47 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 11 Sep 2021 05:02:47 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with
 few failed objects [v7]
In-Reply-To: <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
Message-ID: <T7q0vk1fLNJWKmDKN3l6KjHFACz9gj-DsmH_mZ52Muk=.003ae577-554c-43d0-899e-939d813edca8@github.com>

On Thu, 26 Aug 2021 10:04:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

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

Agree, I will first work on https://bugs.openjdk.java.net/browse/JDK-8273626 which is to refactor G1CardSetAllocator and related classes to support element size less pointer size.

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

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


From mli at openjdk.java.net  Sat Sep 11 05:14:04 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 11 Sep 2021 05:14:04 GMT
Subject: RFR: 8273626: G1: refactor G1CardSetAllocator to support element size
 less pointer size
Message-ID: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>

To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.

This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

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

Commit messages:
 - Clean code
 - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums
 - Initial commit

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

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


From github.com+16811675+linade at openjdk.java.net  Sun Sep 12 13:41:05 2021
From: github.com+16811675+linade at openjdk.java.net (Yude Lin)
Date: Sun, 12 Sep 2021 13:41:05 GMT
Subject: RFR: 8272083: G1: Record iterated range for BOT performance
 during card scan [v2]
In-Reply-To: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
References: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
Message-ID: <VIIlrLTgJXxjfblbTS-tRHZk16x7EaXLE0HHMHWQN18=.70cadbc9-80a5-45fc-9ea1-2bc25576e0e4@github.com>

> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000).
> 
> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern.

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

 - 8272083: G1: Concurrently fix block offset table
 - Revert "8272083: G1: Record iterated range for BOT performance during card scan."
   
   This reverts commit 7f4bb6e459880bd9fcf132099280b22e022baccb.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5039/files
  - new: https://git.openjdk.java.net/jdk/pull/5039/files/7f4bb6e4..07a8b9e5

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

  Stats: 1273 lines in 24 files changed: 1225 ins; 35 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5039/head:pull/5039

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


From github.com+16811675+linade at openjdk.java.net  Mon Sep 13 04:44:51 2021
From: github.com+16811675+linade at openjdk.java.net (Yude Lin)
Date: Mon, 13 Sep 2021 04:44:51 GMT
Subject: RFR: 8272083: G1: Record iterated range for BOT performance
 during card scan [v3]
In-Reply-To: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
References: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
Message-ID: <Y2DJ7nuOvNRMPgJ0_hlPflslTC4sfvfII_k7ufnA2s0=.1830b61f-aa7f-47b1-a33f-c2807f34fb38@github.com>

> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000).
> 
> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern.

Yude Lin has updated the pull request incrementally with one additional commit since the last revision:

  Resolve TODOs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5039/files
  - new: https://git.openjdk.java.net/jdk/pull/5039/files/07a8b9e5..79ebe0a2

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

  Stats: 41 lines in 4 files changed: 20 ins; 2 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5039.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5039/head:pull/5039

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


From github.com+16811675+linade at openjdk.java.net  Mon Sep 13 07:45:53 2021
From: github.com+16811675+linade at openjdk.java.net (Yude Lin)
Date: Mon, 13 Sep 2021 07:45:53 GMT
Subject: RFR: 8272083: G1: Record iterated range for BOT performance
 during card scan [v3]
In-Reply-To: <Y2DJ7nuOvNRMPgJ0_hlPflslTC4sfvfII_k7ufnA2s0=.1830b61f-aa7f-47b1-a33f-c2807f34fb38@github.com>
References: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
 <Y2DJ7nuOvNRMPgJ0_hlPflslTC4sfvfII_k7ufnA2s0=.1830b61f-aa7f-47b1-a33f-c2807f34fb38@github.com>
Message-ID: <Ktqp50O1TBvoRrf06K6bPxfo5Bl0hVo_t0MuqLC5oSw=.5d9c8ced-cb69-44e6-ae3c-9d243e42c3a4@github.com>

On Mon, 13 Sep 2021 04:44:51 GMT, Yude Lin <github.com+16811675+linade at openjdk.org> wrote:

>> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000).
>> 
>> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern.
>
> Yude Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolve TODOs

Hi Thomas,

I've updated the pr with new code. I hope at least it's good for further discussion.

An outline of the current implementation:

1. During gc:
> PLABs are created during evacuation to contain promoted objects from survivor regions and surviving objects from old regions (mixed gc only). In each old region, the area between the old top() and new top(), before and after an evacuation pause, is where the new PLABs are, which we will record.

The above hasn't changed. We will record the old top() and every plab that has crossed a card boundary. Recording is now done using a card set. Each card will represent a plab.

2. After the pause, a concurrent phase will be scheduled to fix BOT in these areas. Basically a fixing worker will claim a card from the card set. This card tells us a plab needs to be fixed. This worker then fixes the BOT entries covered by the plab.

3. For concurrent refinement:
> If concurrent refinement tries to refine a card, it will probably run into an unfixed part of BOT. We prevent this by requiring the refiner to fix where the card is pointing at.

The card could be pointing into a plab, which needs to be fixed. We will ask the card set whether this is the case. If it is, the card set will return the card of the plab and the concurrent refinement thread (or java thread) should fix it before doing refine.

4. If another gc pause is scheduled, we abort the unfinished fixing jobs and clear the card sets.

The card set implementation:

This card set needs to be populated in parallel; and removed from concurrently. The G1CardSet doesn't allow concurrent removing without major modification (from what I understand). Also the cards we are managing has the following characteristics:
* They are in the back of a region;
* They are at a distance apart from each other (at least plab size).

To take advantage of these, I used a separate card set. It can use an array that has size=region_size/plab_size; or it can use a bitmap of cards. It will only use bitmap when the plab size is small enough so that the bitmap is smaller than the array. I tried to make the card set implementation decoupled from the fixer, so that if you think it's insufficient, we can improve or replace it.

Other consideration:

You are right about that fixing a single plab could stall java threads' concurrent refinement for too long. It occasionally gets over 10ms (most of the time below 1ms). An idea is to abort when fixing takes too long, or just don't let the refinement threads fix large plabs when we predict it will take very long. But large plabs are the most costly ones and are the reasons why we want fixing. Maybe there is a way to postpone concurrent refinement a little after a gc? E.g., increase the buffer size temporarily. So that as many plabs are processed by fixer threads as possible. I'm not sure.

Thank you!

Regards,

Yude

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

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


From shade at openjdk.java.net  Mon Sep 13 08:58:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 08:58:52 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <4UD4Fgl1VmQ1pG2cL_rOmaO5j163s5LvFilUOIFgaCw=.7d4c1b28-11f1-4dbc-9edc-986085431517@github.com>

On Fri, 10 Sep 2021 18:17:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

Looks fine to me with minor nits.

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp line 124:

> 122: 
> 123: public:
> 124:   ShenandoahClassLoaderDataRoots(ShenandoahPhaseTimings::Phase phase, uint n_workers, bool heapdump);

Can we call the new parameter `heap_iteration`? This would match the `ShenandoahHeapIterationRootScanner` name. I could also imagine that iteration is used for something else than a heap dump (maybe JFR/JVMTI heap walk for profiling/debugging?).

test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java line 156:

> 154:         }
> 155:     }
> 156: }

Newline is missing.

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

Marked as reviewed by shade (Reviewer).

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


From pliden at openjdk.java.net  Mon Sep 13 09:38:52 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 09:38:52 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v3]
In-Reply-To: <Jf3TCseLYFm00ro_ghYjnJ_ke_jobkp5wKDsIq9LJhA=.24f7f81f-fd2b-426f-9ac4-ddc07ff6e01d@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
 <Jf3TCseLYFm00ro_ghYjnJ_ke_jobkp5wKDsIq9LJhA=.24f7f81f-fd2b-426f-9ac4-ddc07ff6e01d@github.com>
Message-ID: <S7nRdfgwdjMIfYLzzLH_naZzoFyJHaKwmxvbVOrbq-g=.dc8353b4-40a5-4277-a7a3-0ca99476927e@github.com>

On Fri, 10 Sep 2021 13:54:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
>> 
>> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Per's comment

Marked as reviewed by pliden (Reviewer).

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

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


From sgehwolf at openjdk.java.net  Mon Sep 13 10:11:50 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 13 Sep 2021 10:11:50 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <88HP7CdhnW6Bj6pQ2tQ2HnzfxJOm8fIbsZ-IKJLX2Gc=.89170242-6aea-4a36-afc1-d5808027964f@github.com>

On Fri, 10 Sep 2021 18:17:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 263:

> 261:    assert(Thread::current()->is_VM_thread(), "Only by VM thread");
> 262:    // Must use _claim_none to avoid interfering with concurrent CLDG iteration
> 263:    CLDToOopClosure clds(oops, ClassLoaderData::_claim_other);

Nit: Update/remove comment? `Must use _claim_none ...` seems to conflict with code.

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

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


From shade at openjdk.java.net  Mon Sep 13 10:21:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 10:21:51 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v3]
In-Reply-To: <Jf3TCseLYFm00ro_ghYjnJ_ke_jobkp5wKDsIq9LJhA=.24f7f81f-fd2b-426f-9ac4-ddc07ff6e01d@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
 <Jf3TCseLYFm00ro_ghYjnJ_ke_jobkp5wKDsIq9LJhA=.24f7f81f-fd2b-426f-9ac4-ddc07ff6e01d@github.com>
Message-ID: <bDYMefBKaaKXDeAqFfOiX8enXqUmrYMQKRiu63Ef11E=.b72ff566-ba66-4ecf-ae74-abcfbd9425ad@github.com>

On Fri, 10 Sep 2021 13:54:34 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
>> 
>> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Per's comment

Marked as reviewed by shade (Reviewer).

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

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


From zgu at openjdk.java.net  Mon Sep 13 12:26:49 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:26:49 GMT
Subject: RFR: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah [v3]
In-Reply-To: <bDYMefBKaaKXDeAqFfOiX8enXqUmrYMQKRiu63Ef11E=.b72ff566-ba66-4ecf-ae74-abcfbd9425ad@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
 <Jf3TCseLYFm00ro_ghYjnJ_ke_jobkp5wKDsIq9LJhA=.24f7f81f-fd2b-426f-9ac4-ddc07ff6e01d@github.com>
 <bDYMefBKaaKXDeAqFfOiX8enXqUmrYMQKRiu63Ef11E=.b72ff566-ba66-4ecf-ae74-abcfbd9425ad@github.com>
Message-ID: <JuXdClGPgEjDG030RASNmEprts4h4_r1h9ttWamXh9Y=.33736be0-a242-4d91-a0ee-acfb0e3329ae@github.com>

On Mon, 13 Sep 2021 10:18:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Per's comment
>
> Marked as reviewed by shade (Reviewer).

Thanks, @shipilev @pliden

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

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


From zgu at openjdk.java.net  Mon Sep 13 12:26:49 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:26:49 GMT
Subject: Integrated: 8271834: TestStringDeduplicationAgeThreshold intermittent
 failures on Shenandoah
In-Reply-To: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
References: <a43b6UXhhl1wisIAjEEAy9_wj4Gmp60_5WRFUCF9wNY=.91be065e-173a-45d3-a17e-6ed76d668999@github.com>
Message-ID: <qZU_1q3cX-GLnrtTOcJEAULPh-PNMjxxc-BOPYzw2DQ=.c9729548-fb56-4429-9312-7be975f22e38@github.com>

On Wed, 8 Sep 2021 23:59:00 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> To trigger young GC, the test fills heap with -Xmn amount of garbage. However, -Xmn does not apply to non-generational GC, such as Shenandoah, and -Xmn amount of garbage, sometimes, it not enough to trigger GC, therefore, there is no guarantee that strings can reach deduplication age threshold.
> 
> I purpose to use MXBean to get exact gc count to ensure expected gc cycles actually performed.

This pull request has now been integrated.

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

8271834: TestStringDeduplicationAgeThreshold intermittent failures on Shenandoah

Reviewed-by: shade, pliden

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

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


From zgu at openjdk.java.net  Mon Sep 13 12:32:15 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:32:15 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v2]
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <-9varZ1RTYOW8rzeK4NGQPGN1AGi1kHpTLLjV9v62o4=.3d64f9b0-51f7-49d6-880c-5327b9320580@github.com>

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

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

  Aleksey and Severin's comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5473/files
  - new: https://git.openjdk.java.net/jdk/pull/5473/files/1432e964..31406df7

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

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

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


From zgu at openjdk.java.net  Mon Sep 13 12:35:59 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:35:59 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v2]
In-Reply-To: <88HP7CdhnW6Bj6pQ2tQ2HnzfxJOm8fIbsZ-IKJLX2Gc=.89170242-6aea-4a36-afc1-d5808027964f@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <88HP7CdhnW6Bj6pQ2tQ2HnzfxJOm8fIbsZ-IKJLX2Gc=.89170242-6aea-4a36-afc1-d5808027964f@github.com>
Message-ID: <6MGFfCiG43QqTj65MyyCf_HLv2GgjXQYTdI_DPrxoCo=.efe967cd-6591-478d-91da-c7b789a1ea2e@github.com>

On Mon, 13 Sep 2021 10:09:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey and Severin's comments
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp line 263:
> 
>> 261:    assert(Thread::current()->is_VM_thread(), "Only by VM thread");
>> 262:    // Must use _claim_none to avoid interfering with concurrent CLDG iteration
>> 263:    CLDToOopClosure clds(oops, ClassLoaderData::_claim_other);
> 
> Nit: Update/remove comment? `Must use _claim_none ...` seems to conflict with code.

Fixed. Thanks!

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

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


From zgu at openjdk.java.net  Mon Sep 13 12:42:47 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 12:42:47 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v2]
In-Reply-To: <4UD4Fgl1VmQ1pG2cL_rOmaO5j163s5LvFilUOIFgaCw=.7d4c1b28-11f1-4dbc-9edc-986085431517@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <4UD4Fgl1VmQ1pG2cL_rOmaO5j163s5LvFilUOIFgaCw=.7d4c1b28-11f1-4dbc-9edc-986085431517@github.com>
Message-ID: <wNbo_5_smfdypq390vZ8rLuNhoBgv4kq8GlAgYz6FjE=.9ae28c9b-9263-43e6-8ba2-2bfeb756863f@github.com>

On Mon, 13 Sep 2021 08:55:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Aleksey and Severin's comments
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp line 124:
> 
>> 122: 
>> 123: public:
>> 124:   ShenandoahClassLoaderDataRoots(ShenandoahPhaseTimings::Phase phase, uint n_workers, bool heapdump);
> 
> Can we call the new parameter `heap_iteration`? This would match the `ShenandoahHeapIterationRootScanner` name. I could also imagine that iteration is used for something else than a heap dump (maybe JFR/JVMTI heap walk for profiling/debugging?).

Fixed. Thanks!

> test/hotspot/jtreg/gc/shenandoah/TestJcmdHeapDump.java line 156:
> 
>> 154:         }
>> 155:     }
>> 156: }
> 
> Newline is missing.

Fixed

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

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


From zgu at openjdk.java.net  Mon Sep 13 13:34:28 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 13 Sep 2021 13:34:28 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

Zhengyu Gu 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
 - Aleksey and Severin's comments
 - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

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

Changes: https://git.openjdk.java.net/jdk/pull/5473/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5473&range=02
  Stats: 206 lines in 6 files changed: 161 ins; 10 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5473.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5473/head:pull/5473

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


From tschatzl at openjdk.java.net  Mon Sep 13 15:29:14 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 13 Sep 2021 15:29:14 GMT
Subject: RFR: 8273605: VM Exit does not abort concurrent mark
Message-ID: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>

Hi,

  can I have reviews for this change that adds (best-effort) notification of the concurrent mark thread about that the VM is exiting. In particular, the change reuses the existing abort mechanism.

Best-effort because the change just flips a global flag that is periodically polled by all threads (particularly the concurrent mark thread) to see whether we should abort.

In that test case it reduces shutdown time from a wait until the whole marking cycle finished to "immediate".

There is no test case because I could not think of anything that's reproducable: after all to have a very long delay for shutdown we need to have a *huge* heap (tested on a 50gb heap with 25gb live data), and additionally measuring shutdown time in CI is just asking for spurious errors when that process does not get enough cpu time for any reason.

Testing: test case that found that issue; tier1-3

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

Commit messages:
 - Notify everyone to abort at VM exit instead of waiting until marking finishes.

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

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


From kbarrett at openjdk.java.net  Mon Sep 13 16:13:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 13 Sep 2021 16:13:52 GMT
Subject: RFR: 8273605: VM Exit does not abort concurrent mark
In-Reply-To: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
References: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
Message-ID: <XGgwGA94vWf3ZRHNhVFvZzJ5WCKF6xen7Ov4RswJUjw=.29c0da26-8d2f-409b-9107-cdadd918ac5d@github.com>

On Mon, 13 Sep 2021 14:38:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   can I have reviews for this change that adds (best-effort) notification of the concurrent mark thread about that the VM is exiting. In particular, the change reuses the existing abort mechanism.
> 
> Best-effort because the change just flips a global flag that is periodically polled by all threads (particularly the concurrent mark thread) to see whether we should abort.
> 
> In that test case it reduces shutdown time from a wait until the whole marking cycle finished to "immediate".
> 
> There is no test case because I could not think of anything that's reproducable: after all to have a very long delay for shutdown we need to have a *huge* heap (tested on a 50gb heap with 25gb live data), and additionally measuring shutdown time in CI is just asking for spurious errors when that process does not get enough cpu time for any reason.
> 
> Testing: test case that found that issue; tier1-3

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From coleenp at openjdk.java.net  Tue Sep 14 12:41:20 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Sep 2021 12:41:20 GMT
Subject: RFR: 8273730: WorkGangBarrierSync constructor unused
Message-ID: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>

Please review this trivial change.  This constructor is unused and uses a lock rank that doesn't really mean anything in the jvm.  Built vm with shenandoah and testing with tier1 on Oracle platforms.  Thanks!

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

Commit messages:
 - 8273730: WorkGangBarrierSync constructor unused

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

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


From tschatzl at openjdk.java.net  Tue Sep 14 13:03:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 14 Sep 2021 13:03:06 GMT
Subject: RFR: 8273730: WorkGangBarrierSync constructor unused
In-Reply-To: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
References: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
Message-ID: <k9JnOab75HU06IvAhmcTHcfkk1JP-8wlRirude1KlkM=.b199d036-a490-4443-83aa-8c0377bca42e@github.com>

On Tue, 14 Sep 2021 12:32:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change.  This constructor is unused and uses a lock rank that doesn't really mean anything in the jvm.  Built vm with shenandoah and testing with tier1 on Oracle platforms.  Thanks!

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

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


From eosterlund at openjdk.java.net  Tue Sep 14 13:15:03 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 14 Sep 2021 13:15:03 GMT
Subject: RFR: 8273730: WorkGangBarrierSync constructor unused
In-Reply-To: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
References: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
Message-ID: <_mdV9kMH2SGbl4UYQCVMRKsikMcWf1q_3AExGZhN-uc=.5e6e7ff8-a957-4c39-9a9f-32daad7b055e@github.com>

On Tue, 14 Sep 2021 12:32:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change.  This constructor is unused and uses a lock rank that doesn't really mean anything in the jvm.  Built vm with shenandoah and testing with tier1 on Oracle platforms.  Thanks!

Looks good and trivial.

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

Marked as reviewed by eosterlund (Reviewer).

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


From coleenp at openjdk.java.net  Tue Sep 14 13:21:13 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Sep 2021 13:21:13 GMT
Subject: RFR: 8273730: WorkGangBarrierSync constructor unused
In-Reply-To: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
References: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
Message-ID: <G5EshXTp9A-rS_kAyoZopjcqdIGKZhsevV4OD7HMS3I=.7bfc8062-ad9f-4afc-b96f-cc17e52585de@github.com>

On Tue, 14 Sep 2021 12:32:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change.  This constructor is unused and uses a lock rank that doesn't really mean anything in the jvm.  Built vm with shenandoah and testing with tier1 on Oracle platforms.  Thanks!

Thank you Thomas and Erik!

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

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


From coleenp at openjdk.java.net  Tue Sep 14 13:21:14 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 14 Sep 2021 13:21:14 GMT
Subject: Integrated: 8273730: WorkGangBarrierSync constructor unused
In-Reply-To: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
References: <-DDcyDZgtT8fH1bYN6bvj-Yro_C2-1XIL__Gg3rk8tc=.3cf48062-8fcb-4bbc-ac34-fe9097990a4f@github.com>
Message-ID: <v8DlsnqK-NUCKB_Z0u3BqzF_mDCtWZTZpFrBvx6X6jQ=.94602c28-6eae-4c75-9f9f-dc65b0e33875@github.com>

On Tue, 14 Sep 2021 12:32:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change.  This constructor is unused and uses a lock rank that doesn't really mean anything in the jvm.  Built vm with shenandoah and testing with tier1 on Oracle platforms.  Thanks!

This pull request has now been integrated.

Changeset: 8974b958
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8974b958866bf43d2639114b764bccbae941943f
Stats:     6 lines in 2 files changed: 0 ins; 6 del; 0 mod

8273730: WorkGangBarrierSync constructor unused

Reviewed-by: tschatzl, eosterlund

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

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


From sjohanss at openjdk.java.net  Wed Sep 15 06:35:46 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 15 Sep 2021 06:35:46 GMT
Subject: RFR: 8273605: VM Exit does not abort concurrent mark
In-Reply-To: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
References: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
Message-ID: <xo75TGRXlkRz09zz5Bl26oOkkq77JeadUPktGGwwPY0=.853b9dfc-b403-4a6c-ac78-ea473a46cd75@github.com>

On Mon, 13 Sep 2021 14:38:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   can I have reviews for this change that adds (best-effort) notification of the concurrent mark thread about that the VM is exiting. In particular, the change reuses the existing abort mechanism.
> 
> Best-effort because the change just flips a global flag that is periodically polled by all threads (particularly the concurrent mark thread) to see whether we should abort.
> 
> In that test case it reduces shutdown time from a wait until the whole marking cycle finished to "immediate".
> 
> There is no test case because I could not think of anything that's reproducable: after all to have a very long delay for shutdown we need to have a *huge* heap (tested on a 50gb heap with 25gb live data), and additionally measuring shutdown time in CI is just asking for spurious errors when that process does not get enough cpu time for any reason.
> 
> Testing: test case that found that issue; tier1-3

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Wed Sep 15 06:44:43 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 15 Sep 2021 06:44:43 GMT
Subject: RFR: 8273599: Remove cross_threshold method usage around GC
In-Reply-To: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
References: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
Message-ID: <B2Wt83mzQHzcdo375GlwVYliigdvCG1f5HWjCyQe1Wc=.64ba6dbd-2908-46e3-8db3-703c40e54dd1@github.com>

On Fri, 10 Sep 2021 15:35:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> HI all,
> 
>  the cross_threshold() method is used in a few places to update the BOT after major changes to object locations (typically full gc compaction).
> 
> It has the following signature:
> 
> HeapWord* HeapRegion::cross_threshold(HeapWord* start, HeapWord* end);
> 
> to update the BOT for an object from start to end, returning the next (higher) address where there is need to call it again if advancing forward in the heap (i.e. basically after the last BOT entry that has just been written).
> 
> So it can be used in a loop to be only called in that case like this:
> 
>   _compaction_top += size;
>   if (_compaction_top > _threshold) {
>     _threshold = _current_region->cross_threshold(_compaction_top - size, _compaction_top);
>   }
> 
> However the method it calls, alloc_block() does that check to shortcut unnecessary calls to some alloc_block_work() method already:
> 
>     if (blk_end > _next_offset_threshold) {
>       alloc_block_work(&_next_offset_threshold, blk_start, blk_end);
>     }
> 
> as cross_threshold() always returns _next_offset_threshold.
> 
> So the cross_threshold method and all the machinery to avoid unnecessary calls is... unnecessary. 
> 
> No particular performance implications either way.
> 
> Testing: tier1-3, gc/g1
> 
> Thanks,
>   Thomas

Nice find and good clean up. ?

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Wed Sep 15 06:59:02 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 15 Sep 2021 06:59:02 GMT
Subject: RFR: 8273590: Move helper classes in G1 post evacuation sub tasks
 to cpp files
In-Reply-To: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
References: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
Message-ID: <YFZkOsd1dFFiG2WEHuhd4VDU96Kd6IFoRBqIH4Vc6Mc=.7b4cf6ab-2629-4a1f-b4b2-477cddc7fec7@github.com>

On Fri, 10 Sep 2021 10:52:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this straightforward refactoring, moving helper classes that are not required to .cpp files. The nice side effect of this is that it removes around 100 LOC. No changes to code, except for removal of one unused local variable in
> ```RemoveSelfForwardPtrsTask::~RemoveSelfForwardPtrsTask`.
> 
> Testing: compilation, gha, local jtreg/gc/g1
> 
> Thanks,
>   Thomas

?

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

Marked as reviewed by sjohanss (Reviewer).

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


From ayang at openjdk.java.net  Wed Sep 15 08:17:45 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 15 Sep 2021 08:17:45 GMT
Subject: RFR: 8273599: Remove cross_threshold method usage around GC
In-Reply-To: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
References: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
Message-ID: <7GGA1540aArfKRSJPDnfVHV0fTHPyN4Absmt-EOUfyQ=.5ddebfec-9667-49db-8a60-5135e4ae80b2@github.com>

On Fri, 10 Sep 2021 15:35:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> HI all,
> 
>  the cross_threshold() method is used in a few places to update the BOT after major changes to object locations (typically full gc compaction).
> 
> It has the following signature:
> 
> HeapWord* HeapRegion::cross_threshold(HeapWord* start, HeapWord* end);
> 
> to update the BOT for an object from start to end, returning the next (higher) address where there is need to call it again if advancing forward in the heap (i.e. basically after the last BOT entry that has just been written).
> 
> So it can be used in a loop to be only called in that case like this:
> 
>   _compaction_top += size;
>   if (_compaction_top > _threshold) {
>     _threshold = _current_region->cross_threshold(_compaction_top - size, _compaction_top);
>   }
> 
> However the method it calls, alloc_block() does that check to shortcut unnecessary calls to some alloc_block_work() method already:
> 
>     if (blk_end > _next_offset_threshold) {
>       alloc_block_work(&_next_offset_threshold, blk_start, blk_end);
>     }
> 
> as cross_threshold() always returns _next_offset_threshold.
> 
> So the cross_threshold method and all the machinery to avoid unnecessary calls is... unnecessary. 
> 
> No particular performance implications either way.
> 
> Testing: tier1-3, gc/g1
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 08:30:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 08:30:49 GMT
Subject: RFR: 8273605: VM Exit does not abort concurrent mark
In-Reply-To: <XGgwGA94vWf3ZRHNhVFvZzJ5WCKF6xen7Ov4RswJUjw=.29c0da26-8d2f-409b-9107-cdadd918ac5d@github.com>
References: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
 <XGgwGA94vWf3ZRHNhVFvZzJ5WCKF6xen7Ov4RswJUjw=.29c0da26-8d2f-409b-9107-cdadd918ac5d@github.com>
Message-ID: <P_6CQqncfWB7cV8azyIW8AU8JB90tK05Y75g7FkqVcQ=.88aa20de-beea-4331-9b91-ab6b0ceb8a89@github.com>

On Mon, 13 Sep 2021 16:10:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that adds (best-effort) notification of the concurrent mark thread about that the VM is exiting. In particular, the change reuses the existing abort mechanism.
>> 
>> Best-effort because the change just flips a global flag that is periodically polled by all threads (particularly the concurrent mark thread) to see whether we should abort.
>> 
>> In that test case it reduces shutdown time from a wait until the whole marking cycle finished to "immediate".
>> 
>> There is no test case because I could not think of anything that's reproducable: after all to have a very long delay for shutdown we need to have a *huge* heap (tested on a 50gb heap with 25gb live data), and additionally measuring shutdown time in CI is just asking for spurious errors when that process does not get enough cpu time for any reason.
>> 
>> Testing: test case that found that issue; tier1-3
>
> Looks good.

Thanks @kimbarrett @kstefanj for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 08:30:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 08:30:50 GMT
Subject: Integrated: 8273605: VM Exit does not abort concurrent mark
In-Reply-To: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
References: <-cWnGXyv-tKKuy4ii51_t3jOrUveXAE3KHDjHQpUgwQ=.69091beb-5190-4dba-8392-c8afc2df1d67@github.com>
Message-ID: <qQS4rdvZ4cV47U9RtYZJVHcsRi5m4IsTZ6pKouZEOP0=.53ee0107-8960-49f8-9c24-a6ab8a9953ed@github.com>

On Mon, 13 Sep 2021 14:38:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   can I have reviews for this change that adds (best-effort) notification of the concurrent mark thread about that the VM is exiting. In particular, the change reuses the existing abort mechanism.
> 
> Best-effort because the change just flips a global flag that is periodically polled by all threads (particularly the concurrent mark thread) to see whether we should abort.
> 
> In that test case it reduces shutdown time from a wait until the whole marking cycle finished to "immediate".
> 
> There is no test case because I could not think of anything that's reproducable: after all to have a very long delay for shutdown we need to have a *huge* heap (tested on a 50gb heap with 25gb live data), and additionally measuring shutdown time in CI is just asking for spurious errors when that process does not get enough cpu time for any reason.
> 
> Testing: test case that found that issue; tier1-3

This pull request has now been integrated.

Changeset: 02af541b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/02af541b7427a4b74eecab9513a770026d1a8426
Stats:     15 lines in 3 files changed: 12 ins; 1 del; 2 mod

8273605: VM Exit does not abort concurrent mark

Reviewed-by: kbarrett, sjohanss

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 08:31:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 08:31:49 GMT
Subject: Integrated: 8273599: Remove cross_threshold method usage around GC
In-Reply-To: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
References: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
Message-ID: <wVvjig-bSuCxKNCgTOh8eHi6-PO2OLXYLSzzdqJrrB4=.c3c253e1-907d-48fd-b00a-cc11368eda3c@github.com>

On Fri, 10 Sep 2021 15:35:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> HI all,
> 
>  the cross_threshold() method is used in a few places to update the BOT after major changes to object locations (typically full gc compaction).
> 
> It has the following signature:
> 
> HeapWord* HeapRegion::cross_threshold(HeapWord* start, HeapWord* end);
> 
> to update the BOT for an object from start to end, returning the next (higher) address where there is need to call it again if advancing forward in the heap (i.e. basically after the last BOT entry that has just been written).
> 
> So it can be used in a loop to be only called in that case like this:
> 
>   _compaction_top += size;
>   if (_compaction_top > _threshold) {
>     _threshold = _current_region->cross_threshold(_compaction_top - size, _compaction_top);
>   }
> 
> However the method it calls, alloc_block() does that check to shortcut unnecessary calls to some alloc_block_work() method already:
> 
>     if (blk_end > _next_offset_threshold) {
>       alloc_block_work(&_next_offset_threshold, blk_start, blk_end);
>     }
> 
> as cross_threshold() always returns _next_offset_threshold.
> 
> So the cross_threshold method and all the machinery to avoid unnecessary calls is... unnecessary. 
> 
> No particular performance implications either way.
> 
> Testing: tier1-3, gc/g1
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 92c30c94
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92c30c941be09cd43ca794b180b8a1b6f7f952e1
Stats:     50 lines in 11 files changed: 0 ins; 18 del; 32 mod

8273599: Remove cross_threshold method usage around GC

Reviewed-by: sjohanss, ayang

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 08:31:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 08:31:48 GMT
Subject: RFR: 8273599: Remove cross_threshold method usage around GC
In-Reply-To: <7GGA1540aArfKRSJPDnfVHV0fTHPyN4Absmt-EOUfyQ=.5ddebfec-9667-49db-8a60-5135e4ae80b2@github.com>
References: <K6G8k8748MVp0Owzetld0hzyfVyVs3eT59lvfVYsWfE=.bc1c2dd0-7368-4611-9761-749c659b1b61@github.com>
 <7GGA1540aArfKRSJPDnfVHV0fTHPyN4Absmt-EOUfyQ=.5ddebfec-9667-49db-8a60-5135e4ae80b2@github.com>
Message-ID: <gopiNjEX-Ms7b1vxjASR7cip6p3YiW4tKdmlHBBhu_s=.14fc28d4-2def-495f-97c1-96906d1c8e0a@github.com>

On Wed, 15 Sep 2021 08:14:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> HI all,
>> 
>>  the cross_threshold() method is used in a few places to update the BOT after major changes to object locations (typically full gc compaction).
>> 
>> It has the following signature:
>> 
>> HeapWord* HeapRegion::cross_threshold(HeapWord* start, HeapWord* end);
>> 
>> to update the BOT for an object from start to end, returning the next (higher) address where there is need to call it again if advancing forward in the heap (i.e. basically after the last BOT entry that has just been written).
>> 
>> So it can be used in a loop to be only called in that case like this:
>> 
>>   _compaction_top += size;
>>   if (_compaction_top > _threshold) {
>>     _threshold = _current_region->cross_threshold(_compaction_top - size, _compaction_top);
>>   }
>> 
>> However the method it calls, alloc_block() does that check to shortcut unnecessary calls to some alloc_block_work() method already:
>> 
>>     if (blk_end > _next_offset_threshold) {
>>       alloc_block_work(&_next_offset_threshold, blk_start, blk_end);
>>     }
>> 
>> as cross_threshold() always returns _next_offset_threshold.
>> 
>> So the cross_threshold method and all the machinery to avoid unnecessary calls is... unnecessary. 
>> 
>> No particular performance implications either way.
>> 
>> Testing: tier1-3, gc/g1
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj  for your reviews.

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

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


From shade at openjdk.java.net  Wed Sep 15 09:51:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 09:51:57 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
Message-ID: <dAlzsbkSF7Ib5xeTT3bU6B6cbrgmPTH0xctNr4vcqao=.c20b47f7-08c0-4f42-81de-76151b0a1c3e@github.com>

On Mon, 13 Sep 2021 13:34:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
>> 
>>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
>> 
>> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1 with Shenandoah GC
>
> Zhengyu Gu 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
>  - Aleksey and Severin's comments
>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Marked as reviewed by shade (Reviewer).

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

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


From shade at openjdk.java.net  Wed Sep 15 10:53:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 10:53:27 GMT
Subject: RFR: 8273805: gc/g1/TestGCLogMessages.java test should handle non-JFR
 configs
Message-ID: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>

JDK-8273147 introduced a more thorough GC messages test, which includes JFR. But it is not guaranteed that JFR is actually in the build, like in the case of Zero:


$ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/g1/TestGCLogMessages.java

java.lang.RuntimeException: '[debug.*Weak JFR Old Object Samples' missing from stdout/stderr

at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:340)
at gc.g1.TestGCLogMessages.checkMessagesAtLevel(TestGCLogMessages.java:193)
at gc.g1.TestGCLogMessages.testNormalLogs(TestGCLogMessages.java:224)
at gc.g1.TestGCLogMessages.main(TestGCLogMessages.java:199)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833) 


Luckily, the test already uses `WhiteBox`, so we can just ask if JFR is in the build or not.

Additional testing:
 - [x] Linux x86_64 Zero, affected test now passes
 - [x] Linux x86_64 Server, affected test still passes
 - [x]  Linux x86_64 Server, verified the JFR test path is taken

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

Commit messages:
 - Fix

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 11:07:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 11:07:48 GMT
Subject: RFR: 8273805: gc/g1/TestGCLogMessages.java test should handle
 non-JFR configs
In-Reply-To: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
References: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
Message-ID: <5lBUmRwaVGekTVPDAI7cUIWu17bGEXmXrq2bsyVTG4w=.f3ba42b1-f460-4b83-95cc-9fdf5c7d91f0@github.com>

On Wed, 15 Sep 2021 10:43:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8273147 introduced a more thorough GC messages test, which includes JFR. But it is not guaranteed that JFR is actually in the build, like in the case of Zero:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/g1/TestGCLogMessages.java
> 
> java.lang.RuntimeException: '[debug.*Weak JFR Old Object Samples' missing from stdout/stderr
> 
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:340)
> at gc.g1.TestGCLogMessages.checkMessagesAtLevel(TestGCLogMessages.java:193)
> at gc.g1.TestGCLogMessages.testNormalLogs(TestGCLogMessages.java:224)
> at gc.g1.TestGCLogMessages.main(TestGCLogMessages.java:199)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Luckily, the test already uses `WhiteBox`, so we can just ask if JFR is in the build or not.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, affected test now passes
>  - [x] Linux x86_64 Server, affected test still passes
>  - [x]  Linux x86_64 Server, verified the JFR test path is taken

Lgtm. Thanks for fixing this.

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

Marked as reviewed by tschatzl (Reviewer).

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


From thomas.schatzl at oracle.com  Wed Sep 15 11:18:39 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 15 Sep 2021 13:18:39 +0200
Subject: Prepopulated SerialGC old gen causes slow GC verification
In-Reply-To: <f4e46fab-b4c2-ecf8-5af0-3886d68d4ec8@oracle.com>
References: <5bb24c67-fcb8-f4d8-ddd8-05c4d7983699@oracle.com>
 <df11e15e-f90e-7f32-5bff-02eb4aad82a1@oracle.com>
 <70fc4f6a-c493-0de4-de84-b9d98320d386@oracle.com>
 <f4e46fab-b4c2-ecf8-5af0-3886d68d4ec8@oracle.com>
Message-ID: <3ab9bfec-63a1-fff9-6a8a-5f6eba045345@oracle.com>

Hi all,

On 09.09.21 10:09, Thomas Schatzl wrote:
> Hi,
> 
> On 08.09.21 22:33, Ioi Lam wrote:
>>
>>
>> On 9/8/21 12:05 PM, Thomas Schatzl wrote:
>>> Hi,
>>>
>>> On 08.09.21 20:14, Ioi Lam wrote:
>>>> I am trying to implement JDK-8273508 - Support archived heap objects 
>>>> in SerialGC
>>>>
>>>> https://github.com/openjdk/jdk/compare/master...iklam:8273508-archived-heap-objects-for-serial-gc?expand=1 
>>>>
>>>>[...]
> 
> But a quick hack showed that this is not the issue here (if I got it 
> right).
> 

   fyi, after some back and forth we found out that the issue has been 
the missing updates to the BOT after all. Together I think we found a 
solution to this issue.

Thanks,
   Thomas


From mli at openjdk.java.net  Wed Sep 15 11:37:45 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 15 Sep 2021 11:37:45 GMT
Subject: RFR: 8273626: G1: refactor G1CardSetAllocator to support element
 size less pointer size
In-Reply-To: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
Message-ID: <-nvFoVBJmN4F8OVnL07SXKwl80ERkJY8P0fMEhDCs6A=.9b47e46f-266a-42fe-af92-b8fb4776a795@github.com>

On Sat, 11 Sep 2021 05:05:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.
> 
> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

Seems the failed test "java/util/regex/NegativeArraySize.java " is not related to this patch.

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

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


From rkennke at openjdk.java.net  Wed Sep 15 11:54:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 15 Sep 2021 11:54:53 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
Message-ID: <X7xbwqfyGIfSN-9YaXklx4gybYsOH8Bt-jCUxb_QgEY=.f637f926-dc7e-4d7e-9a1b-2758009ee888@github.com>

On Mon, 13 Sep 2021 13:34:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
>> 
>>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
>> 
>> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1 with Shenandoah GC
>
> Zhengyu Gu 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
>  - Aleksey and Severin's comments
>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Marked as reviewed by rkennke (Reviewer).

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

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


From sgehwolf at openjdk.java.net  Wed Sep 15 13:09:52 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 15 Sep 2021 13:09:52 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
Message-ID: <8D9Zf4Q0V6IJfD-X5_Py2y-TDxE7L6w-RxLdf4AzQ1k=.1899ecc1-71c9-4bd9-af47-53f5a17637c1@github.com>

On Mon, 13 Sep 2021 13:34:28 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
>> 
>>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
>> 
>> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] tier1 with Shenandoah GC
>
> Zhengyu Gu 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
>  - Aleksey and Severin's comments
>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

comment change looks good :)

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

Marked as reviewed by sgehwolf (Reviewer).

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


From zgu at openjdk.java.net  Wed Sep 15 13:09:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 13:09:53 GMT
Subject: RFR: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump [v3]
In-Reply-To: <dAlzsbkSF7Ib5xeTT3bU6B6cbrgmPTH0xctNr4vcqao=.c20b47f7-08c0-4f42-81de-76151b0a1c3e@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
 <owpaF5xLXbTqFQamSMhAoJIeWjgRMjQ9sqJ4bo5lWJk=.529b205a-b862-4cf1-8d11-344c501c5921@github.com>
 <dAlzsbkSF7Ib5xeTT3bU6B6cbrgmPTH0xctNr4vcqao=.c20b47f7-08c0-4f42-81de-76151b0a1c3e@github.com>
Message-ID: <j4Kwm78hQAx6q0KuJScLXl10mHW8ORy-vlnfGZKrw90=.0d845902-cc7b-442c-82f8-f6b35a726eff@github.com>

On Wed, 15 Sep 2021 09:48:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge
>>  - Aleksey and Severin's comments
>>  - 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump
>
> Marked as reviewed by shade (Reviewer).

Thanks, @shipilev  @jerboaa  @rkennke

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

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


From zgu at openjdk.java.net  Wed Sep 15 13:13:02 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 13:13:02 GMT
Subject: Integrated: 8273559: Shenandoah: Shenandoah should support
 multi-threaded heap dump
In-Reply-To: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
References: <2N0K5tR59E_3WyKoDuFFu_DuOb5ie9TZ-9d8kyPhxCk=.770d6781-4b7f-49d1-a9bb-a690f7ff0b7b@github.com>
Message-ID: <gMpplukpHz3IHER5yxH5rDlBpeTz31xhG_KajUAzacI=.f004546b-f289-490c-9a20-2e38a335a69a@github.com>

On Fri, 10 Sep 2021 18:17:50 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> At the point when Shenandoah implemented heap dump, there was no ClassLoaderData::_claim_other flag. To avoid CLDG iteration interfering concurrent GC, we chosen single-threaded CLDG iteration with ClassLoaderData::_claim_none and ensured that by asserting calling thread has to be VMThread.
> 
>  JDK-8237354 broke the assumption, as it uses safepoint worker to execute heap dump, so that the thread executes CLDG iteration is not necessary VMThread.
> 
> Now, with new ClassLoaderData::_claim_other, we can enable multi-threaded CLDG iteration during heap dump.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with Shenandoah GC

This pull request has now been integrated.

Changeset: 8132bfd2
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8132bfd23f2f7fb52e502a3e6fe488fbdb537df0
Stats:     206 lines in 6 files changed: 161 ins; 10 del; 35 mod

8273559: Shenandoah: Shenandoah should support multi-threaded heap dump

Reviewed-by: shade, rkennke, sgehwolf

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 15:38:18 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 15:38:18 GMT
Subject: RFR: 8273823: Problemlist gc/stringdedup tests timing out on ZGC
Message-ID: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>

Hi all,

  can I have reviews for problemlist the gc/stringdedup tests for ZGC? They time out a lot in CI currently, and generate a lot of noise.

Testing: CI run with this change does not run the #id4 tests any more

Thanks,
  Thomas

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

Commit messages:
 - Problemlist gc/stringdedup for zgc because of many failures

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

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


From zgu at openjdk.java.net  Wed Sep 15 15:44:02 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 15:44:02 GMT
Subject: RFR: 8273823: Problemlist gc/stringdedup tests timing out on ZGC
In-Reply-To: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
References: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
Message-ID: <DyE4K6I93DD06H8lcdWvtYgP-vqcW2SkZKi7KruwXpE=.f8c9468b-6cb0-4a8e-aeaf-bfc2289ac2d7@github.com>

On Wed, 15 Sep 2021 15:29:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for problemlist the gc/stringdedup tests for ZGC? They time out a lot in CI currently, and generate a lot of noise.
> 
> Testing: CI run with this change does not run the #id4 tests any more
> 
> Thanks,
>   Thomas

Looks good and trivial

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

Marked as reviewed by zgu (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep 15 15:49:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 15:49:57 GMT
Subject: RFR: 8273823: Problemlist gc/stringdedup tests timing out on ZGC
In-Reply-To: <-iogOwhtjx7CVX3qEakIU6Ome2xzeR7UaPZLT81UiOU=.06f724ab-2c41-4f19-97c9-36b9681574ad@github.com>
References: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
 <-iogOwhtjx7CVX3qEakIU6Ome2xzeR7UaPZLT81UiOU=.06f724ab-2c41-4f19-97c9-36b9681574ad@github.com>
Message-ID: <o0lqooLayn6UC5Dg0KUzlBVbE0gJxADqVIhQt-mWBS8=.cb0d25d2-490e-4da5-a7af-47a3a885ccf0@github.com>

On Wed, 15 Sep 2021 15:45:51 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for problemlist the gc/stringdedup tests for ZGC? They time out a lot in CI currently, and generate a lot of noise.
>> 
>> Testing: CI run with this change does not run the #id4 tests any more
>> 
>> Thanks,
>>   Thomas
>
> Looks good and trivial. Thanks for problem listing these tests!

Thanks @lkorinth @zhengyu123 for your reviews.

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

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


From lkorinth at openjdk.java.net  Wed Sep 15 15:49:57 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Wed, 15 Sep 2021 15:49:57 GMT
Subject: RFR: 8273823: Problemlist gc/stringdedup tests timing out on ZGC
In-Reply-To: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
References: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
Message-ID: <-iogOwhtjx7CVX3qEakIU6Ome2xzeR7UaPZLT81UiOU=.06f724ab-2c41-4f19-97c9-36b9681574ad@github.com>

On Wed, 15 Sep 2021 15:29:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for problemlist the gc/stringdedup tests for ZGC? They time out a lot in CI currently, and generate a lot of noise.
> 
> Testing: CI run with this change does not run the #id4 tests any more
> 
> Thanks,
>   Thomas

Looks good and trivial. Thanks for problem listing these tests!

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

Marked as reviewed by lkorinth (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep 15 15:52:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 15:52:53 GMT
Subject: Integrated: 8273823: Problemlist gc/stringdedup tests timing out on
 ZGC
In-Reply-To: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
References: <OPDEctd4To5sWFUjG50jBoAtt4HAMI4I9MuG7jZ3-ws=.ceb582d0-47f8-4e89-aab8-f33b766a6462@github.com>
Message-ID: <JpDZ2sMLrdY_H2lA5KolieN2WYMaJ2x2qDZEJttw9_8=.17b03f34-4b26-4121-91ee-b219f5e25f71@github.com>

On Wed, 15 Sep 2021 15:29:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for problemlist the gc/stringdedup tests for ZGC? They time out a lot in CI currently, and generate a lot of noise.
> 
> Testing: CI run with this change does not run the #id4 tests any more
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 7b2beb6b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7b2beb6ba6df868fa8e44701f906c40bb7c407bb
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8273823: Problemlist gc/stringdedup tests timing out on ZGC

Reviewed-by: zgu, lkorinth

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 16:22:13 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 16:22:13 GMT
Subject: RFR: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a
 @requires vm.gc.shenandoah
Message-ID: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>

Hi all,

  can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?

Currently testing tier2 with this change, but I expect this to work.

Thanks,
  Thomas

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

Commit messages:
 - Add requires label

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

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


From zgu at openjdk.java.net  Wed Sep 15 16:27:56 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 15 Sep 2021 16:27:56 GMT
Subject: RFR: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a
 @requires vm.gc.shenandoah
In-Reply-To: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
References: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
Message-ID: <gIhZHIGIMfrEgEI4uhP6M3wnaa4RjmVgaKhcrIMIWOU=.980f37c0-7c95-4ed6-a8c5-d2033144c5d3@github.com>

On Wed, 15 Sep 2021 16:14:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?
> 
> Currently testing tier2 with this change, but I expect this to work.
> 
> Thanks,
>   Thomas

Looks good and trivial

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

Marked as reviewed by zgu (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep 15 17:24:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 17:24:53 GMT
Subject: Integrated: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not
 have a @requires vm.gc.shenandoah
In-Reply-To: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
References: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
Message-ID: <nIkqPW5mLTxIWOL4zlByMhkEyHzzgi4J6XQxEYF_6zU=.c0b73c43-8e8a-4cbf-88af-3cf5a1af66a5@github.com>

On Wed, 15 Sep 2021 16:14:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?
> 
> Currently testing tier2 with this change, but I expect this to work.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: cbffecc6
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cbffecc61e4a9ac1172926ef4f20d918d73adde9
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a @requires vm.gc.shenandoah

Reviewed-by: zgu

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

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


From tschatzl at openjdk.java.net  Wed Sep 15 17:24:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 15 Sep 2021 17:24:52 GMT
Subject: RFR: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a
 @requires vm.gc.shenandoah
In-Reply-To: <gIhZHIGIMfrEgEI4uhP6M3wnaa4RjmVgaKhcrIMIWOU=.980f37c0-7c95-4ed6-a8c5-d2033144c5d3@github.com>
References: <Mx_EWlZxeRPqOowWEX0F7D79VoMl_vAj4qQ8ei43OoE=.5cc0a6fe-3526-4ba4-b328-c5f6250ad905@github.com>
 <gIhZHIGIMfrEgEI4uhP6M3wnaa4RjmVgaKhcrIMIWOU=.980f37c0-7c95-4ed6-a8c5-d2033144c5d3@github.com>
Message-ID: <LMneEENt845XNwyDdzPfUzbfDP4FePVCp2WwhuWxZ7g=.dc3ef59a-7339-469d-866f-3402408afe2f@github.com>

On Wed, 15 Sep 2021 16:25:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get quick reviews for this change adding necessary @requires labels for builds without Shenandoah?
>> 
>> Currently testing tier2 with this change, but I expect this to work.
>> 
>> Thanks,
>>   Thomas
>
> Looks good and trivial

Thanks @zhengyu123 for your reviews.

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

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


From ayang at openjdk.java.net  Wed Sep 15 18:57:50 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 15 Sep 2021 18:57:50 GMT
Subject: RFR: 8273805: gc/g1/TestGCLogMessages.java test should handle
 non-JFR configs
In-Reply-To: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
References: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
Message-ID: <iNAodJMVOnHCmPEfNzuuOLvawNKN7mnIVi_mTqWzFMc=.2096d6aa-367f-4f3b-88c7-43bad6980a38@github.com>

On Wed, 15 Sep 2021 10:43:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8273147 introduced a more thorough GC messages test, which includes JFR. But it is not guaranteed that JFR is actually in the build, like in the case of Zero:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/g1/TestGCLogMessages.java
> 
> java.lang.RuntimeException: '[debug.*Weak JFR Old Object Samples' missing from stdout/stderr
> 
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:340)
> at gc.g1.TestGCLogMessages.checkMessagesAtLevel(TestGCLogMessages.java:193)
> at gc.g1.TestGCLogMessages.testNormalLogs(TestGCLogMessages.java:224)
> at gc.g1.TestGCLogMessages.main(TestGCLogMessages.java:199)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Luckily, the test already uses `WhiteBox`, so we can just ask if JFR is in the build or not.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, affected test now passes
>  - [x] Linux x86_64 Server, affected test still passes
>  - [x]  Linux x86_64 Server, verified the JFR test path is taken

Marked as reviewed by ayang (Reviewer).

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

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


From shade at openjdk.java.net  Thu Sep 16 08:27:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 08:27:52 GMT
Subject: RFR: 8273805: gc/g1/TestGCLogMessages.java test should handle
 non-JFR configs
In-Reply-To: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
References: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
Message-ID: <kivqk_Kjkv-0_6Q1UwFCDhM7-70Z8LUIC-k3Rmwq9HY=.2d156e9c-5b19-4d3c-9db2-6c5c5032acb9@github.com>

On Wed, 15 Sep 2021 10:43:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8273147 introduced a more thorough GC messages test, which includes JFR. But it is not guaranteed that JFR is actually in the build, like in the case of Zero:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/g1/TestGCLogMessages.java
> 
> java.lang.RuntimeException: '[debug.*Weak JFR Old Object Samples' missing from stdout/stderr
> 
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:340)
> at gc.g1.TestGCLogMessages.checkMessagesAtLevel(TestGCLogMessages.java:193)
> at gc.g1.TestGCLogMessages.testNormalLogs(TestGCLogMessages.java:224)
> at gc.g1.TestGCLogMessages.main(TestGCLogMessages.java:199)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Luckily, the test already uses `WhiteBox`, so we can just ask if JFR is in the build or not.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, affected test now passes
>  - [x] Linux x86_64 Server, affected test still passes
>  - [x]  Linux x86_64 Server, verified the JFR test path is taken

Thanks, I'll integrate now.

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

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


From shade at openjdk.java.net  Thu Sep 16 08:27:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 08:27:53 GMT
Subject: Integrated: 8273805: gc/g1/TestGCLogMessages.java test should handle
 non-JFR configs
In-Reply-To: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
References: <YjP426-1lLNtH5SyjCp87ihVF-u-wavuhTcVTw6CVcQ=.ee1aa04b-e531-44c1-94a4-8bf3eb3ae71f@github.com>
Message-ID: <NzA109kYJKHpQi-A9ezkc_-SWb1K9m3Cz1dT79DwB3I=.24c6917e-7c7c-4ace-85b1-722b5741d814@github.com>

On Wed, 15 Sep 2021 10:43:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8273147 introduced a more thorough GC messages test, which includes JFR. But it is not guaranteed that JFR is actually in the build, like in the case of Zero:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=gc/g1/TestGCLogMessages.java
> 
> java.lang.RuntimeException: '[debug.*Weak JFR Old Object Samples' missing from stdout/stderr
> 
> at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:340)
> at gc.g1.TestGCLogMessages.checkMessagesAtLevel(TestGCLogMessages.java:193)
> at gc.g1.TestGCLogMessages.testNormalLogs(TestGCLogMessages.java:224)
> at gc.g1.TestGCLogMessages.main(TestGCLogMessages.java:199)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Luckily, the test already uses `WhiteBox`, so we can just ask if JFR is in the build or not.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, affected test now passes
>  - [x] Linux x86_64 Server, affected test still passes
>  - [x]  Linux x86_64 Server, verified the JFR test path is taken

This pull request has now been integrated.

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

8273805: gc/g1/TestGCLogMessages.java test should handle non-JFR configs

Reviewed-by: tschatzl, ayang

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

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


From tschatzl at openjdk.java.net  Thu Sep 16 08:35:45 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 16 Sep 2021 08:35:45 GMT
Subject: RFR: 8273626: G1: refactor G1CardSetAllocator to support element
 size less pointer size
In-Reply-To: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
Message-ID: <jZIA2e_rEvA1hyE8cZ45Qrejat7WLBM_AwR6V4U7qB0=.34477e7e-1220-46c2-89ce-a4537798b881@github.com>

On Sat, 11 Sep 2021 05:05:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.
> 
> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

Hi Hamlin,

  just fyi, I am aware that this CR is out, but currently I am a too busy looking into nontrivial PRs with some pre/post-JDK17 GA work. Initial look seems good though.

Thomas

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

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


From tschatzl at openjdk.java.net  Thu Sep 16 08:41:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 16 Sep 2021 08:41:47 GMT
Subject: RFR: 8272083: G1: Record iterated range for BOT performance
 during card scan [v3]
In-Reply-To: <Y2DJ7nuOvNRMPgJ0_hlPflslTC4sfvfII_k7ufnA2s0=.1830b61f-aa7f-47b1-a33f-c2807f34fb38@github.com>
References: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
 <Y2DJ7nuOvNRMPgJ0_hlPflslTC4sfvfII_k7ufnA2s0=.1830b61f-aa7f-47b1-a33f-c2807f34fb38@github.com>
Message-ID: <ggxbD7RT0n4w23BrjBSX9lR-klE2u99-e-Y1NzdNTBE=.a0145ec3-1d7a-4a1e-910d-bb13c885c51d@github.com>

On Mon, 13 Sep 2021 04:44:51 GMT, Yude Lin <github.com+16811675+linade at openjdk.org> wrote:

>> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000).
>> 
>> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern.
>
> Yude Lin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Resolve TODOs

Hi linade,

  just fyi, I am aware that you posted another change for this, but currently I am a too busy looking into nontrivial PRs with some  pre/post-JDK17 GA work. I started some internal specjbb2015 runs where critical-jops look like they improved, i.e. I noticed single scores higher than usual, but also with higher than usual variance. This was kind of expected according to your comments, but this just means we should just look into this some more.

Thomas

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

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


From lkorinth at openjdk.java.net  Thu Sep 16 09:25:44 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Thu, 16 Sep 2021 09:25:44 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <kZgu3uGSXxksk8WD9Z3FnW6dEtnBmCdcZNW013OUOvk=.7d679653-cd1c-4003-8b5b-ea263e221c85@github.com>

On Mon, 6 Sep 2021 08:26:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

While the change looks good, I agree with Thomas that it is better to remove the trace altogether. Also, in general it is not always better to move the ResourceMark closer to the allocation. I think you should rename the enhancement to a name that betters describe the new code, and removing the trace (and ResourceMark) is the best way forward.

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

Changes requested by lkorinth (Reviewer).

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


From github.com+16811675+linade at openjdk.java.net  Thu Sep 16 09:28:43 2021
From: github.com+16811675+linade at openjdk.java.net (Yude Lin)
Date: Thu, 16 Sep 2021 09:28:43 GMT
Subject: RFR: 8272083: G1: Record iterated range for BOT performance
 during card scan [v3]
In-Reply-To: <ggxbD7RT0n4w23BrjBSX9lR-klE2u99-e-Y1NzdNTBE=.a0145ec3-1d7a-4a1e-910d-bb13c885c51d@github.com>
References: <Wdq6RiNvyA5Vc1MUonB8r-ySCCdzdmAIEwAobaIpwLY=.5ac0e65a-c037-4628-8c3f-409a56b7b5b9@github.com>
 <Y2DJ7nuOvNRMPgJ0_hlPflslTC4sfvfII_k7ufnA2s0=.1830b61f-aa7f-47b1-a33f-c2807f34fb38@github.com>
 <ggxbD7RT0n4w23BrjBSX9lR-klE2u99-e-Y1NzdNTBE=.a0145ec3-1d7a-4a1e-910d-bb13c885c51d@github.com>
Message-ID: <AnYULSRXmUxNLdCD7UcelhRTMNu0rI67fGkH8lJktxI=.4d0bf003-477a-4bd2-98f7-b1491dc85a59@github.com>

On Thu, 16 Sep 2021 08:38:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi linade,
> 
> just fyi, I am aware that you posted another change for this, but currently I am a too busy looking into nontrivial PRs with some pre/post-JDK17 GA work. I started some internal specjbb2015 runs where critical-jops look like they improved, i.e. I noticed single scores higher than usual, but also with higher than usual variance. This was kind of expected according to your comments, but this just means we should just look into this some more.
> 
> Thomas

Hi Thomas,

No worries. I expected it would take some time to review, especially with jdk17 just released. Thanks for the testing. Looking forward to more feedbacks!

Yude

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

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


From ayang at openjdk.java.net  Thu Sep 16 10:02:19 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 16 Sep 2021 10:02:19 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor [v2]
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

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

  remove tracemsg

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5375/files
  - new: https://git.openjdk.java.net/jdk/pull/5375/files/c6c9335e..ec25f9e9

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

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

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


From ayang at openjdk.java.net  Thu Sep 16 10:02:20 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 16 Sep 2021 10:02:20 GMT
Subject: RFR: 8273372: More precise ResourceMark in ReferenceProcessor
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <Evc9haFj0G09NDc80CKuywWesMo-GDnoMYY_hf2bkhU=.2c752358-d983-4080-87f5-2c1ea3ff12db@github.com>

On Mon, 6 Sep 2021 08:26:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

Removed those trace messages as suggested, because the signal-to-noise ratio is too low in them.

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

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


From lkorinth at openjdk.java.net  Thu Sep 16 10:47:43 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Thu, 16 Sep 2021 10:47:43 GMT
Subject: RFR: 8273372: Remove scavenge trace message in psPromotionManager
 [v2]
In-Reply-To: <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
 <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>
Message-ID: <A8aaOkNN7OF9MuB_BjFH_FOxd87qPKrSNRQubBMF-Go=.29822afc-d08c-4efc-9dcc-b6bc71d3a409@github.com>

On Thu, 16 Sep 2021 10:02:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving `ResourceMark` closer to where it is actually required.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tracemsg

Looks good to me!

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

Marked as reviewed by lkorinth (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Sep 16 11:33:46 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 16 Sep 2021 11:33:46 GMT
Subject: RFR: 8273372: Remove scavenge trace message in psPromotionManager
 [v2]
In-Reply-To: <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
 <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>
Message-ID: <n4iDNp2Jw4rYDbEi_1-j067vLXo-isQkjnCd2AyOG8I=.e09b2471-f9f9-43cd-949e-146b37545f63@github.com>

On Thu, 16 Sep 2021 10:02:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving `ResourceMark` closer to where it is actually required.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tracemsg

Ship it.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Thu Sep 16 11:44:51 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 16 Sep 2021 11:44:51 GMT
Subject: RFR: 8273372: Remove scavenge trace message in psPromotionManager
 [v2]
In-Reply-To: <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
 <9hpB7Uz-jjJyFcbcRxECzUHcesqejjGQxp6un9b18OU=.4df6e583-ce1f-4dcb-8ad6-59b31290f054@github.com>
Message-ID: <BcyqJS2ApYen9aqj22Ey7rXqHCfH8JxJyKCtvtv_9vw=.4e5b5985-b2b1-4324-8922-0a4f5a263c62@github.com>

On Thu, 16 Sep 2021 10:02:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving `ResourceMark` closer to where it is actually required.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove tracemsg

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Sep 16 11:44:51 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 16 Sep 2021 11:44:51 GMT
Subject: Integrated: 8273372: Remove scavenge trace message in
 psPromotionManager
In-Reply-To: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
References: <k16SPguc4xfk5EfVbBJhuqFe1CCEW0y9YFSUhdhs1yI=.48f4b12e-e1b9-4271-a7ce-25349a7ded7e@github.com>
Message-ID: <7YqSxqsHY3fw9JHMo5HGYe-rNqWwmD4Zdcv5YAivpFA=.f5b8f364-c581-4595-a3dc-cd90143fa400@github.com>

On Mon, 6 Sep 2021 08:26:37 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `ResourceMark` closer to where it is actually required.
> 
> Test: tier1-6

This pull request has now been integrated.

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

8273372: Remove scavenge trace message in psPromotionManager

Reviewed-by: tschatzl, lkorinth

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

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


From mli at openjdk.java.net  Thu Sep 16 13:48:44 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 16 Sep 2021 13:48:44 GMT
Subject: RFR: 8273626: G1: refactor G1CardSetAllocator to support element
 size less pointer size
In-Reply-To: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
Message-ID: <a3J7p8NV1u794gzhZ9D-Dr-v7Ep7q7c1z6S2Er9cgCg=.877f31b7-3985-4041-81e7-d1f678013d1e@github.com>

On Sat, 11 Sep 2021 05:05:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.
> 
> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

Thanks for the information, Thomas.
Sure, no hurry, please take your time.

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

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


From tschatzl at openjdk.java.net  Fri Sep 17 14:16:00 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 17 Sep 2021 14:16:00 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v11]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> 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 14 commits:

 - Merge branch 'master' into pull/5037-tighten-condition
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Fix compilation after merge
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Add enqueue callback
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - ayang comments; note that the mentioned crash is still not fixed.
 - Merge master
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - More updates to comment
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/27d747ad...c708d5cb

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

Changes: https://git.openjdk.java.net/jdk/pull/5037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=10
  Stats: 290 lines in 23 files changed: 147 ins; 83 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5037/head:pull/5037

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


From sjohanss at openjdk.java.net  Mon Sep 20 10:02:54 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 20 Sep 2021 10:02:54 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <udtIwJGUr7bLjF0a6DZ0aQecb9DwdiKkAGjZhUu6xe8=.c0115ff2-8890-46f8-9b14-fb68ae786f85@github.com>

On Wed, 8 Sep 2021 15:09:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Looks good in general, just one question.

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

> 488:   trace_phase(_gc_par_phases[RedirtyCards]);
> 489:   debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
> 490:   if (_gc_par_phases[RestorePreservedMarks]->uninitialized()) {

This looks a bit strange, why isn't this check using the passed in `evacuation_failed` like above? And if it can't shouldn't the check be `!_gc_par_phases[RestorePreservedMarks]->uninitialized()`?

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

Changes requested by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Sep 20 11:24:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 20 Sep 2021 11:24:57 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector
In-Reply-To: <udtIwJGUr7bLjF0a6DZ0aQecb9DwdiKkAGjZhUu6xe8=.c0115ff2-8890-46f8-9b14-fb68ae786f85@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
 <udtIwJGUr7bLjF0a6DZ0aQecb9DwdiKkAGjZhUu6xe8=.c0115ff2-8890-46f8-9b14-fb68ae786f85@github.com>
Message-ID: <MdmCWmo5uBQiWuGdFMnb_dkrtX604zaf0ehNavHV7XQ=.87723e5b-1cef-4a48-a411-6a3277bfdd5e@github.com>

On Mon, 20 Sep 2021 09:55:30 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 490:
> 
>> 488:   trace_phase(_gc_par_phases[RedirtyCards]);
>> 489:   debug_time("Post Evacuate Cleanup 2", _cur_post_evacuate_cleanup_2_time_ms);
>> 490:   if (_gc_par_phases[RestorePreservedMarks]->uninitialized()) {
> 
> This looks a bit strange, why isn't this check using the passed in `evacuation_failed` like above? And if it can't shouldn't the check be `!_gc_par_phases[RestorePreservedMarks]->uninitialized()`?

Probably some oversight when implementing some variants in that area. Will fix.

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

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


From tschatzl at openjdk.java.net  Mon Sep 20 11:38:32 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 20 Sep 2021 11:38:32 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v2]
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <SHcIXu2ehGyUbP8KR47QFKQmj1_6j38V0xt9zc3dhmY=.5589077f-4be1-4205-ab47-6baa7b3f9b16@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> 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 three commits:

 - sjohanss review
 - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
 - Move evac failure handling to young gc

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

Changes: https://git.openjdk.java.net/jdk/pull/5419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5419&range=01
  Stats: 160 lines in 13 files changed: 57 ins; 47 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5419/head:pull/5419

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


From sjohanss at openjdk.java.net  Mon Sep 20 12:29:04 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 20 Sep 2021 12:29:04 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v2]
In-Reply-To: <SHcIXu2ehGyUbP8KR47QFKQmj1_6j38V0xt9zc3dhmY=.5589077f-4be1-4205-ab47-6baa7b3f9b16@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
 <SHcIXu2ehGyUbP8KR47QFKQmj1_6j38V0xt9zc3dhmY=.5589077f-4be1-4205-ab47-6baa7b3f9b16@github.com>
Message-ID: <wN3hq9hpQZUT_iScE9nJfqh8AeFESkOqVSkaFvFh5AU=.f0d3ec27-b15d-4b6b-9475-ef4be0cb5dcc@github.com>

On Mon, 20 Sep 2021 11:38:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
>> 
>> Testing: tier1-3
>> 
>> 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 three commits:
> 
>  - sjohanss review
>  - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
>  - Move evac failure handling to young gc

Marked as reviewed by sjohanss (Reviewer).

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

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


From sjohanss at openjdk.java.net  Mon Sep 20 12:33:56 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 20 Sep 2021 12:33:56 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v11]
In-Reply-To: <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
Message-ID: <ZGuHYAtGXW_nXSrhqXjETRkOmwrEDeNaddY7h2FVijo=.fce378dc-731f-4704-a00c-8e2e320c4ad9@github.com>

On Fri, 17 Sep 2021 14:16:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> 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 14 commits:
> 
>  - Merge branch 'master' into pull/5037-tighten-condition
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - Fix compilation after merge
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - Add enqueue callback
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - ayang comments; note that the mentioned crash is still not fixed.
>  - Merge master
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - More updates to comment
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/27d747ad...c708d5cb

Sorry for not getting to this one until now, but took a first quick look at this. 

Apart from the small comment below, I think we might want to split this into two separate PRs. One to add the new reference processing abstraction with the general use and then do the specific G1 changes as another PR. What do you think about that?

src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp line 116:

> 114:   if (!dest_attr.is_in_cset()) {
> 115:     enqueue_card_if_tracked(dest_attr, p, obj);
> 116:   }

If I understand this correctly, the only time `dest_attr.is_in_cset() == true` is when `obj` is in a region that failed evacuation, right? To make this even more obvious could we add an else-statement with an assert that this is the case?

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

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


From tschatzl at openjdk.java.net  Mon Sep 20 14:16:58 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 20 Sep 2021 14:16:58 GMT
Subject: RFR: 8273940:
 vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in
 full gc during VM exit
Message-ID: <jUwEWy2TKcb_s68bNLNw1zk_amDqEoFSG1Q6GMQJfh4=.d1b39a90-10b2-4a39-a2bb-67e65a651c31@github.com>

Hi all,

  this change fixes random crashes at VM exit by reverting JDK-8273605 (02af541b7427a4b74eecab9513a770026d1a8426). Testing showed that without that change, around 2000 executions of the failing tests passes, while otherwise there is a failure rate of around 2% (13 out of 600).

Since I do not have time to fix this properly, and this is an annoying issue, I propose to remove that change and re-implement later (I'll file a new issue for the original change).

Revert applies cleanly.

Testing: tier1, the failing test a few thousand times

Thanks,
  Thomas

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

Commit messages:
 - Fixed random crashes at VM exit by reverting JDK-8273605 (02af541b7427a4b74eecab9513a770026d1a8426)

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

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


From lkorinth at openjdk.java.net  Mon Sep 20 15:47:53 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 20 Sep 2021 15:47:53 GMT
Subject: RFR: 8273940:
 vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in
 full gc during VM exit
In-Reply-To: <jUwEWy2TKcb_s68bNLNw1zk_amDqEoFSG1Q6GMQJfh4=.d1b39a90-10b2-4a39-a2bb-67e65a651c31@github.com>
References: <jUwEWy2TKcb_s68bNLNw1zk_amDqEoFSG1Q6GMQJfh4=.d1b39a90-10b2-4a39-a2bb-67e65a651c31@github.com>
Message-ID: <wDCssp0pvMSG7SeZ16S7RD2bCewdTdggjWzEj-hi2RE=.44abebc9-611f-42df-9343-54bd71458f8f@github.com>

On Mon, 20 Sep 2021 13:56:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   this change fixes random crashes at VM exit by reverting JDK-8273605 (02af541b7427a4b74eecab9513a770026d1a8426). Testing showed that without that change, around 2000 executions of the failing tests passes, while otherwise there is a failure rate of around 2% (13 out of 600).
> 
> Since I do not have time to fix this properly, and this is an annoying issue, I propose to remove that change and re-implement later (I'll file a new issue for the original change).
> 
> Revert applies cleanly.
> 
> Testing: tier1, the failing test a few thousand times
> 
> Thanks,
>   Thomas

Looks good and trivial!

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

Marked as reviewed by lkorinth (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Sep 20 16:21:58 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 20 Sep 2021 16:21:58 GMT
Subject: RFR: 8273940:
 vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in
 full gc during VM exit
In-Reply-To: <wDCssp0pvMSG7SeZ16S7RD2bCewdTdggjWzEj-hi2RE=.44abebc9-611f-42df-9343-54bd71458f8f@github.com>
References: <jUwEWy2TKcb_s68bNLNw1zk_amDqEoFSG1Q6GMQJfh4=.d1b39a90-10b2-4a39-a2bb-67e65a651c31@github.com>
 <wDCssp0pvMSG7SeZ16S7RD2bCewdTdggjWzEj-hi2RE=.44abebc9-611f-42df-9343-54bd71458f8f@github.com>
Message-ID: <gKYOCd9613fYGajD3aeRw5YBPln-bWF3zxc1JrrN42E=.759bcf37-60e7-4a34-9048-3e8ffc8b9c22@github.com>

On Mon, 20 Sep 2021 15:44:23 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Hi all,
>> 
>>   this change fixes random crashes at VM exit by reverting JDK-8273605 (02af541b7427a4b74eecab9513a770026d1a8426). Testing showed that without that change, around 2000 executions of the failing tests passes, while otherwise there is a failure rate of around 2% (13 out of 600).
>> 
>> Since I do not have time to fix this properly, and this is an annoying issue, I propose to remove that change and re-implement later (I'll file a new issue for the original change).
>> 
>> Revert applies cleanly.
>> 
>> Testing: tier1, the failing test a few thousand times
>> 
>> Thanks,
>>   Thomas
>
> Looks good and trivial!

Thanks for your review @lkorinth .

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

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


From tschatzl at openjdk.java.net  Mon Sep 20 16:21:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 20 Sep 2021 16:21:59 GMT
Subject: Integrated: 8273940:
 vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in
 full gc during VM exit
In-Reply-To: <jUwEWy2TKcb_s68bNLNw1zk_amDqEoFSG1Q6GMQJfh4=.d1b39a90-10b2-4a39-a2bb-67e65a651c31@github.com>
References: <jUwEWy2TKcb_s68bNLNw1zk_amDqEoFSG1Q6GMQJfh4=.d1b39a90-10b2-4a39-a2bb-67e65a651c31@github.com>
Message-ID: <hU1H9xElTc6euoKKNBcxkCV4LCoM9tLJDpqCkRB-Q44=.91023d64-1821-4213-a761-3b3877796e13@github.com>

On Mon, 20 Sep 2021 13:56:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   this change fixes random crashes at VM exit by reverting JDK-8273605 (02af541b7427a4b74eecab9513a770026d1a8426). Testing showed that without that change, around 2000 executions of the failing tests passes, while otherwise there is a failure rate of around 2% (13 out of 600).
> 
> Since I do not have time to fix this properly, and this is an annoying issue, I propose to remove that change and re-implement later (I'll file a new issue for the original change).
> 
> Revert applies cleanly.
> 
> Testing: tier1, the failing test a few thousand times
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 4b3a4fff
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4b3a4fff39c1fba0d7eae719525e2a46b0a6d6ed
Stats:     15 lines in 3 files changed: 1 ins; 12 del; 2 mod

8273940: vmTestbase/vm/mlvm/meth/stress/gc/callSequencesDuringGC/Test.java crashes in full gc during VM exit

Reviewed-by: lkorinth

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 08:48:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 08:48:43 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v11]
In-Reply-To: <ZGuHYAtGXW_nXSrhqXjETRkOmwrEDeNaddY7h2FVijo=.fce378dc-731f-4704-a00c-8e2e320c4ad9@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
 <ZGuHYAtGXW_nXSrhqXjETRkOmwrEDeNaddY7h2FVijo=.fce378dc-731f-4704-a00c-8e2e320c4ad9@github.com>
Message-ID: <GCPvpxx7eqTIdDF1l0IQsvL0egvkW6RloeO0iDD7RDU=.4c607da1-5559-444a-af82-01e8136958df@github.com>

On Mon, 20 Sep 2021 12:30:58 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Sorry for not getting to this one until now, but took a first quick look at this.
> 
> Apart from the small comment below, I think we might want to split this into two separate PRs. One to add the new reference processing abstraction with the general use and then do the specific G1 changes as another PR. What do you think about that?

I will first revert the faulty JDK-8270842, then add the API, then add the G1 specific code if you prefer.

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

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


From sjohanss at openjdk.java.net  Tue Sep 21 09:00:48 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 21 Sep 2021 09:00:48 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v11]
In-Reply-To: <GCPvpxx7eqTIdDF1l0IQsvL0egvkW6RloeO0iDD7RDU=.4c607da1-5559-444a-af82-01e8136958df@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
 <ZGuHYAtGXW_nXSrhqXjETRkOmwrEDeNaddY7h2FVijo=.fce378dc-731f-4704-a00c-8e2e320c4ad9@github.com>
 <GCPvpxx7eqTIdDF1l0IQsvL0egvkW6RloeO0iDD7RDU=.4c607da1-5559-444a-af82-01e8136958df@github.com>
Message-ID: <PQOgrxqIKd_AuLnjyBPEK-FX3KceID_P8hEK-g5rUGY=.8adfe411-5d1c-4736-8153-cdfaa6b9d0d1@github.com>

On Tue, 21 Sep 2021 08:45:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I will first revert the faulty JDK-8270842, then add the API, then add the G1 specific code if you prefer.

Sounds good to me.

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 09:23:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 09:23:55 GMT
Subject: Integrated: 8274053: [BACKOUT] JDK-8270842: G1: Only young regions
 need to redirty outside references in remset.
Message-ID: <PjwtZX49PD39CviuCLjZa0kerRvSyTOQwFOFWLjhcVs=.4db4592a-ebc8-4193-b2ce-ddc3e489dbf9@github.com>

Hi all,

  can I have reviews for this clean backout of JDK-8270842/PR#4853 because it is buggy - it drops re-scanning of failed objects in old generation during self-forward removal. However the previous attempt to mark the card of the discovered reference field for j.l.ref.References might not have been processed correctly as the card table may not be in a state to properly handle regular write barrier writes. More information in PR#5037.

I will follow-up with a correct solution.

Testing: GHA (this is a clean backout)

Thanks,
  Thomas

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

Commit messages:
 - Backout JDK-8270842 because it's buggy.

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

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


From sjohanss at openjdk.java.net  Tue Sep 21 09:23:55 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 21 Sep 2021 09:23:55 GMT
Subject: Integrated: 8274053: [BACKOUT] JDK-8270842: G1: Only young
 regions need to redirty outside references in remset.
In-Reply-To: <PjwtZX49PD39CviuCLjZa0kerRvSyTOQwFOFWLjhcVs=.4db4592a-ebc8-4193-b2ce-ddc3e489dbf9@github.com>
References: <PjwtZX49PD39CviuCLjZa0kerRvSyTOQwFOFWLjhcVs=.4db4592a-ebc8-4193-b2ce-ddc3e489dbf9@github.com>
Message-ID: <nD_vxcEgAbCWldMVxAyQpOUIS8n5wEzFsF8d1gbc2XU=.901f4008-4d5f-4de7-893d-1eede4db159f@github.com>

On Tue, 21 Sep 2021 09:11:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this clean backout of JDK-8270842/PR#4853 because it is buggy - it drops re-scanning of failed objects in old generation during self-forward removal. However the previous attempt to mark the card of the discovered reference field for j.l.ref.References might not have been processed correctly as the card table may not be in a state to properly handle regular write barrier writes. More information in PR#5037.
> 
> I will follow-up with a correct solution.
> 
> Testing: GHA (this is a clean backout)
> 
> Thanks,
>   Thomas

Looks good.

And since it is small and a clean back-out we can consider it trivial.

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

Marked as reviewed by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Sep 21 09:23:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 09:23:56 GMT
Subject: Integrated: 8274053: [BACKOUT] JDK-8270842: G1: Only young
 regions need to redirty outside references in remset.
In-Reply-To: <nD_vxcEgAbCWldMVxAyQpOUIS8n5wEzFsF8d1gbc2XU=.901f4008-4d5f-4de7-893d-1eede4db159f@github.com>
References: <PjwtZX49PD39CviuCLjZa0kerRvSyTOQwFOFWLjhcVs=.4db4592a-ebc8-4193-b2ce-ddc3e489dbf9@github.com>
 <nD_vxcEgAbCWldMVxAyQpOUIS8n5wEzFsF8d1gbc2XU=.901f4008-4d5f-4de7-893d-1eede4db159f@github.com>
Message-ID: <JkDnvGj0U1_xApGgg-AqO05y7RhWoh6ow-FaKnsttKQ=.8a45504b-c1a9-47ff-8d56-452127913baa@github.com>

On Tue, 21 Sep 2021 09:18:05 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this clean backout of JDK-8270842/PR#4853 because it is buggy - it drops re-scanning of failed objects in old generation during self-forward removal. However the previous attempt to mark the card of the discovered reference field for j.l.ref.References might not have been processed correctly as the card table may not be in a state to properly handle regular write barrier writes. More information in PR#5037.
>> 
>> I will follow-up with a correct solution.
>> 
>> Testing: GHA (this is a clean backout)
>> 
>> Thanks,
>>   Thomas
>
> And since it is small and a clean back-out we can consider it trivial.

Thanks @kstefanj for your review.

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 09:23:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 09:23:56 GMT
Subject: Integrated: 8274053: [BACKOUT] JDK-8270842: G1: Only young regions
 need to redirty outside references in remset.
In-Reply-To: <PjwtZX49PD39CviuCLjZa0kerRvSyTOQwFOFWLjhcVs=.4db4592a-ebc8-4193-b2ce-ddc3e489dbf9@github.com>
References: <PjwtZX49PD39CviuCLjZa0kerRvSyTOQwFOFWLjhcVs=.4db4592a-ebc8-4193-b2ce-ddc3e489dbf9@github.com>
Message-ID: <dpOVDhJn_UwCiMzm-DyfkYnDJ9cctwSfEcD5jEjnU8k=.5bc0ebfb-6c27-4d47-9b40-0e6d23e4175d@github.com>

On Tue, 21 Sep 2021 09:11:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this clean backout of JDK-8270842/PR#4853 because it is buggy - it drops re-scanning of failed objects in old generation during self-forward removal. However the previous attempt to mark the card of the discovered reference field for j.l.ref.References might not have been processed correctly as the card table may not be in a state to properly handle regular write barrier writes. More information in PR#5037.
> 
> I will follow-up with a correct solution.
> 
> Testing: GHA (this is a clean backout)
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: afd218d3
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/afd218d39a3125fcea50968edef6e6cfbacfff50
Stats:     15 lines in 1 file changed: 5 ins; 2 del; 8 mod

8274053: [BACKOUT] JDK-8270842: G1: Only young regions need to redirty outside references in remset.

Reviewed-by: sjohanss

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 10:40:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 10:40:22 GMT
Subject: RFR: 8274054: Add custom enqueue calls during reference processing
Message-ID: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>

Hi all,

  can I have reviews for this split-out of JDK-8271880/PR#5037 that only adds the interface and the default implementation to add custom "enqueue" calls to the VM?

For G1, the default (wrong) queue call is still used, that will be added with the other modifications to g1 later.

Testing: tier1-3

Thanks,
  Thomas

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

Commit messages:
 - Some indentation fixes
 - Add custom enqueue calls

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

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


From ayang at openjdk.java.net  Tue Sep 21 11:03:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 21 Sep 2021 11:03:42 GMT
Subject: RFR: 8274054: Add custom enqueue calls during reference processing
In-Reply-To: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
References: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
Message-ID: <Cf5eRfGyq-cdqjFZgDhKYxvCZSrFVXXf02GGh_lFtuc=.6486cd50-569e-4321-8af5-9dcb18ef7d41@github.com>

On Tue, 21 Sep 2021 10:33:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this split-out of JDK-8271880/PR#5037 that only adds the interface and the default implementation to add custom "enqueue" calls to the VM?
> 
> For G1, the default (wrong) queue call is still used, that will be added with the other modifications to g1 later.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 11:36:11 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 11:36:11 GMT
Subject: RFR: 8274068: Rename G1ScanInYoungSetter to G1SkipCardEnqueueSetter
Message-ID: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>

Hi all,

  can I get reviews for this renaming change? The reason for this renaming is that @ayang and me thought that it would be a more appropriate name during review of JDK-8271880 - causing the code to skip enqueuing cards.

Testing: gha, local compilation

Thanks,
  Thomas

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

Commit messages:
 - rename

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 11:53:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 11:53:04 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit
Message-ID: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>

Hi all,

  can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:

- remove declaration without definition
- move inlined code into hpp file
- factor out some code

Testing: gha, local compilation, local gc/g1

Thanks,
  Thomas

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

Commit messages:
 - Clean up

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 11:54:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 11:54:52 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v11]
In-Reply-To: <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
Message-ID: <JdKa_ExDuuzA23_gwsQ2sDQLKEeE_d0xDqS4DbkELac=.bf60d67c-451e-49a4-a110-018017bf1ab3@github.com>

On Fri, 17 Sep 2021 14:16:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> 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 14 commits:
> 
>  - Merge branch 'master' into pull/5037-tighten-condition
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - Fix compilation after merge
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - Add enqueue callback
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - ayang comments; note that the mentioned crash is still not fixed.
>  - Merge master
>  - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
>  - More updates to comment
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/27d747ad...c708d5cb

Already pushed PR for backing out the old change ([PR#5600](https://github.com/openjdk/jdk/pull/5600)) - thanks!

PRs for the preparatory changes are out: [PR#5607](https://github.com/openjdk/jdk/pull/5607) - some refactoring of G1ParScanThreadState, [PR#5605](https://github.com/openjdk/jdk/pull/5605) - some renaming of a class done here, [PR#5603](https://github.com/openjdk/jdk/pull/5603) - factoring out the enqueue call.

Thanks.

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

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


From sjohanss at openjdk.java.net  Tue Sep 21 12:00:45 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 21 Sep 2021 12:00:45 GMT
Subject: RFR: 8274068: Rename G1ScanInYoungSetter to
 G1SkipCardEnqueueSetter
In-Reply-To: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
References: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
Message-ID: <CHZ1OGFw6_gTHQM7cSb2ofZu1g2GqbILxQHL4GLgBUY=.7aebe0da-9898-4113-8e72-4ab9fcdae45a@github.com>

On Tue, 21 Sep 2021 11:26:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this renaming change? The reason for this renaming is that @ayang and me thought that it would be a more appropriate name during review of JDK-8271880 - causing the code to skip enqueuing cards.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

Lgtm

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Sep 21 12:05:45 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 21 Sep 2021 12:05:45 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit
In-Reply-To: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
Message-ID: <1gWH4fjxAljm15qyOoj6wFO2iXrKpLEwD0lrV-KJtNM=.04cf6bb9-749b-4f37-8dbb-ae072c3e227d@github.com>

On Tue, 21 Sep 2021 11:39:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
> 
> - remove declaration without definition
> - move inlined code into hpp file
> - factor out some code
> 
> Testing: gha, local compilation, local gc/g1
> 
> Thanks,
>   Thomas

?

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

Marked as reviewed by sjohanss (Reviewer).

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


From ayang at openjdk.java.net  Tue Sep 21 12:22:47 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 21 Sep 2021 12:22:47 GMT
Subject: RFR: 8274068: Rename G1ScanInYoungSetter to
 G1SkipCardEnqueueSetter
In-Reply-To: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
References: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
Message-ID: <0X3m-Iiqf9HD5N7c-Uaqb-3KS0KnV5w3l3lsbFXJYpY=.4e855705-30a2-4e6f-a904-3fa2bf28ceb6@github.com>

On Tue, 21 Sep 2021 11:26:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this renaming change? The reason for this renaming is that @ayang and me thought that it would be a more appropriate name during review of JDK-8271880 - causing the code to skip enqueuing cards.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Tue Sep 21 13:49:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 13:49:04 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v2]
In-Reply-To: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
Message-ID: <q7ppGRQJwqz2b0gVhzKSbbY0EqptEgVfl17kC0XpREg=.5ae1bf82-82f4-476e-bfb5-c6bc4f0b83ab@github.com>

> Hi all,
> 
>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
> 
> - remove declaration without definition
> - move inlined code into hpp file
> - factor out some code
> 
> Testing: gha, local compilation, local gc/g1
> 
> Thanks,
>   Thomas

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

  ayang review, renaming

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5607/files
  - new: https://git.openjdk.java.net/jdk/pull/5607/files/53997bce..8cf9b6a9

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

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

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


From ayang at openjdk.java.net  Tue Sep 21 14:26:36 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 21 Sep 2021 14:26:36 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v2]
In-Reply-To: <q7ppGRQJwqz2b0gVhzKSbbY0EqptEgVfl17kC0XpREg=.5ae1bf82-82f4-476e-bfb5-c6bc4f0b83ab@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
 <q7ppGRQJwqz2b0gVhzKSbbY0EqptEgVfl17kC0XpREg=.5ae1bf82-82f4-476e-bfb5-c6bc4f0b83ab@github.com>
Message-ID: <7pqUX_UKLKYr2y2KdqC-E36eRADMM8i1qHIQ1kh6N7A=.2ea6fd84-5543-4dd1-ad5e-0871acc560d1@github.com>

On Tue, 21 Sep 2021 13:49:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
>> 
>> - remove declaration without definition
>> - move inlined code into hpp file
>> - factor out some code
>> 
>> Testing: gha, local compilation, local gc/g1
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review, renaming

The old name, `enqueue_card_after_barrier_filters`, is still referenced in the comments.

(I also wonder if it makes sense to unify all callers of `enqueue_card_if_tracked` to use `write_ref_field_post` with template non-type arguments. Not in PR ofc.)

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

Marked as reviewed by ayang (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Sep 21 14:45:15 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 14:45:15 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v3]
In-Reply-To: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
Message-ID: <fWhxKuXXdHQ4LkyIX30jWLi1dIjCj-uwtirtRucv_DU=.d42ad0e3-00f2-4fe2-8e4a-bb668829e21b@github.com>

> Hi all,
> 
>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
> 
> - remove declaration without definition
> - move inlined code in the .hpp file into .inline.hpp file
> - factor out some code
> 
> Testing: gha, local compilation, local gc/g1
> 
> Thanks,
>   Thomas

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

  ayang review, fixed comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5607/files
  - new: https://git.openjdk.java.net/jdk/pull/5607/files/8cf9b6a9..769254c8

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

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

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


From kbarrett at openjdk.java.net  Tue Sep 21 15:25:38 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 21 Sep 2021 15:25:38 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v3]
In-Reply-To: <fWhxKuXXdHQ4LkyIX30jWLi1dIjCj-uwtirtRucv_DU=.d42ad0e3-00f2-4fe2-8e4a-bb668829e21b@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
 <fWhxKuXXdHQ4LkyIX30jWLi1dIjCj-uwtirtRucv_DU=.d42ad0e3-00f2-4fe2-8e4a-bb668829e21b@github.com>
Message-ID: <NZv9OA5QflxbmpwP_1HKEpYy23MkJszaxY2psm0h4g8=.6e990745-c8e7-4c64-8e33-23ad152f8e44@github.com>

On Tue, 21 Sep 2021 14:45:15 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
>> 
>> - remove declaration without definition
>> - move inlined code in the .hpp file into .inline.hpp file
>> - factor out some code
>> 
>> Testing: gha, local compilation, local gc/g1
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review, fixed comment

Does this change allow this inclusion of an .inline.hpp to be moved out of the .hpp?
33 #include "gc/g1/heapRegionRemSet.inline.hpp"

src/hotspot/share/gc/g1/g1ParScanThreadState.hpp line 132:

> 130: 
> 131:   // Apply the post barrier to the given reference field. Enqueues the card of p
> 132:   // if the barrier (same region, not from survivor) does not filter out not find

I don't understand this comment; seems like there's a grammar or wording problem.

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

Changes requested by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Sep 21 16:07:25 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 16:07:25 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v4]
In-Reply-To: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
Message-ID: <PMN5j0mITgKAaY08eAX8CN19ejhyW78vulE2lUkOLu0=.2374e3e5-768b-47e1-b804-4f3590c07a88@github.com>

> Hi all,
> 
>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
> 
> - remove declaration without definition
> - move inlined code in the .hpp file into .inline.hpp file
> - factor out some code
> 
> Testing: gha, local compilation, local gc/g1
> 
> Thanks,
>   Thomas

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

  kbarrett review; fix comment, includes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5607/files
  - new: https://git.openjdk.java.net/jdk/pull/5607/files/769254c8..5d3a28bd

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

  Stats: 31 lines in 4 files changed: 15 ins; 11 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5607.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5607/head:pull/5607

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


From tschatzl at openjdk.java.net  Tue Sep 21 16:14:30 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 21 Sep 2021 16:14:30 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v3]
In-Reply-To: <NZv9OA5QflxbmpwP_1HKEpYy23MkJszaxY2psm0h4g8=.6e990745-c8e7-4c64-8e33-23ad152f8e44@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
 <fWhxKuXXdHQ4LkyIX30jWLi1dIjCj-uwtirtRucv_DU=.d42ad0e3-00f2-4fe2-8e4a-bb668829e21b@github.com>
 <NZv9OA5QflxbmpwP_1HKEpYy23MkJszaxY2psm0h4g8=.6e990745-c8e7-4c64-8e33-23ad152f8e44@github.com>
Message-ID: <2HH-f5aZDvpWsCq7KMImJ4Wk-hKHGomuQ32k7-8tF5A=.cae3efe7-8c48-4607-828d-40fa2a6bf495@github.com>

On Tue, 21 Sep 2021 15:22:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Does this change allow this inclusion of an .inline.hpp to be moved out of the .hpp?
> 33 #include "gc/g1/heapRegionRemSet.inline.hpp"

In the latest change I also touched up includes in that file a bit. Nothing about heapRegionRemSet has been used in that file...

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

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


From kbarrett at openjdk.java.net  Tue Sep 21 22:10:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 21 Sep 2021 22:10:59 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v4]
In-Reply-To: <PMN5j0mITgKAaY08eAX8CN19ejhyW78vulE2lUkOLu0=.2374e3e5-768b-47e1-b804-4f3590c07a88@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
 <PMN5j0mITgKAaY08eAX8CN19ejhyW78vulE2lUkOLu0=.2374e3e5-768b-47e1-b804-4f3590c07a88@github.com>
Message-ID: <8CFqG24nvq8ft0Q-wXz8obe4MYUo19rG3mXeTzsO-dg=.5b9d0035-cdf2-4f6a-b01b-9088b9295a70@github.com>

On Tue, 21 Sep 2021 16:07:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
>> 
>> - remove declaration without definition
>> - move inlined code in the .hpp file into .inline.hpp file
>> - factor out some code
>> 
>> Testing: gha, local compilation, local gc/g1
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review; fix comment, includes

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Sep 21 22:17:54 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 21 Sep 2021 22:17:54 GMT
Subject: RFR: 8274054: Add custom enqueue calls during reference processing
In-Reply-To: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
References: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
Message-ID: <a3O2vIqbkBH8slq1DqdYOJgY7V5aR8uA8MFomNYpHEc=.63e3f2b7-e7b4-47d0-bb80-cba7665fac4d@github.com>

On Tue, 21 Sep 2021 10:33:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this split-out of JDK-8271880/PR#5037 that only adds the interface and the default implementation to add custom "enqueue" calls to the VM?
> 
> For G1, the default (wrong) queue call is still used, that will be added with the other modifications to g1 later.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Sep 21 22:27:03 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 21 Sep 2021 22:27:03 GMT
Subject: RFR: 8273590: Move helper classes in G1 post evacuation sub tasks
 to cpp files
In-Reply-To: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
References: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
Message-ID: <OswOWTCAURubNtvdiQX1aEjobgj6eOxtx967m55lwF4=.f8a43cff-f32d-421b-bf90-3ed45984c49c@github.com>

On Fri, 10 Sep 2021 10:52:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this straightforward refactoring, moving helper classes that are not required to .cpp files. The nice side effect of this is that it removes around 100 LOC. No changes to code, except for removal of one unused local variable in
> ```RemoveSelfForwardPtrsTask::~RemoveSelfForwardPtrsTask`.
> 
> Testing: compilation, gha, local jtreg/gc/g1
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep 22 08:07:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 08:07:04 GMT
Subject: RFR: 8273590: Move helper classes in G1 post evacuation sub tasks
 to cpp files
In-Reply-To: <OswOWTCAURubNtvdiQX1aEjobgj6eOxtx967m55lwF4=.f8a43cff-f32d-421b-bf90-3ed45984c49c@github.com>
References: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
 <OswOWTCAURubNtvdiQX1aEjobgj6eOxtx967m55lwF4=.f8a43cff-f32d-421b-bf90-3ed45984c49c@github.com>
Message-ID: <pYWjBY3FqKGD-bKe0FaVD-oJPoRLMOfKhKPl5MW6YgM=.a7a71bb5-1169-4fac-a07e-406fa21243fa@github.com>

On Tue, 21 Sep 2021 22:24:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this straightforward refactoring, moving helper classes that are not required to .cpp files. The nice side effect of this is that it removes around 100 LOC. No changes to code, except for removal of one unused local variable in
>> ```RemoveSelfForwardPtrsTask::~RemoveSelfForwardPtrsTask`.
>> 
>> Testing: compilation, gha, local jtreg/gc/g1
>> 
>> Thanks,
>>   Thomas
>
> Looks good.

Thanks @kimbarrett @kstefanj for your reviews

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 08:11:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 08:11:02 GMT
Subject: Integrated: 8273590: Move helper classes in G1 post evacuation sub
 tasks to cpp files
In-Reply-To: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
References: <36xZi9aTB1PDnfFxSRkRWXLxAyBXzEy0DcGSMo4sm8s=.08bb7b95-d761-48f7-88a4-a9c8eb14a50a@github.com>
Message-ID: <8DUmQ40gq561kPLe84UeO3conlHcPjL8eVjKLvX9yrQ=.7b3991ec-26fb-47fc-b91f-d64dac82864c@github.com>

On Fri, 10 Sep 2021 10:52:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this straightforward refactoring, moving helper classes that are not required to .cpp files. The nice side effect of this is that it removes around 100 LOC. No changes to code, except for removal of one unused local variable in
> ```RemoveSelfForwardPtrsTask::~RemoveSelfForwardPtrsTask`.
> 
> Testing: compilation, gha, local jtreg/gc/g1
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: d9872ba3
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d9872ba3d6c5afb2ae8e17c38e2222a2a1ab9493
Stats:     423 lines in 2 files changed: 108 ins; 190 del; 125 mod

8273590: Move helper classes in G1 post evacuation sub tasks to cpp files

Reviewed-by: sjohanss, kbarrett

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

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


From sjohanss at openjdk.java.net  Wed Sep 22 08:59:57 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 22 Sep 2021 08:59:57 GMT
Subject: RFR: 8274054: Add custom enqueue calls during reference processing
In-Reply-To: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
References: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
Message-ID: <SyZu4bMF1TCYh7N37JWMeevFa-D-thbQHM-oV3WObYw=.130d3632-831d-48ea-9cad-5f8888c06f5b@github.com>

On Tue, 21 Sep 2021 10:33:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this split-out of JDK-8271880/PR#5037 that only adds the interface and the default implementation to add custom "enqueue" calls to the VM?
> 
> For G1, the default (wrong) queue call is still used, that will be added with the other modifications to g1 later.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Sep 22 10:21:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 10:21:08 GMT
Subject: RFR: 8274054: Add custom enqueue calls during reference processing
In-Reply-To: <Cf5eRfGyq-cdqjFZgDhKYxvCZSrFVXXf02GGh_lFtuc=.6486cd50-569e-4321-8af5-9dcb18ef7d41@github.com>
References: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
 <Cf5eRfGyq-cdqjFZgDhKYxvCZSrFVXXf02GGh_lFtuc=.6486cd50-569e-4321-8af5-9dcb18ef7d41@github.com>
Message-ID: <xMMVlCqIevtKck3DIFbziyM2taCPBG5Qj_XrDsCp0Mw=.502d0bcd-233c-41f8-b57e-184279fc6360@github.com>

On Tue, 21 Sep 2021 11:00:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this split-out of JDK-8271880/PR#5037 that only adds the interface and the default implementation to add custom "enqueue" calls to the VM?
>> 
>> For G1, the default (wrong) queue call is still used, that will be added with the other modifications to g1 later.
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj @kimbarrett for your reviews

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 10:21:09 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 10:21:09 GMT
Subject: Integrated: 8274054: Add custom enqueue calls during reference
 processing
In-Reply-To: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
References: <nuljAuEXzQadevaOAAWpP8Fui-knA3wWs0_-2pnvr4U=.cd91c78a-d65e-4d07-8bfc-19968d0d4639@github.com>
Message-ID: <P7LvfBi-CXSavfw3-Psa5UHgi_pRSkszLzMgERCz__E=.1eb99978-0dcb-4c93-ba5f-3d66f9aee50d@github.com>

On Tue, 21 Sep 2021 10:33:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this split-out of JDK-8271880/PR#5037 that only adds the interface and the default implementation to add custom "enqueue" calls to the VM?
> 
> For G1, the default (wrong) queue call is still used, that will be added with the other modifications to g1 later.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 51085b52
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51085b523eb7f37c3af5b566b55eca37c127bdcf
Stats:     84 lines in 9 files changed: 53 ins; 3 del; 28 mod

8274054: Add custom enqueue calls during reference processing

Reviewed-by: ayang, kbarrett, sjohanss

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 11:42:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 11:42:57 GMT
Subject: RFR: 8274069: Clean up g1ParScanThreadState a bit [v2]
In-Reply-To: <7pqUX_UKLKYr2y2KdqC-E36eRADMM8i1qHIQ1kh6N7A=.2ea6fd84-5543-4dd1-ad5e-0871acc560d1@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
 <q7ppGRQJwqz2b0gVhzKSbbY0EqptEgVfl17kC0XpREg=.5ae1bf82-82f4-476e-bfb5-c6bc4f0b83ab@github.com>
 <7pqUX_UKLKYr2y2KdqC-E36eRADMM8i1qHIQ1kh6N7A=.2ea6fd84-5543-4dd1-ad5e-0871acc560d1@github.com>
Message-ID: <_gFtkfIzQH49NbskJN5URegmoZb7Q0kIQf5aaZz-gBk=.b5c19b76-c6c4-49ad-b964-0860df10ad24@github.com>

On Tue, 21 Sep 2021 14:23:16 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:
>> 
>>   ayang review, renaming
>
> The old name, `enqueue_card_after_barrier_filters`, is still referenced in the comments.
> 
> (I also wonder if it makes sense to unify all callers of `enqueue_card_if_tracked` to use `write_ref_field_post` with template non-type arguments. Not in *this* PR ofc.)

Thanks @albertnetymk @kstefanj @kimbarrett for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 11:45:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 11:45:04 GMT
Subject: RFR: 8274068: Rename G1ScanInYoungSetter to
 G1SkipCardEnqueueSetter
In-Reply-To: <0X3m-Iiqf9HD5N7c-Uaqb-3KS0KnV5w3l3lsbFXJYpY=.4e855705-30a2-4e6f-a904-3fa2bf28ceb6@github.com>
References: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
 <0X3m-Iiqf9HD5N7c-Uaqb-3KS0KnV5w3l3lsbFXJYpY=.4e855705-30a2-4e6f-a904-3fa2bf28ceb6@github.com>
Message-ID: <BvN53T9MlYcjRCMTM_3uj-6PZK6oQ6MieS2mb1QkC_w=.98752428-2169-4752-8e8d-460c80b5853e@github.com>

On Tue, 21 Sep 2021 12:20:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this renaming change? The reason for this renaming is that @ayang and me thought that it would be a more appropriate name during review of JDK-8271880 - causing the code to skip enqueuing cards.
>> 
>> Testing: gha, local compilation
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 11:45:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 11:45:06 GMT
Subject: Integrated: 8274068: Rename G1ScanInYoungSetter to
 G1SkipCardEnqueueSetter
In-Reply-To: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
References: <NKpkiVmfPDK-aVisOEkYPKhYJmdZw2hQrrqIGehvIXg=.a855ba0e-644a-48db-8872-8f81ce0d35fb@github.com>
Message-ID: <W_xe5YCEr3L7yB_C3F3Mvu38SG7dxbjohB29qzPp-YE=.bf8cf429-78c2-4f7e-a770-9d3540993427@github.com>

On Tue, 21 Sep 2021 11:26:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this renaming change? The reason for this renaming is that @ayang and me thought that it would be a more appropriate name during review of JDK-8271880 - causing the code to skip enqueuing cards.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 3f73ca7f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3f73ca7fcd674e10d4382ec4bd8d4cb0da1e4256
Stats:     17 lines in 3 files changed: 0 ins; 0 del; 17 mod

8274068: Rename G1ScanInYoungSetter to G1SkipCardEnqueueSetter

Reviewed-by: sjohanss, ayang

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 11:47:04 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 11:47:04 GMT
Subject: Integrated: 8274069: Clean up g1ParScanThreadState a bit
In-Reply-To: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
References: <boNH19Ngax_lumW99Fi4fqt4ne9gLcdTQo19GDS2XwY=.5cab01b7-c915-4e71-98e3-01b5a322e21d@github.com>
Message-ID: <MilsvrQx3gOjBJiuhVaorJ2c4tB_6AR5a72seE0COuo=.02b79beb-9376-4340-8420-4dd74a3eb5a8@github.com>

On Tue, 21 Sep 2021 11:39:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that does some minor refactoring for issues found in JDK-8271880/PR#5037:
> 
> - remove declaration without definition
> - move inlined code in the .hpp file into .inline.hpp file
> - factor out some code
> 
> Testing: gha, local compilation, local gc/g1
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: d245a8cc
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d245a8cc852de21547928252ed6f0474f0d49b1c
Stats:     97 lines in 5 files changed: 51 ins; 34 del; 12 mod

8274069: Clean up g1ParScanThreadState a bit

Reviewed-by: sjohanss, ayang, kbarrett

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 12:46:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 12:46:12 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v12]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <hDYB-_6NN3ueLLGn_c7zgixpdPQAnZSLuMPaDKS1Fe0=.0f43c900-85a6-4227-ad05-6062291dcbaa@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> 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 15 commits:

 - Remove unnecessary changes
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Fix compilation after merge
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - Add enqueue callback
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - ayang comments; note that the mentioned crash is still not fixed.
 - Merge master
 - Merge branch 'master' into evac-failure-no-scan-during-remove-self-forwards
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/aefd4ac4...cefe7fda

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

Changes: https://git.openjdk.java.net/jdk/pull/5037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=11
  Stats: 167 lines in 14 files changed: 73 ins; 74 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5037/head:pull/5037

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


From tschatzl at openjdk.java.net  Wed Sep 22 13:51:24 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 13:51:24 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v13]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <vIRnRixjDiv7olVQZpneTzqP6Yv6faeb550rdvQ3QAU=.948bf033-7c17-4e9b-8a20-e1fc5570564c@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> Thanks,
>   Thomas

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

  ayang review, consistency, comment fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5037/files
  - new: https://git.openjdk.java.net/jdk/pull/5037/files/cefe7fda..4570174a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=11-12

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 14:23:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 14:23:56 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v13]
In-Reply-To: <vIRnRixjDiv7olVQZpneTzqP6Yv6faeb550rdvQ3QAU=.948bf033-7c17-4e9b-8a20-e1fc5570564c@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <vIRnRixjDiv7olVQZpneTzqP6Yv6faeb550rdvQ3QAU=.948bf033-7c17-4e9b-8a20-e1fc5570564c@github.com>
Message-ID: <XqVdJYzprYExJzkuGSk9AKz146roACK-AqzJDV9SeXY=.9366be75-982d-4314-baa8-a35b31f9d348@github.com>

On Wed, 22 Sep 2021 13:51:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review, consistency, comment fix

Please hold off reviewing, it looks I messed something up in the merge.

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 15:14:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 15:14:08 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v14]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> Thanks,
>   Thomas

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

 - Fix merge error
 - ayang review, more comment notes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5037/files
  - new: https://git.openjdk.java.net/jdk/pull/5037/files/4570174a..d000beed

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=12-13

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

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


From ayang at openjdk.java.net  Wed Sep 22 15:21:17 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 22 Sep 2021 15:21:17 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v14]
In-Reply-To: <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
Message-ID: <76290oB92Kb323klzhL49WhOzxhZy4uxslnZDMMtb4I=.43f3d951-851b-42c5-aaec-361fc3bea1e7@github.com>

On Wed, 22 Sep 2021 15:14:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix merge error
>  - ayang review, more comment notes

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Sep 22 15:29:24 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 22 Sep 2021 15:29:24 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v3]
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <-Ry1BKD1_rg27R_Hkriv8sCk93a9PKClo4HlOVjWsaI=.7c081c9b-089a-4111-98ca-58bb9fccfc86@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> 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 8273492-move-evac-failure-handling-to-younggc
 - sjohanss review
 - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
 - Move evac failure handling to young gc

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

Changes: https://git.openjdk.java.net/jdk/pull/5419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5419&range=02
  Stats: 154 lines in 13 files changed: 58 ins; 40 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5419/head:pull/5419

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


From sjohanss at openjdk.java.net  Thu Sep 23 10:11:55 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 23 Sep 2021 10:11:55 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v14]
In-Reply-To: <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
Message-ID: <CPLgHhZa8zRWOyp_JXZQIUaaCPoQapaXybYRTAVXaOs=.d82f957e-7d37-4cf7-9e7f-d5638c0e7aac@github.com>

On Wed, 22 Sep 2021 15:14:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix merge error
>  - ayang review, more comment notes

Looks good. 

Still I think maybe we should just go with just calling it `Survivor` instead of `NewSurvivor`. I see how it could lead to some confusion, but the comments could be expanded a bit to explain that these are referring to the newly allocated survivors. 

But I'm good with the change as is, so if you prefer this, let's go with this.

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

> 268:   }
> 269: 
> 270:   // Skip the card enqueue iff the objective (to_array) is in survivor region.

Typo:
Suggestion:

  // Skip the card enqueue iff the object (to_array) is in survivor region.

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

> 518:     }
> 519: 
> 520:     // Skip the card enqueue iff the objective (obj) is in survivor region.

Same typo as above.

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

Marked as reviewed by sjohanss (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Sep 23 10:40:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 10:40:43 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v15]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <OrDiohOQE2kcvRy9zQ_eZ0BhDfkD9BmHNz0V65zjhsg=.4fd6d21d-179e-4ae9-b0f2-aee877d7f400@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> Thanks,
>   Thomas

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

 - Update src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
 - Update src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
   
   Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5037/files
  - new: https://git.openjdk.java.net/jdk/pull/5037/files/d000beed..6393624c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=13-14

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

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


From tschatzl at openjdk.java.net  Thu Sep 23 10:40:46 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 10:40:46 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v14]
In-Reply-To: <CPLgHhZa8zRWOyp_JXZQIUaaCPoQapaXybYRTAVXaOs=.d82f957e-7d37-4cf7-9e7f-d5638c0e7aac@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
 <CPLgHhZa8zRWOyp_JXZQIUaaCPoQapaXybYRTAVXaOs=.d82f957e-7d37-4cf7-9e7f-d5638c0e7aac@github.com>
Message-ID: <Z1Clh-PoedH-l3mDqkMpb5XLeZRn7WBrKpna_LMu8oU=.22c6f784-4809-4cf8-a5d4-578c1768cf8b@github.com>

On Thu, 23 Sep 2021 09:52:14 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix merge error
>>  - ayang review, more comment notes
>
> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 520:
> 
>> 518:     }
>> 519: 
>> 520:     // Skip the card enqueue iff the objective (obj) is in survivor region.
> 
> Same typo as above.

Suggestion:

    // Skip the card enqueue iff the object (obj) is in survivor region.

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

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


From tschatzl at openjdk.java.net  Thu Sep 23 11:10:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 11:10:51 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v15]
In-Reply-To: <OrDiohOQE2kcvRy9zQ_eZ0BhDfkD9BmHNz0V65zjhsg=.4fd6d21d-179e-4ae9-b0f2-aee877d7f400@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <OrDiohOQE2kcvRy9zQ_eZ0BhDfkD9BmHNz0V65zjhsg=.4fd6d21d-179e-4ae9-b0f2-aee877d7f400@github.com>
Message-ID: <TGYM9k3RQu68nxedkAKUqvZ_2yCT0i2PNoqqRZqSWh0=.2aa20eb8-8091-4bf5-bed3-58e8b1191fc4@github.com>

On Thu, 23 Sep 2021 10:40:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
>> 
>> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
>> 
>> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
>> 
>> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
>> 
>> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
>> 
>> 
>>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
>> 
>> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
>> 
>> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
>> 
>> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
>  - Update src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
>    
>    Co-authored-by: Stefan Johansson <54407259+kstefanj at users.noreply.github.com>

Not sure about `NewSurvivor` and `Survivor` as well. Unless somebody has a strong opinion about either I will push this as is later - you are right that I have been worried about confusion. The enum value can be renamed later too.

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

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


From tschatzl at openjdk.java.net  Thu Sep 23 11:10:54 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 11:10:54 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v11]
In-Reply-To: <ZGuHYAtGXW_nXSrhqXjETRkOmwrEDeNaddY7h2FVijo=.fce378dc-731f-4704-a00c-8e2e320c4ad9@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <OPpv8oOJYPK-otBYKkrIJar5O04Bi5jTUe2dys4tjb8=.786841b6-4f39-47e6-8fc8-86095757b622@github.com>
 <ZGuHYAtGXW_nXSrhqXjETRkOmwrEDeNaddY7h2FVijo=.fce378dc-731f-4704-a00c-8e2e320c4ad9@github.com>
Message-ID: <XQXruUmdkZSupQA0nxpX34smUqGwBTMQNfn7D0C99VM=.af724cd0-c48e-40e5-8764-90bc44768dff@github.com>

On Mon, 20 Sep 2021 12:12:36 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.
>
> src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp line 116:
> 
>> 114:   if (!dest_attr.is_in_cset()) {
>> 115:     enqueue_card_if_tracked(dest_attr, p, obj);
>> 116:   }
> 
> If I understand this correctly, the only time `dest_attr.is_in_cset() == true` is when `obj` is in a region that failed evacuation, right? To make this even more obvious could we add an else-statement with an assert that this is the case?

This is unfortunately not possible due to races (I tried :)) - one thread may set the flag, another one in the meanwhile already fail again an object in the region, and the evacuation-failed flag not yet visible to this thread.

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

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


From tschatzl at openjdk.java.net  Thu Sep 23 13:33:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 13:33:12 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
Message-ID: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>

Hi all,

  can I have reviews for this change that improves evacuation failure injector performance to be usable for pinned region performance work?

The suspected reason I think why performance is so bad (image in the CR), is that the unsynchronized reads and writes to `G1YoungGCEvacFailureInjector::_evacuation_failure_object_count` cause massive performance issue if done millions of times.

This change makes that counter thread-local, fixing that issue completely.

I initially had a prototype using a `THREAD_LOCAL`, but when testing I had the feeling that this is/was slightly slower and I thought that adding a variable to every thread where most do not use them seems to be a waste.

Testing: local testing, GHA

Thanks,
  Thomas

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

Commit messages:
 - Fixes
 - Make injector counter local

Changes: https://git.openjdk.java.net/jdk/pull/5650/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5650&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274191
  Stats: 34 lines in 5 files changed: 17 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5650.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5650/head:pull/5650

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


From tschatzl at openjdk.java.net  Thu Sep 23 14:08:54 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 14:08:54 GMT
Subject: RFR: 8273626: G1: refactor G1CardSetAllocator to support element
 size less pointer size
In-Reply-To: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
Message-ID: <OKBj2tCruD3iObD3X4nnDm-UYme1boQosMkF4iV7lks=.011aa2ca-c25d-49bf-b615-30ed9b23484a@github.com>

On Sat, 11 Sep 2021 05:05:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.
> 
> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

Sorry for the late reply. Coincidentally around release there's also some housekeeping to do.

My main question about this change is: Would it be possible to give a sneak-peek on the use of `G1SegmentedArray` in the [JDK-8254739](https://bugs.openjdk.java.net/browse/JDK-8254739) code? It is impossible to determine if the change fits the intended purpose, and I want to avoid changing `G1SegmentedArray` again later.

What *I* thought was that every region gets a set of elements using `G1SegmentedArray` attached to it, in whatever form. Multiple threads add to that at the same time.

This means that multiple threads might add new segments to it at the same time, meaning that they may try to append new segments to it. What happens with the thread and the segment that fails? Shouldn't this allocation be reused somehow (maybe for other segmented arrays?).

Also, this seems to drop the concurrent freeing of these segments after GC, which is nice too.

The remembered set uses the memory provided by the segmented arrays in chunks too, i.e. the `G1CardSetArray` container. Not sure if something like this would be more appropriate here instead of directly using the chunks (but may well be as good).

What are your plans about all this?

Depending on your design choices (which I do not know) this change may be reasonable or not. Please detail this a bit.

Also note that the CR title currently is a bit misleading imho, indicating a small change supporting smaller pointer sizes. I would prefer if it would be named something like "Factor out concurrent segmented array from G1CardSetAllocator".

src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 27:

> 25: 
> 26: #ifndef LINUX_X86_64_SERVER_SLOWDEBUG_G1SEGMENTEDARRAY_HPP
> 27: #define LINUX_X86_64_SERVER_SLOWDEBUG_G1SEGMENTEDARRAY_HPP

This should be something like `SHARE_GC_G1_G1SEGMENTEDARRAY_HPP`

src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 36:

> 34: // SegmentedArrayBuffers can be linked together using a singly linked list.
> 35: template<MEMFLAGS flag>
> 36: class SegmentedArrayBuffer : public CHeapObj<flag> {

Should be `G1SegmentedArrayBuffer`.

src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 85:

> 83: 
> 84:   char* start() const { return _buffer; }
> 85: 

Unused, can be removed.

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

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


From dcubed at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on
 linux-all and windows-all
Message-ID: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>

A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

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

Commit messages:
 - 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

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

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


From darcy at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
Message-ID: <NPvLGaVLiBPGMa9eLq0IQYHzyirhm6oBy8hoiECY-mY=.9e110985-22ac-4506-8273-49ef2a1d7922@github.com>

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

Marked as reviewed by darcy (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
Message-ID: <98hC7JdW0nSdZJrViN7XTJxJc4bpSuLtBpUPC0I1UHk=.3ba05130-cf03-47b7-a5ec-9d5be694181c@github.com>

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

Marked as reviewed by tschatzl (Reviewer).

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

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


From dcubed at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <NPvLGaVLiBPGMa9eLq0IQYHzyirhm6oBy8hoiECY-mY=.9e110985-22ac-4506-8273-49ef2a1d7922@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
 <NPvLGaVLiBPGMa9eLq0IQYHzyirhm6oBy8hoiECY-mY=.9e110985-22ac-4506-8273-49ef2a1d7922@github.com>
Message-ID: <wWv7tCV02wTFvyUe36a6JFKOO-Ad66ww3w_CPprkr0M=.cb77810c-c805-4464-84c7-0606b6b23a3a@github.com>

On Thu, 23 Sep 2021 16:58:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review!

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

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


From dcubed at openjdk.java.net  Thu Sep 23 17:09:11 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:09:11 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <98hC7JdW0nSdZJrViN7XTJxJc4bpSuLtBpUPC0I1UHk=.3ba05130-cf03-47b7-a5ec-9d5be694181c@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
 <98hC7JdW0nSdZJrViN7XTJxJc4bpSuLtBpUPC0I1UHk=.3ba05130-cf03-47b7-a5ec-9d5be694181c@github.com>
Message-ID: <kfJ6gGASBULC1BZFDLRGCRMae7rpggRzvuL-3CPhJXU=.5d227710-b114-455a-9647-a03174d9da9c@github.com>

On Thu, 23 Sep 2021 17:01:14 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.
>
> Marked as reviewed by tschatzl (Reviewer).

@tschatzl - Thanks for the fast review!

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

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


From dcubed at openjdk.java.net  Thu Sep 23 17:17:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:17:53 GMT
Subject: Integrated: 8274216: ProblemList 2 serviceability/dcmd/gc tests with
 ZGC on linux-all and windows-all
In-Reply-To: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
Message-ID: <VYBSJJRcUGLR2y_d1DRiXloLApq8yW4gzBRjwf-unEM=.6d263267-8eb3-4517-82a3-56c756b1ec51@github.com>

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

This pull request has now been integrated.

Changeset: 0aa63fec
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0aa63feca8704c8958530ef9e3df128570c50e12
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

Reviewed-by: darcy, tschatzl

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

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


From kbarrett at openjdk.java.net  Thu Sep 23 21:33:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 23 Sep 2021 21:33:59 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
In-Reply-To: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
Message-ID: <-_A1D5jiE0WwJe23-tcIOqhGMNygwzzB3_fkJY0oqqw=.3cda896b-7b34-4b33-a2a7-5070143f6eac@github.com>

On Thu, 23 Sep 2021 12:13:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that improves evacuation failure injector performance to be usable for pinned region performance work?
> 
> The suspected reason I think why performance is so bad (image in the CR), is that the unsynchronized reads and writes to `G1YoungGCEvacFailureInjector::_evacuation_failure_object_count` cause massive performance issue if done millions of times.
> 
> This change makes that counter thread-local, fixing that issue completely.
> 
> I initially had a prototype using a `THREAD_LOCAL`, but when testing I had the feeling that this is/was slightly slower and I thought that adding a variable to every thread where most do not use them seems to be a waste.
> 
> Testing: local testing, GHA
> 
> Thanks,
>   Thomas

Good find.  Looks good.  Just a couple nits.

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

> 88: #ifndef PRODUCT
> 89:     _evac_failure_inject_counter(0),
> 90: #endif

This might be less cluttering as `NOT_PRODUCT(_evac_failure_inject_counter(0) COMMA)`.  Your call...

src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.inline.hpp line 40:

> 38:   }
> 39:   // Injecting evacuation failures is in effect for current GC
> 40:   // Access to _evacuation_failure_alot_count is not atomic;

Comment about non-atomicity seems like it should not be needed anymore.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Fri Sep 24 03:39:55 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 24 Sep 2021 03:39:55 GMT
Subject: RFR: 8273626: G1: Factor out concurrent segmented array from
 G1CardSetAllocator
In-Reply-To: <OKBj2tCruD3iObD3X4nnDm-UYme1boQosMkF4iV7lks=.011aa2ca-c25d-49bf-b615-30ed9b23484a@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
 <OKBj2tCruD3iObD3X4nnDm-UYme1boQosMkF4iV7lks=.011aa2ca-c25d-49bf-b615-30ed9b23484a@github.com>
Message-ID: <PhduXeaq3gDHsFDOsmErWrKDwCtK88plF3QC6FOnWzE=.b1276d69-6984-4bcb-a198-e2e096dd4389@github.com>

On Thu, 23 Sep 2021 14:05:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Sorry for the late reply. Coincidentally around release there's also some housekeeping to do.
> 

Thanks Thomas, it's OK, this is not that urgent.

> My main question about this change is: Would it be possible to give a sneak-peek on the use of `G1SegmentedArray` in the [JDK-8254739](https://bugs.openjdk.java.net/browse/JDK-8254739) code? It is impossible to determine if the change fits the intended purpose, and I want to avoid changing `G1SegmentedArray` again later.
> 

Sure, I've put the merged code in a temporary branch, https://github.com/Hamlin-Li/jdk/tree/tmp-merge.segmented-array.speed-remove-self. "speed-remove-self" part is still the old one, I did not change it yet, including the suggestions you gave in #5181 and old home made segmented array implementation; I just use the new G1SegmentedArray in G1EvacuationFailureObjsInHR.

> What _I_ thought was that every region gets a set of elements using `G1SegmentedArray` attached to it, in whatever form. Multiple threads add to that at the same time.
> 

Yes, it's implemented in this way, although later in #5181 we may refactor how G1SegmentedArray is attached to a region, but G1SegmentedArray itself should be fine at that time.

> This means that multiple threads might add new segments to it at the same time, meaning that they may try to append new segments to it. What happens with the thread and the segment that fails? Shouldn't this allocation be reused somehow (maybe for other segmented arrays?).
> 

Current(original) implementation just drop the newly allocated G1SegmentedArrayBuffer if current thread fails, seems it's fine as the race should be rare, should we add the faield one to free list? seems adding to freelist will bring some benefit.

> Also, this seems to drop the concurrent freeing of these segments after GC, which is nice too.
> 
> The remembered set uses the memory provided by the segmented arrays in chunks too, i.e. the `G1CardSetArray` container. Not sure if something like this would be more appropriate here instead of directly using the chunks (but may well be as good).
> 

Not quite sure, seems both have benefit, in `G1CardSetArray` way, it has better design benefit; in G1SegmentedArray::iterate_nodes/G1EvacuationFailureObjsInHR::visit, it might have better performance. I'm OK with both ways, please kindly let me know your decision.

> What are your plans about all this?
> 
> Depending on your design choices (which I do not know) this change may be reasonable or not. Please detail this a bit.
> 
> Also note that the CR title currently is a bit misleading imho, indicating a small change supporting smaller pointer sizes. I would prefer if it would be named something like "Factor out concurrent segmented array from G1CardSetAllocator".

Modified.

> src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 85:
> 
>> 83: 
>> 84:   char* start() const { return _buffer; }
>> 85: 
> 
> Unused, can be removed.

This is used in G1EvacuationFailureObjsInHR::visit, so it depends on the discussion below.

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

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


From github.com+25214855+casparcwang at openjdk.java.net  Fri Sep 24 03:50:09 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Fri, 24 Sep 2021 03:50:09 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages in bulk
Message-ID: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>

Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.

The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.

patch:
[2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
[2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
[2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms


origin:
[2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
[2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
[2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

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

Commit messages:
 - Bulk free in relocate

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

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


From mli at openjdk.java.net  Fri Sep 24 03:52:41 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 24 Sep 2021 03:52:41 GMT
Subject: RFR: 8273626: G1: Factor out concurrent segmented array from
 G1CardSetAllocator [v2]
In-Reply-To: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
Message-ID: <Qkrl6PXIIrFqbbCPI_ubz3Ame3HEN-xhRYqSfpuJSBk=.dad0518f-7abc-4646-82da-7c7e5e88b276@github.com>

> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.
> 
> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

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

  Rename Xxx to G1Xxx

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5478/files
  - new: https://git.openjdk.java.net/jdk/pull/5478/files/5769a8be..8e5f5943

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

  Stats: 71 lines in 4 files changed: 5 ins; 0 del; 66 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5478.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5478/head:pull/5478

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


From github.com+1866174+tbzhang at openjdk.java.net  Fri Sep 24 06:47:18 2021
From: github.com+1866174+tbzhang at openjdk.java.net (Tongbao Zhang)
Date: Fri, 24 Sep 2021 06:47:18 GMT
Subject: RFR: JDK-8274259: G1: assert(check_alignment(result)) failed: address
 not aligned: 0x00000008baadbabe after JDK-8270009
Message-ID: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>

After JDK-8270009, the VerifyBeforeGC missed retired tlabs before verify remset

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

Commit messages:
 - whitespace error
 - JDK-8274259: G1: assert(check_alignment(result)) failed: address not aligned: 0x00000008baadbabe after JDK-8270009

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 07:46:30 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 07:46:30 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
 [v2]
In-Reply-To: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
Message-ID: <2tfPjmNMtWalkvd0-SQN4cXa4oiPnOcm52DK-LNGk_s=.2fda39b5-fb3d-4e3a-b0f9-ff4506792adb@github.com>

> Hi all,
> 
>   can I have reviews for this change that improves evacuation failure injector performance to be usable for pinned region performance work?
> 
> The suspected reason I think why performance is so bad (image in the CR), is that the unsynchronized reads and writes to `G1YoungGCEvacFailureInjector::_evacuation_failure_object_count` cause massive performance issue if done millions of times.
> 
> This change makes that counter thread-local, fixing that issue completely.
> 
> I initially had a prototype using a `THREAD_LOCAL`, but when testing I had the feeling that this is/was slightly slower and I thought that adding a variable to every thread where most do not use them seems to be a waste.
> 
> Testing: local testing, GHA
> 
> Thanks,
>   Thomas

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

  kbarrett review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5650/files
  - new: https://git.openjdk.java.net/jdk/pull/5650/files/f2f9c651..7925c987

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

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 07:46:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 07:46:33 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
 [v2]
In-Reply-To: <-_A1D5jiE0WwJe23-tcIOqhGMNygwzzB3_fkJY0oqqw=.3cda896b-7b34-4b33-a2a7-5070143f6eac@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
 <-_A1D5jiE0WwJe23-tcIOqhGMNygwzzB3_fkJY0oqqw=.3cda896b-7b34-4b33-a2a7-5070143f6eac@github.com>
Message-ID: <rTFKnoUMusVk5lZJsOUwC3nRMPHcOIn08e8WYVCMG18=.e0ffb812-7e17-45e7-ab15-3e8a762ef676@github.com>

On Thu, 23 Sep 2021 21:27:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett review
>
> src/hotspot/share/gc/g1/g1YoungGCEvacFailureInjector.inline.hpp line 40:
> 
>> 38:   }
>> 39:   // Injecting evacuation failures is in effect for current GC
>> 40:   // Access to _evacuation_failure_alot_count is not atomic;
> 
> Comment about non-atomicity seems like it should not be needed anymore.

I removed the entire paragraph. There is nothing interesting to tell any more after this change.

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 07:53:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 07:53:51 GMT
Subject: RFR: JDK-8274259: G1: assert(check_alignment(result)) failed:
 address not aligned: 0x00000008baadbabe after JDK-8270009
In-Reply-To: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
References: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
Message-ID: <ASKPtQsF3J--WN4EE6oD6gZuWY37QanXM_EGyq3fqPY=.384b0b6b-bd86-4720-8f63-81ecaababa12@github.com>

On Fri, 24 Sep 2021 06:37:00 GMT, Tongbao Zhang <github.com+1866174+tbzhang at openjdk.org> wrote:

> After JDK-8270009, the VerifyBeforeGC missed retired tlabs before verify remset

Lgtm. Thanks.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Sep 24 08:01:54 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 08:01:54 GMT
Subject: RFR: JDK-8274259: G1: assert(check_alignment(result)) failed:
 address not aligned: 0x00000008baadbabe after JDK-8270009
In-Reply-To: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
References: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
Message-ID: <VUcJFGtYDn_UkrkhCbseJGRtIMWyXNbuOhy2TOmB_wU=.01905d1f-d6b4-4e3f-9c58-004d1a0c1aed@github.com>

On Fri, 24 Sep 2021 06:37:00 GMT, Tongbao Zhang <github.com+1866174+tbzhang at openjdk.org> wrote:

> After JDK-8270009, the VerifyBeforeGC missed retired tlabs before verify remset

Fwiw, for other reviewers, (I think) the cause is the move of the `ensure_parsability` call from `gc_prologue` into `pre_evacuate_collection_set` that always occurs *after* verification.

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

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


From mli at openjdk.java.net  Fri Sep 24 08:37:30 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 24 Sep 2021 08:37:30 GMT
Subject: RFR: 8273626: G1: Factor out concurrent segmented array from
 G1CardSetAllocator [v3]
In-Reply-To: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
References: <t43LVSkM99RdWrVVIUOsdj-x1ii91YFTkkAszYpmp0c=.c06c07bf-90cc-4371-9710-a4a1b137ba02@github.com>
Message-ID: <pco9xfLaMKfiPfi12Oq5bZ5Yfk6XAvYvIeTIQBqtWTw=.5c1afc22-0c23-4819-b7e1-be60b994a7c0@github.com>

> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement.
> 
> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray).

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

 - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator
 - Rename Xxx to G1Xxx
 - Clean code
 - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums
 - Initial commit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5478/files
  - new: https://git.openjdk.java.net/jdk/pull/5478/files/8e5f5943..0088b53f

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

  Stats: 42032 lines in 1393 files changed: 28400 ins; 6968 del; 6664 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5478.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5478/head:pull/5478

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


From tschatzl at openjdk.java.net  Fri Sep 24 09:34:17 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 09:34:17 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
 [v3]
In-Reply-To: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
Message-ID: <EmEZGFUN9LX_gA0yScR71DYfcBBr_Q0JmG5ZtRre7gc=.f2cfbe51-d29f-4afd-973e-aa0b17fe7ed4@github.com>

> Hi all,
> 
>   can I have reviews for this change that improves evacuation failure injector performance to be usable for pinned region performance work?
> 
> The suspected reason I think why performance is so bad (image in the CR), is that the unsynchronized reads and writes to `G1YoungGCEvacFailureInjector::_evacuation_failure_object_count` cause massive performance issue if done millions of times.
> 
> This change makes that counter thread-local, fixing that issue completely.
> 
> I initially had a prototype using a `THREAD_LOCAL`, but when testing I had the feeling that this is/was slightly slower and I thought that adding a variable to every thread where most do not use them seems to be a waste.
> 
> Testing: local testing, GHA
> 
> Thanks,
>   Thomas

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

  ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5650/files
  - new: https://git.openjdk.java.net/jdk/pull/5650/files/7925c987..0d380f7b

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

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

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


From ayang at openjdk.java.net  Fri Sep 24 09:34:18 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 24 Sep 2021 09:34:18 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
 [v3]
In-Reply-To: <EmEZGFUN9LX_gA0yScR71DYfcBBr_Q0JmG5ZtRre7gc=.f2cfbe51-d29f-4afd-973e-aa0b17fe7ed4@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
 <EmEZGFUN9LX_gA0yScR71DYfcBBr_Q0JmG5ZtRre7gc=.f2cfbe51-d29f-4afd-973e-aa0b17fe7ed4@github.com>
Message-ID: <v-PzVe1vhNFibfD9vmnBWBsYWkNUqllH7FrpPkEKd1Q=.98f3414d-3b0d-431e-8fd1-3e3fe7ef8aba@github.com>

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

>> Hi all,
>> 
>>   can I have reviews for this change that improves evacuation failure injector performance to be usable for pinned region performance work?
>> 
>> The suspected reason I think why performance is so bad (image in the CR), is that the unsynchronized reads and writes to `G1YoungGCEvacFailureInjector::_evacuation_failure_object_count` cause massive performance issue if done millions of times.
>> 
>> This change makes that counter thread-local, fixing that issue completely.
>> 
>> I initially had a prototype using a `THREAD_LOCAL`, but when testing I had the feeling that this is/was slightly slower and I thought that adding a variable to every thread where most do not use them seems to be a waste.
>> 
>> Testing: local testing, GHA
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 11:37:23 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 11:37:23 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v16]
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <N1KxuI3zTbpZkkkvW1wtt0QdWfsihjJAvuf3JK7eetQ=.f8a191a7-6673-439f-8310-9c2c75080e1e@github.com>

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> Thanks,
>   Thomas

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

  sjohanss review, additional verification

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5037/files
  - new: https://git.openjdk.java.net/jdk/pull/5037/files/6393624c..1da340cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5037&range=14-15

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 11:37:26 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 11:37:26 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v14]
In-Reply-To: <76290oB92Kb323klzhL49WhOzxhZy4uxslnZDMMtb4I=.43f3d951-851b-42c5-aaec-361fc3bea1e7@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
 <76290oB92Kb323klzhL49WhOzxhZy4uxslnZDMMtb4I=.43f3d951-851b-42c5-aaec-361fc3bea1e7@github.com>
Message-ID: <reiWNUp2ONj-l6olDM5V7V4SZ8rB6nWMaEKrKMvveKs=.bf0cfdb4-5175-4c95-b76c-f0df543db522@github.com>

On Wed, 22 Sep 2021 15:17:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix merge error
>>  - ayang review, more comment notes
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk made me aware that we can check whether the `is_in_cset()` is only true for evac-failed regions by using the fact that for those `obj` their forwardee is equal. Tier1-5 almost passed with this change now. Will integrate later unless something comes up.

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

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


From ayang at openjdk.java.net  Fri Sep 24 12:06:59 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 24 Sep 2021 12:06:59 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v3]
In-Reply-To: <-Ry1BKD1_rg27R_Hkriv8sCk93a9PKClo4HlOVjWsaI=.7c081c9b-089a-4111-98ca-58bb9fccfc86@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
 <-Ry1BKD1_rg27R_Hkriv8sCk93a9PKClo4HlOVjWsaI=.7c081c9b-089a-4111-98ca-58bb9fccfc86@github.com>
Message-ID: <fXaLA3TXP1Tj1DpLwtNg5x1xE1a8lM2lEnGaHG_jqzk=.3c5cfe13-3232-4270-a8b0-fabe33e4382c@github.com>

On Wed, 22 Sep 2021 15:29:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
>> 
>> Testing: tier1-3
>> 
>> 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 8273492-move-evac-failure-handling-to-younggc
>  - sjohanss review
>  - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
>  - Move evac failure handling to young gc

I think the original placement about the design, update stats iff `evac_fail == false`, is better; this is sth internal to `G1Policy`, not a caller's decision. IOW, sth like:


G1Policy::record_young_collection_end(bool concurrent_operation_is_full_mark, bool evac_fail) {
  // Evacuation failures skew the timing too much ...
  update_stats = !evac_fail;
}


The same apply to `G1Policy::record_pause`.

Not strictly part of this PR:

`num_regions_failed_evacuation` is just a getter, right? Why the name difference btw the method and the field?

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 12:09:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 12:09:59 GMT
Subject: RFR: 8274191: Improve g1 evacuation failure injector performance
 [v3]
In-Reply-To: <v-PzVe1vhNFibfD9vmnBWBsYWkNUqllH7FrpPkEKd1Q=.98f3414d-3b0d-431e-8fd1-3e3fe7ef8aba@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
 <EmEZGFUN9LX_gA0yScR71DYfcBBr_Q0JmG5ZtRre7gc=.f2cfbe51-d29f-4afd-973e-aa0b17fe7ed4@github.com>
 <v-PzVe1vhNFibfD9vmnBWBsYWkNUqllH7FrpPkEKd1Q=.98f3414d-3b0d-431e-8fd1-3e3fe7ef8aba@github.com>
Message-ID: <kdL9aRL-6Z4qjC5KL532AXJDnBXwUDoi8AzmZmp_qLc=.d64327ff-a855-4837-88d2-7fb5085848e6@github.com>

On Fri, 24 Sep 2021 09:28:58 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:
>> 
>>   ayang review
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kimbarrett for your reviews

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 12:10:00 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 12:10:00 GMT
Subject: Integrated: 8274191: Improve g1 evacuation failure injector
 performance
In-Reply-To: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
References: <9EI8BuF47crDaWNJB71LCLtqalTcrLe88ysFAYSu-3U=.98acc3e4-1f84-40c9-a8ae-7c5921901e7b@github.com>
Message-ID: <Rc9b7oaQTNxRrrimfRVUbdLwWtB8d-tNJu5GnfZ1dCQ=.c40ff25e-219f-4daf-ad3e-b9045da65268@github.com>

On Thu, 23 Sep 2021 12:13:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that improves evacuation failure injector performance to be usable for pinned region performance work?
> 
> The suspected reason I think why performance is so bad (image in the CR), is that the unsynchronized reads and writes to `G1YoungGCEvacFailureInjector::_evacuation_failure_object_count` cause massive performance issue if done millions of times.
> 
> This change makes that counter thread-local, fixing that issue completely.
> 
> I initially had a prototype using a `THREAD_LOCAL`, but when testing I had the feeling that this is/was slightly slower and I thought that adding a variable to every thread where most do not use them seems to be a waste.
> 
> Testing: local testing, GHA
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: db23ecdf
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/db23ecdfae44a5387c2407e9e0f300f08770e7c0
Stats:     36 lines in 6 files changed: 15 ins; 11 del; 10 mod

8274191: Improve g1 evacuation failure injector performance

Reviewed-by: kbarrett, ayang

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 12:11:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 12:11:59 GMT
Subject: RFR: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references [v14]
In-Reply-To: <76290oB92Kb323klzhL49WhOzxhZy4uxslnZDMMtb4I=.43f3d951-851b-42c5-aaec-361fc3bea1e7@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
 <5-D6FKvlGqwca0jVnbMoVHDChqDc85UIojQmgtcU99g=.fa1fda70-35b7-454d-ae9a-7b831e3865bd@github.com>
 <76290oB92Kb323klzhL49WhOzxhZy4uxslnZDMMtb4I=.43f3d951-851b-42c5-aaec-361fc3bea1e7@github.com>
Message-ID: <Umrl_CVj1DfqXI7ZHCPekx5fl0ktJsCAnqS-UVYyoL8=.f4f9f9fa-46c5-4489-9255-7d73cae4c213@github.com>

On Wed, 22 Sep 2021 15:17:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix merge error
>>  - ayang review, more comment notes
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kstefanj for your reviews

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 12:12:00 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 12:12:00 GMT
Subject: Integrated: 8271880: Tighten condition for excluding regions from
 collecting cards with cross-references
In-Reply-To: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
References: <JQcgC7XRWNI44-ZIs75gifEJ4zOJnnd_8lm2YmR5vt4=.0b4679bc-6379-45e8-89dc-b3e66771a579@github.com>
Message-ID: <F8045549WeM35vUQOXYVcZ3xaXntIqnlpXNlhGUJ2j0=.5b6cd0a8-ffe0-4890-a6cb-55bde5acd714@github.com>

On Fri, 6 Aug 2021 21:05:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   can I have reviews for this change that by tightening the condition for excluding regions from collecting cards with cross-references allows us to avoid the rescanning of objects that failed evacuation in the fix up self-forwards phase after evacuation failure.
> 
> I.e. during gc g1 never collects cards/references from the young gen (including eden) for later refinement - which means that we need to rescan all live objects remaining in eden regions for cross-references.
> 
> The problem or the reason why we did that was that we did not want to add cards to refine from survivor regions (i.e. next gc's young gen) because we just don't need to as we always collect young gen, so references from there need not be recorded in the remembered sets (and actually, if we did, we errorneouosly marked cards in young gen which later card table verification will not like) - but we did not have that information on hand anywhere already quickly accessible.
> 
> This change solves that problem by actually recording this information in the region attribute table as "NewSurvivor" type region. "NewSurvivor" because I did want to make explicit that these are the survivor regions from the *new* (next) young generation (i.e. just survivor) and not the survivor regions of the previous gc (that were turned eden at the start of this gc) but something like "NewYoung" or so would be fine with me as well (or certainly just "Survivor", but that might be confusing).
> 
> Another interesting addition is probably the new assert in `G1ParThreadScanState::enqueue_card_if_tracked`
> 
> 
>      assert(!_g1h->heap_region_containing(o)->in_collection_set(), "Should not try to enqueue reference into collection set region");
> 
> This, at this time, verifies the assumption that g1 is not trying to collect references *to* the collection set, i.e. other objects that failed evacuation - after all we later relabel their regions as old *without* a remembered set; we would do otherwise unnecessarily because the reason is that (currently) cset tracking for these regions is enabled (at least during gc - we only later relabel and drop the remembered sets).
> 
> This might change later if we want to move evacuation failed regions into survivor (or keep their remembered sets for some reason), but for now we filter attempts to add cards in the dcqs for those this way.
> 
> Testing: tier1-5, gc/g1 with `JAVA_OPTIONS_=-XX+G1EvacuationFailureALot -XX:+VerifyAfterGC`.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 5a12af76
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5a12af762df0c45edea94fb433bbe0eb54e6505f
Stats:     171 lines in 14 files changed: 76 ins; 74 del; 21 mod

8271880: Tighten condition for excluding regions from collecting cards with cross-references

Reviewed-by: ayang, sjohanss

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

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


From github.com+1866174+tbzhang at openjdk.java.net  Fri Sep 24 12:28:55 2021
From: github.com+1866174+tbzhang at openjdk.java.net (Tongbao Zhang)
Date: Fri, 24 Sep 2021 12:28:55 GMT
Subject: RFR: JDK-8274259: G1: assert(check_alignment(result)) failed:
 address not aligned: 0x00000008baadbabe after JDK-8270009
In-Reply-To: <ASKPtQsF3J--WN4EE6oD6gZuWY37QanXM_EGyq3fqPY=.384b0b6b-bd86-4720-8f63-81ecaababa12@github.com>
References: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
 <ASKPtQsF3J--WN4EE6oD6gZuWY37QanXM_EGyq3fqPY=.384b0b6b-bd86-4720-8f63-81ecaababa12@github.com>
Message-ID: <On9UkSDmh_SHpZL9GRWVG4BXbeU8dPGaeFyubeHNL0I=.d4e65e58-3ce3-4a41-be74-8bde4b895fb7@github.com>

On Fri, 24 Sep 2021 07:50:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Lgtm. Thanks.

Thanks for your review!

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 12:47:25 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 12:47:25 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v4]
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <YXIw0XsPtpOpTYCGZa7deI2hOgU7Be8_qGY4ZFyA0xo=.b7485635-8755-4f50-b1b3-b4d61ec68dee@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

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

  ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5419/files
  - new: https://git.openjdk.java.net/jdk/pull/5419/files/d94e38b0..466f4998

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

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 12:55:26 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 12:55:26 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v5]
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <NOgoBVD1VaYHjWhjKjQDsIc5l6700OP_UE2L_vwl8xA=.4829ad3f-bb56-43c5-a8b9-3c74442d984e@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

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

  ayang review (2)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5419/files
  - new: https://git.openjdk.java.net/jdk/pull/5419/files/466f4998..3c27f705

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

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 13:08:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 13:08:12 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v6]
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <uSaF2AVr94SWl0hk3Lb-9uTyWyEFh79ZNgAEgyUKKQA=.4a73cf20-3248-4e04-8f58-519bb6b25aa6@github.com>

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

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

 - Fix comment
 - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
 - ayang review (2)
 - ayang review
 - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
 - sjohanss review
 - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
 - Move evac failure handling to young gc

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

Changes: https://git.openjdk.java.net/jdk/pull/5419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5419&range=05
  Stats: 153 lines in 13 files changed: 58 ins; 40 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5419/head:pull/5419

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


From ayang at openjdk.java.net  Fri Sep 24 13:08:13 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 24 Sep 2021 13:08:13 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v6]
In-Reply-To: <uSaF2AVr94SWl0hk3Lb-9uTyWyEFh79ZNgAEgyUKKQA=.4a73cf20-3248-4e04-8f58-519bb6b25aa6@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
 <uSaF2AVr94SWl0hk3Lb-9uTyWyEFh79ZNgAEgyUKKQA=.4a73cf20-3248-4e04-8f58-519bb6b25aa6@github.com>
Message-ID: <_4CHqtYXeVNLewKNcGxk1h3ic7j5_k2oHMhOOJS2O4I=.6737fa8d-189f-44f8-a460-dc699b03cb6c@github.com>

On Fri, 24 Sep 2021 13:05:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Fix comment
>  - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
>  - ayang review (2)
>  - ayang review
>  - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
>  - sjohanss review
>  - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
>  - Move evac failure handling to young gc

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 13:08:14 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 13:08:14 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v5]
In-Reply-To: <NOgoBVD1VaYHjWhjKjQDsIc5l6700OP_UE2L_vwl8xA=.4829ad3f-bb56-43c5-a8b9-3c74442d984e@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
 <NOgoBVD1VaYHjWhjKjQDsIc5l6700OP_UE2L_vwl8xA=.4829ad3f-bb56-43c5-a8b9-3c74442d984e@github.com>
Message-ID: <ikWfIPa7fOySXSG7riMOeEyQRBZsekfO2LIJjPvrDW4=.3abfafcc-864e-49d7-9bc8-f8dd485d8ee2@github.com>

On Fri, 24 Sep 2021 12:55:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review (2)

> I think the original placement about the design, update stats iff `evac_fail == false`, is better; this is sth internal to `G1Policy`, not a caller's decision. IOW, sth like:
> 
> ```c++
> G1Policy::record_young_collection_end(bool concurrent_operation_is_full_mark, bool evac_fail) {
>   // Evacuation failures skew the timing too much ...
>   update_stats = !evac_fail;
> }
> ```
> 
> The same apply to `G1Policy::record_pause`.

I agree with `record_young_collection_end`, but I am not that confident about `record_pause`. The latter is an internal API and directly controlled by the respective `record_xxx_end` methods only. However this is not a strong opinion so I changed it as well.

> 
> Not strictly part of this PR:
> 
> `num_regions_failed_evacuation` is just a getter, right? Why the name difference btw the method and the field?

I think this is coming from the collection set where the same naming (`_cur_length`) has been introduced to indicate the current length of the array used to gather elements. Should maybe be both renamed.

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

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


From ayang at openjdk.java.net  Fri Sep 24 13:50:09 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 24 Sep 2021 13:50:09 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in referenceProcessor
Message-ID: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>

Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure.

Test: hotspot_gc

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

Commit messages:
 - referent

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 19:32:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 19:32:56 GMT
Subject: RFR: 8273492: Move evacuation failure handling into
 G1YoungCollector [v2]
In-Reply-To: <wN3hq9hpQZUT_iScE9nJfqh8AeFESkOqVSkaFvFh5AU=.f0d3ec27-b15d-4b6b-9475-ef4be0cb5dcc@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
 <SHcIXu2ehGyUbP8KR47QFKQmj1_6j38V0xt9zc3dhmY=.5589077f-4be1-4205-ab47-6baa7b3f9b16@github.com>
 <wN3hq9hpQZUT_iScE9nJfqh8AeFESkOqVSkaFvFh5AU=.f0d3ec27-b15d-4b6b-9475-ef4be0cb5dcc@github.com>
Message-ID: <c7tjEmfJ6CzAKGA0L-cNP0gftqNin6lB5WHEoQJAN-0=.4aca46c0-d48d-43c0-bc2a-0b34c80b9f40@github.com>

On Mon, 20 Sep 2021 12:25:51 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 pull request now contains three commits:
>> 
>>  - sjohanss review
>>  - Merge branch 'master' into 8273492-move-evac-failure-handling-to-younggc
>>  - Move evac failure handling to young gc
>
> Marked as reviewed by sjohanss (Reviewer).

Thanks @kstefanj @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Fri Sep 24 19:32:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 24 Sep 2021 19:32:57 GMT
Subject: Integrated: 8273492: Move evacuation failure handling into
 G1YoungCollector
In-Reply-To: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
References: <69_4FKx29iwAEjslIpT-_2l9QB-FdDSJSmsbt6T6HJs=.54f55620-a1aa-4910-8f47-a23756451859@github.com>
Message-ID: <L8N-cAs52O9Vz3_AgrEf4EJJFMEryKLZSk6pnXIZR0c=.1101af19-0792-4306-98bf-56515392228b@github.com>

On Wed, 8 Sep 2021 15:09:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that moves young gc evacuation failure handling (`G1EvacFailureRegions`) from `G1CollectedHeap` to `G1YoungCollector`.
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 341de49f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/341de49f8f7a89b87804f681fb60c09f7d3240ab
Stats:     153 lines in 13 files changed: 58 ins; 40 del; 55 mod

8273492: Move evacuation failure handling into G1YoungCollector

Reviewed-by: sjohanss, ayang

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

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


From kbarrett at openjdk.java.net  Sat Sep 25 19:32:02 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 25 Sep 2021 19:32:02 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor
In-Reply-To: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
Message-ID: <M4ApLMXyycYiOguyKT4ernw9U8-uJQtcvIL_JLNuXfg=.25ec68d0-6f44-4b15-9659-209316051868@github.com>

On Fri, 24 Sep 2021 13:42:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure.
> 
> Test: hotspot_gc

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/referenceProcessor.cpp line 267:

> 265: 
> 266: void DiscoveredListIterator::make_referent_alive() {
> 267:   assert(referent() != nullptr, "precondition");

This assert is not correct.  Preclean runs concurrently with the mutator.  The mutator could clear the reference between the time it is accessed by the list iterator and the call to make_referent_alive.  Looking at this also makes me wonder if the keep-alive function is safe against a racing clear by the mutator.

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

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


From kbarrett at openjdk.java.net  Sat Sep 25 20:49:56 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 25 Sep 2021 20:49:56 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor
In-Reply-To: <M4ApLMXyycYiOguyKT4ernw9U8-uJQtcvIL_JLNuXfg=.25ec68d0-6f44-4b15-9659-209316051868@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
 <M4ApLMXyycYiOguyKT4ernw9U8-uJQtcvIL_JLNuXfg=.25ec68d0-6f44-4b15-9659-209316051868@github.com>
Message-ID: <qMO1m1NE6-P3OroKL5mN4oC23K2S6tYAyam40LTp3Ys=.acdc1801-b78e-4183-8f73-62f2e20495df@github.com>

On Sat, 25 Sep 2021 19:28:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure.
>> 
>> Test: hotspot_gc
>
> src/hotspot/share/gc/shared/referenceProcessor.cpp line 267:
> 
>> 265: 
>> 266: void DiscoveredListIterator::make_referent_alive() {
>> 267:   assert(referent() != nullptr, "precondition");
> 
> This assert is not correct.  Preclean runs concurrently with the mutator.  The mutator could clear the reference between the time it is accessed by the list iterator and the call to make_referent_alive.  Looking at this also makes me wonder if the keep-alive function is safe against a racing clear by the mutator.

Answering my own question. Only G1 currently uses precleaning, and it looks fine wrto a concurrent clear. Indeed, I think it's an expensive nop. I suspect (though haven't thought about it carefully yet) that any GC that uses ReferenceProcessor would do nothing there, and I'm not sure preclean actually needs the keep-alive and complete-gc closures.

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

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


From sjohanss at openjdk.java.net  Mon Sep 27 08:45:56 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 27 Sep 2021 08:45:56 GMT
Subject: RFR: JDK-8274259: G1: assert(check_alignment(result)) failed:
 address not aligned: 0x00000008baadbabe after JDK-8270009
In-Reply-To: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
References: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
Message-ID: <VzAIq_PyRphzuuNyTaARGu6GgP_hUVOp0RUWBI-WrPE=.c16d1778-ce4b-47a6-9d36-f10e584e591c@github.com>

On Fri, 24 Sep 2021 06:37:00 GMT, Tongbao Zhang <github.com+1866174+tbzhang at openjdk.org> wrote:

> After JDK-8270009, the VerifyBeforeGC missed retired tlabs before verify remset

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From github.com+1866174+tbzhang at openjdk.java.net  Mon Sep 27 12:19:01 2021
From: github.com+1866174+tbzhang at openjdk.java.net (Tongbao Zhang)
Date: Mon, 27 Sep 2021 12:19:01 GMT
Subject: RFR: JDK-8274259: G1: assert(check_alignment(result)) failed:
 address not aligned: 0x00000008baadbabe after JDK-8270009
In-Reply-To: <VzAIq_PyRphzuuNyTaARGu6GgP_hUVOp0RUWBI-WrPE=.c16d1778-ce4b-47a6-9d36-f10e584e591c@github.com>
References: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
 <VzAIq_PyRphzuuNyTaARGu6GgP_hUVOp0RUWBI-WrPE=.c16d1778-ce4b-47a6-9d36-f10e584e591c@github.com>
Message-ID: <r3NhdsmCk_vOWLTfBPqFfcovkXYnuHLbg3Ld3jei-QU=.60720071-ceb5-48e6-b144-c2658bc39523@github.com>

On Mon, 27 Sep 2021 08:43:04 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Looks good.

Thanks for your review!

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

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


From kbarrett at openjdk.java.net  Tue Sep 28 05:35:02 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 28 Sep 2021 05:35:02 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor
In-Reply-To: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
Message-ID: <JN3amfMmC97wruzg82eFTu6kMq-FSbJ_MOQsPJBEqTY=.aea8b46f-5d66-4978-8582-0b858a5529e0@github.com>

On Fri, 24 Sep 2021 13:42:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure.
> 
> Test: hotspot_gc

Changes requested by kbarrett (Reviewer).

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

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


From kbarrett at openjdk.java.net  Tue Sep 28 05:35:03 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 28 Sep 2021 05:35:03 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor
In-Reply-To: <qMO1m1NE6-P3OroKL5mN4oC23K2S6tYAyam40LTp3Ys=.acdc1801-b78e-4183-8f73-62f2e20495df@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
 <M4ApLMXyycYiOguyKT4ernw9U8-uJQtcvIL_JLNuXfg=.25ec68d0-6f44-4b15-9659-209316051868@github.com>
 <qMO1m1NE6-P3OroKL5mN4oC23K2S6tYAyam40LTp3Ys=.acdc1801-b78e-4183-8f73-62f2e20495df@github.com>
Message-ID: <JvBUl2oBeDNQxpmVWJogWXdkbMz2cKqIRS3FuLIjfQE=.a9befeae-6e1a-4aea-b3b0-989601da4915@github.com>

On Sat, 25 Sep 2021 20:46:31 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/referenceProcessor.cpp line 267:
>> 
>>> 265: 
>>> 266: void DiscoveredListIterator::make_referent_alive() {
>>> 267:   assert(referent() != nullptr, "precondition");
>> 
>> This assert is not correct.  Preclean runs concurrently with the mutator.  The mutator could clear the reference between the time it is accessed by the list iterator and the call to make_referent_alive.  Looking at this also makes me wonder if the keep-alive function is safe against a racing clear by the mutator.
>
> Answering my own question. Only G1 currently uses precleaning, and it looks fine wrto a concurrent clear. Indeed, I think it's an expensive nop. I suspect (though haven't thought about it carefully yet) that any GC that uses ReferenceProcessor would do nothing there, and I'm not sure preclean actually needs the keep-alive and complete-gc closures.

@albertnetymk  pointed out that I was confused about what referent access we're dealing with in the assert.  That's the referent that was previously loaded and cached in the iterator.  But that just makes the assert confusing in my opinion.  There is nothing about make_referent_alive that depends on that precondition, and indeed the keep-alive function must *not* depend on it.  So I still think the assert should not be added.

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

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


From mdoerr at openjdk.java.net  Tue Sep 28 08:36:15 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 28 Sep 2021 08:36:15 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest
Message-ID: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>

We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet a 2nd chance.

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

Commit messages:
 - Retry up to 4 times.
 - Fix comments.
 - 8271855: [testbug] Wrong weakCompareAndSet assumption in UnsafeIntrinsicsTest

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

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


From tschatzl at openjdk.java.net  Tue Sep 28 09:35:08 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 28 Sep 2021 09:35:08 GMT
Subject: RFR: 8274430: Remove some debug error printing code added in
 JDK-8017163
Message-ID: <Sxbxv1V_5hPz2vErtFoxnW-JL4R19-fp5OBduxHR7Q8=.10bad668-e217-43fe-bb60-ee720ee85072@github.com>

Hi all,

  can I have reviews for this change that undoes some logging changes from JDK-8017163, in particular it added the `XXX card set` lines in the output as shown in an example below:

``` [171.616s][1632757560415ms][error][gc,verify ] GC(129) Missing rem set entry:
[171.616s][1632757560415ms][error][gc,verify ] GC(129) Field 0x00000007fb1008f0 of obj 0x00000007fb1008d8 in region 1485:(O)[0x00000007fb000000,0x00000
[171.616s][1632757560415ms][error][gc,verify ] GC(129) NULL card setjava.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry
[...]
points to obj 0x00000004d9abd4c8 in region 683:(S)[0x00000004d9000000,0x00000004da000000,0x00000004da000000] remset Complete


This string would indicate which card set container does not have the requested remembered set entry. This is unnecessary information, as the "points to obj" string later shows that there should be a remset to this region already, and otherwise only interesting for debugging.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - initial version

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

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


From tschatzl at openjdk.java.net  Tue Sep 28 09:44:40 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 28 Sep 2021 09:44:40 GMT
Subject: RFR: 8274340: [BACKOUT] JDK-8271880: Tighten condition for excluding
 regions from collecting cards with cross-references
Message-ID: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>

Hi all,

  please review this backout of JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references because it causes failures with Kitchensink runs.

As the CR indicates, with proper verification these runs fail fairly quickly after 5-20mins with a remembered set verification failure on the discovered field of some j.l.ref.References instances; without that patch multiple instances are already running for an hour without issue (out of 8h). This is enough evidence for me that the change is responsible, backing it out to keep the CI clean(er) as I do not really have an idea why at this time (another merge issue after splitting up the original change?).

Revert applied cleanly except for the hunk in G1PostEvacuateCollectionSetCleanupTask1::G1PostEvacuateCollectionSetCleanupTask1 line 138: an earlier cleanup moved evacuation failure handling to `G1YoungCollector`, causing some merge problems.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - Revert "8271880: Tighten condition for excluding regions from collecting cards with cross-references"

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

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


From github.com+1866174+tbzhang at openjdk.java.net  Tue Sep 28 12:36:02 2021
From: github.com+1866174+tbzhang at openjdk.java.net (Tongbao Zhang)
Date: Tue, 28 Sep 2021 12:36:02 GMT
Subject: Integrated: JDK-8274259: G1: assert(check_alignment(result)) failed:
 address not aligned: 0x00000008baadbabe after JDK-8270009
In-Reply-To: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
References: <OwPPmUGKbL6wEEBv8FOUU1hnv28vZ0y2skyTYVmPiSA=.d3eb5ab9-57af-4fa6-8f3b-575ccfe169f6@github.com>
Message-ID: <BFpQ4XVFxCRiwUpz1kIrF1tAMm7LG9FmoLAgJFA9gCc=.8a7ae5c6-7050-4309-b1c1-bd5fdc062433@github.com>

On Fri, 24 Sep 2021 06:37:00 GMT, Tongbao Zhang <github.com+1866174+tbzhang at openjdk.org> wrote:

> After JDK-8270009, the VerifyBeforeGC missed retired tlabs before verify remset

This pull request has now been integrated.

Changeset: 79865cd7
Author:    Tongbao Zhang <tobytbzhang at tencent.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79865cd797737f22cd4efe7e9c03ddbb86095e64
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8274259: G1: assert(check_alignment(result)) failed: address not aligned: 0x00000008baadbabe after JDK-8270009

Reviewed-by: tschatzl, sjohanss

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

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


From goetz at openjdk.java.net  Tue Sep 28 12:42:57 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Tue, 28 Sep 2021 12:42:57 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest
In-Reply-To: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
Message-ID: <VkKoVSdxmVknlvJkM76y4V7TdNj7yKvCrMnZjrxK83M=.d8165684-a52f-447f-8c7d-d6634025ffbe@github.com>

On Wed, 4 Aug 2021 12:38:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.

Hi Martin, 
why do you think 4 iterations are what you need?
I think you should add 8271855 to @bug.
Best regards,
  Goetz

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

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


From pliden at openjdk.java.net  Tue Sep 28 13:10:57 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 28 Sep 2021 13:10:57 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages
In-Reply-To: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
Message-ID: <o_lM8G_wVGixfnmcWdNY1C7kx86IZHpxVcFTFZLRnvQ=.232bbc5e-e792-4bdf-8eee-771ce7d27b41@github.com>

On Fri, 24 Sep 2021 03:41:27 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
> 
> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
> 
> patch:
> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
> 
> 
> origin:
> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

1)  Instead of checking for the allocator type in the general code, this whole thing could be moved into the ZRelocateSmallAllocator, like this: https://github.com/openjdk/jdk/compare/master...pliden:8274249_zgc_bulk_free_empty_pages

2) How did you arrive at the bulk limit of 32? Did you try other numbers and this worked the best?

3) Freeing in bulk feels like a reasonable thing to do, and I'm sure it will cause less contention on the page cache lock. So this will probably help in the normal case. However, in the case were memory is low, GC workers are now hogging free memory could cause allocation stalls to be longer than needed and cause in-place relocation to happen more often than needed. This hogging also gets worse the more GC workers we have. So, I'm a bit hesitant to bring this in without some more thought. For example, instead of having a fixed bulk free limit (like 32) we might instead want to look at other ways of limiting the amount of times `free_page()` is called. I suspect the main problem with calling `free_page()` comes in the beginning of the relocation phase, where we might be relocating a lot very sparse pages. I.e. the time between calls to `free_page()` becomes very short. Later in the relocation phase, as pages get less and less sparse and we spend more and more time copying objects, the
  calls to `free_page()` becomes less frequent. So, perhaps we could instead track number of relocated bytes, and call `free_pages()` once we pass some limit (say 2M). They we get a fairly uniform time between the calls to `free_page()` and avoid hogging memory for too long. This is just a thought, there might be other/better strategies they would work too. One would have to implement and benchmark to figure out which works best.

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

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


From mdoerr at openjdk.java.net  Tue Sep 28 13:52:18 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 28 Sep 2021 13:52:18 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest [v2]
In-Reply-To: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
Message-ID: <3urstqnna3U2oucxz0zM0Ru-cAgaP7UFHFCOIA86PIk=.2b012f80-6457-4df6-8967-17201d9b157a@github.com>

> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Retrying 4 times is probably an overkill.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4992/files
  - new: https://git.openjdk.java.net/jdk/pull/4992/files/f39bb85a..f0a13417

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

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

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


From mdoerr at openjdk.java.net  Tue Sep 28 13:52:20 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 28 Sep 2021 13:52:20 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest
In-Reply-To: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
Message-ID: <qJXVMtxgX2AYB_8Yb6ZMKmK2fbC9O0XCgV6gzfKjkM0=.851179fa-c9f9-49c8-9a21-362b1f766bf9@github.com>

On Wed, 4 Aug 2021 12:38:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.

The test should usually pass within 2 iterations. It could happen that 2 different reasons make it fail (e.g. GC touches the cache line, OS takes the process from the CPU, interrupt occurs, ...). So, I think 2 iterations should usually work, 3 ones should be enough to prevent very sporadic failures in the future.

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

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


From mdoerr at openjdk.java.net  Tue Sep 28 13:58:28 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Tue, 28 Sep 2021 13:58:28 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest [v3]
In-Reply-To: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
Message-ID: <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>

> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add bug id to test.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4992/files
  - new: https://git.openjdk.java.net/jdk/pull/4992/files/f0a13417..df3a553d

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

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

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


From goetz at openjdk.java.net  Tue Sep 28 14:03:32 2021
From: goetz at openjdk.java.net (Goetz Lindenmaier)
Date: Tue, 28 Sep 2021 14:03:32 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest [v3]
In-Reply-To: <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
 <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>
Message-ID: <IMSlT1AKtQ9fjzjz_ByUhz2WHqnW-Uyl-0nA0EZaYIE=.f9bcc5e5-6388-4c2c-92fa-aed7624f680c@github.com>

On Tue, 28 Sep 2021 13:58:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id to test.

LGTM

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

Marked as reviewed by goetz (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Sep 28 21:00:45 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 28 Sep 2021 21:00:45 GMT
Subject: RFR: 8274340: [BACKOUT] JDK-8271880: Tighten condition for
 excluding regions from collecting cards with cross-references
In-Reply-To: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
References: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
Message-ID: <ffPsJsc-Dvj3dy_re7yPBr9XHIPUuTuX0ro7D__6g4Q=.a1a97c89-36f8-4506-bbac-f4e98bd40fc0@github.com>

On Tue, 28 Sep 2021 09:14:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this backout of JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references because it causes failures with Kitchensink runs.
> 
> As the CR indicates, with proper verification these runs fail fairly quickly after 5-20mins with a remembered set verification failure on the discovered field of some j.l.ref.References instances; without that patch multiple instances are already running for an hour without issue (out of 8h). This is enough evidence for me that the change is responsible, backing it out to keep the CI clean(er) as I do not really have an idea why at this time (another merge issue after splitting up the original change?).
> 
> Revert applied cleanly except for the hunk in G1PostEvacuateCollectionSetCleanupTask1::G1PostEvacuateCollectionSetCleanupTask1 line 138: an earlier cleanup moved evacuation failure handling to `G1YoungCollector`, causing some merge problems.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Wed Sep 29 01:08:38 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 29 Sep 2021 01:08:38 GMT
Subject: Withdrawn: 8254739: G1: Optimize evacuation failure for regions with
 few failed objects
In-Reply-To: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
Message-ID: <ePieM_eCmRWOBvSeaE8ukLKvBKJYvLU5u1hhh1BN_0A=.48a20bba-bea4-4767-a982-cedfcbca1ef5@github.com>

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

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

This pull request has been closed without being integrated.

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

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


From mli at openjdk.java.net  Wed Sep 29 01:20:49 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 29 Sep 2021 01:20:49 GMT
Subject: RFR: 8274466 G1: simplify G1 collector states
Message-ID: <X05x-dn4PlNXl2jZx4mVPxrpZB8wYX7iBbHpmIuVsJc=.995ccd4b-85a2-48d1-a52d-1633d7984ce9@github.com>

This is a minor improvement which remove the redundant G1 Collector states usages.

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

Commit messages:
 - Initial commit

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

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


From thartmann at openjdk.java.net  Wed Sep 29 06:38:36 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 29 Sep 2021 06:38:36 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest [v3]
In-Reply-To: <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
 <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>
Message-ID: <eUBu5MP8E-3xAlqPGzr7xiYsvnFj3WOa9ixc0Dc8aQQ=.f03ed29b-096d-4cd4-bec9-0a4369d80f37@github.com>

On Tue, 28 Sep 2021 13:58:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id to test.

Looks good to me.

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

Marked as reviewed by thartmann (Reviewer).

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


From github.com+25214855+casparcwang at openjdk.java.net  Wed Sep 29 07:55:42 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Wed, 29 Sep 2021 07:55:42 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v2]
In-Reply-To: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
Message-ID: <I2ULQoiXKwXs2w2r4T8k7kN-jdNjqOJvkyGoCjEDdQI=.88e5962d-e8b4-41d2-a871-3ff00acebeef@github.com>

> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
> 
> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
> 
> patch:
> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
> 
> 
> origin:
> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

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

  Exit bulk free if in place relocation happens

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5670/files
  - new: https://git.openjdk.java.net/jdk/pull/5670/files/1b16e9dd..639ca2fe

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

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

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


From github.com+25214855+casparcwang at openjdk.java.net  Wed Sep 29 08:10:29 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Wed, 29 Sep 2021 08:10:29 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v2]
In-Reply-To: <I2ULQoiXKwXs2w2r4T8k7kN-jdNjqOJvkyGoCjEDdQI=.88e5962d-e8b4-41d2-a871-3ff00acebeef@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
 <I2ULQoiXKwXs2w2r4T8k7kN-jdNjqOJvkyGoCjEDdQI=.88e5962d-e8b4-41d2-a871-3ff00acebeef@github.com>
Message-ID: <qPFN9y06j1r_FLendlNg-CdB6zHf6UU_mOFvz27CTpE=.d812a7e2-85c9-48fd-b4b5-38bb79fcfd1c@github.com>

On Wed, 29 Sep 2021 07:55:42 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

>> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
>> 
>> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
>> 
>> patch:
>> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
>> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
>> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
>> 
>> 
>> origin:
>> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
>> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
>> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms
>
> ?? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exit bulk free if in place relocation happens

Thank your for your review and suggestions.

> * Instead of checking for the allocator type in the general code, this whole thing could be moved into the ZRelocateSmallAllocator, like this: [master...pliden:8274249_zgc_bulk_free_empty_pages](https://github.com/openjdk/jdk/compare/master...pliden:8274249_zgc_bulk_free_empty_pages)

`ZRelocateSmallAllocator` is a shared object between different relocation tasks, if the logic is moved to `ZRelocateSmallAllocator`, it will need lock-free structures to hold bulk free pages. So I think keep it in the thread local closure make things simpler.

> * How did you arrive at the bulk limit of 32? Did you try other numbers and this worked the best?

64 produces better result than 32 in my testing, but 128 produce the same result as 64. I choose 32 because the worry about in-place relocation in low memory corner cases.

> * Freeing in bulk feels like a reasonable thing to do, and I'm sure it will cause less contention on the page cache lock. So this will probably help in the normal case. However, in the case were memory is low, GC workers are now hogging free memory could cause allocation stalls to be longer than needed and cause in-place relocation to happen more often than needed. This hogging also gets worse the more GC workers we have. So, I'm a bit hesitant to bring this in without some more thought. For example, instead of having a fixed bulk free limit (like 32) we might instead want to look at other ways of limiting the amount of times `free_page()` is called.

Buffering the relocated pages in a local private structure will cause in-place relocation and allocation stall happen more if the memory is low.  So I add a check to exit bulk free mode if in-place relocation happens.

>  I suspect the main problem with calling `free_page()` comes in the beginning of the relocation phase, where we might be relocating a lot very sparse pages. I.e. the time between calls to `free_page()` becomes very short. Later in the relocation phase, as pages get less and less sparse and we spend more and more time copying objects, the calls to `free_page()` becomes less frequent. So, perhaps we could instead track number of relocated bytes, and call `free_pages()` once we pass some limit (say 2M). They we get a fairly uniform time between the calls to `free_page()` and avoid hogging memory for too long. This is just a thought, there might be other/better strategies they would work too. One would have to implement and benchmark to figure out which works best.

Use relocated bytes to control the frequency of bulk free, that's a good idea, I will test it.

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

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


From github.com+25214855+casparcwang at openjdk.java.net  Wed Sep 29 08:54:02 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Wed, 29 Sep 2021 08:54:02 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v3]
In-Reply-To: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
Message-ID: <sLf3gWKPD3OUClbbX1emJ0l8RjZGLKJZTuo-ZxJSYPU=.d569075c-5b9a-4fa9-8352-b170ef489d4f@github.com>

> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage.
> 
> The following is the result of specjbb2015 after applying the patch (the tests turn off  the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%.
> 
> patch:
> [2021-09-18T13:11:51.736+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       373.180 / 569.855     275.312 / 569.855     275.312 / 569.855     ms
> [2021-09-18T15:30:07.168+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       381.266 / 577.812     277.272 / 577.812     277.272 / 577.812     ms
> [2021-09-18T17:37:56.305+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       345.037 / 494.135     259.497 / 506.815     259.497 / 506.815     ms
> 
> 
> origin:
> [2021-09-18T01:01:32.897+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       429.099 / 662.120     327.213 / 759.723     327.213 / 759.723     ms
> [2021-09-18T03:11:10.433+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       413.014 / 613.035     307.625 / 613.035     307.625 / 613.035     ms
> [2021-09-18T05:21:12.743+0800][info][gc,stats    ]       Phase: Concurrent Relocate                           0.000 / 0.000       411.745 / 642.242     308.986 / 642.242     308.986 / 642.242     ms

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

  Change to version provided by per lidan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5670/files
  - new: https://git.openjdk.java.net/jdk/pull/5670/files/639ca2fe..cf18a1f1

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

  Stats: 84 lines in 1 file changed: 25 ins; 53 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5670.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5670/head:pull/5670

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


From github.com+25214855+casparcwang at openjdk.java.net  Wed Sep 29 08:56:31 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Wed, 29 Sep 2021 08:56:31 GMT
Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v2]
In-Reply-To: <qPFN9y06j1r_FLendlNg-CdB6zHf6UU_mOFvz27CTpE=.d812a7e2-85c9-48fd-b4b5-38bb79fcfd1c@github.com>
References: <VfNYe9CARA4RQSsW00pWsRhWBlMJFAGEuUXwfY88Xc0=.b2d88d21-c590-413a-82ec-6754e996d55a@github.com>
 <I2ULQoiXKwXs2w2r4T8k7kN-jdNjqOJvkyGoCjEDdQI=.88e5962d-e8b4-41d2-a871-3ff00acebeef@github.com>
 <qPFN9y06j1r_FLendlNg-CdB6zHf6UU_mOFvz27CTpE=.d812a7e2-85c9-48fd-b4b5-38bb79fcfd1c@github.com>
Message-ID: <plEcg0Ny9Ra7wWQpdpp2IMVshnk604pA5N8AscZKtXk=.44fab9c9-203b-4c6d-9e32-ffecd8415b69@github.com>

On Wed, 29 Sep 2021 08:06:23 GMT, ?? <github.com+25214855+casparcwang at openjdk.org> wrote:

> * Instead of checking for the allocator type in the general code, this whole thing could be moved into the ZRelocateSmallAllocator, like this: [master...pliden:8274249_zgc_bulk_free_empty_pages](https://github.com/openjdk/jdk/compare/master...pliden:8274249_zgc_bulk_free_empty_pages)

Move into `ZRelocateSmallAllocator` make code cleaner and easier to understand. It's a more elegant. So I changed to your provided version, and use `ZPerWorker ` to avoid the contention between the gc workers.

>  However, in the case were memory is low, GC workers are now hogging free memory could cause allocation stalls to be longer than needed and cause in-place relocation to happen more often than needed. 

If in-place relocation has happened, the pages are always freed directly.

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

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


From mdoerr at openjdk.java.net  Wed Sep 29 09:58:45 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 29 Sep 2021 09:58:45 GMT
Subject: RFR: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest [v3]
In-Reply-To: <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
 <kIKIiMr3zl90_nxOomFqY6oD8qzCt_0n2C4PkkEP1Bw=.40234b84-c76a-4948-8195-9d747cffb53b@github.com>
Message-ID: <sfEdzhRgrYg4C1kEDfc7AfbGu8hwyqFGZSyRQLCEarQ=.6bfdd51f-3421-425d-93a9-45cc33bda060@github.com>

On Tue, 28 Sep 2021 13:58:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add bug id to test.

Thanks for the reviews!

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

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


From mdoerr at openjdk.java.net  Wed Sep 29 09:58:45 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 29 Sep 2021 09:58:45 GMT
Subject: Integrated: 8271855: [TESTBUG] Wrong weakCompareAndSet assumption in
 UnsafeIntrinsicsTest
In-Reply-To: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
References: <XVEkrSJn97GCwB8iZo7Yqe3eKqN-byi0MBd3_eyH9PI=.b9073cd9-e7be-4406-aa7a-6ea2d18db7af@github.com>
Message-ID: <xnDQ-Kyd-8hY7JseEV5PQfAxhwuaPyp4OtOaL_9UM1U=.e31e36af-8b96-480b-8a08-e01fbfaee928@github.com>

On Wed, 4 Aug 2021 12:38:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need a fix for test failures due to wrong assumption. (See JBS issue for details.) I suggest to give weakCompareAndSet several chances.

This pull request has now been integrated.

Changeset: c4d11570
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4d115701d102c33af937ca25dda8ac50117ac6b
Stats:     15 lines in 1 file changed: 6 ins; 0 del; 9 mod

8271855: [TESTBUG] Wrong weakCompareAndSet assumption in UnsafeIntrinsicsTest

Reviewed-by: goetz, thartmann

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

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


From ayang at openjdk.java.net  Wed Sep 29 12:08:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 29 Sep 2021 12:08:35 GMT
Subject: RFR: 8274340: [BACKOUT] JDK-8271880: Tighten condition for
 excluding regions from collecting cards with cross-references
In-Reply-To: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
References: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
Message-ID: <CDCpuRiireua-NmHDFniBVwczOoEQamwmAR4KVFjDdc=.7e5c13c5-b855-427d-8d4e-2500c88824a2@github.com>

On Tue, 28 Sep 2021 09:14:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this backout of JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references because it causes failures with Kitchensink runs.
> 
> As the CR indicates, with proper verification these runs fail fairly quickly after 5-20mins with a remembered set verification failure on the discovered field of some j.l.ref.References instances; without that patch multiple instances are already running for an hour without issue (out of 8h). This is enough evidence for me that the change is responsible, backing it out to keep the CI clean(er) as I do not really have an idea why at this time (another merge issue after splitting up the original change?).
> 
> Revert applied cleanly except for the hunk in G1PostEvacuateCollectionSetCleanupTask1::G1PostEvacuateCollectionSetCleanupTask1 line 138: an earlier cleanup moved evacuation failure handling to `G1YoungCollector`, causing some merge problems.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From mli at openjdk.java.net  Wed Sep 29 12:20:32 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 29 Sep 2021 12:20:32 GMT
Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with
 few failed objects [v7]
In-Reply-To: <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
References: <rxQ2FwrzzOeY0PsKvMk8NtKBOWFNTY5BzBK2M1znun8=.01d2b88d-3408-48d1-a66b-c84c5034e772@github.com>
 <aILi5ttQziShlwLKGMv7HGKUXAimK8QMKqRtyEEigOg=.4e7e1a9b-dd65-4552-86bc-41f69dc69637@github.com>
Message-ID: <_IhfPoUV7eXnEhX45HKb8DBVQTnkNb3f3qHoSF0Z6Vw=.441c33c9-4d47-41c9-b81d-3f91a15a531f@github.com>

On Thu, 26 Aug 2021 10:04:54 GMT, Hamlin Li <mli at openjdk.org> wrote:

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

Seems I have accidently closed the pr, reopen it.

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

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


From ayang at openjdk.java.net  Wed Sep 29 12:39:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 29 Sep 2021 12:39:42 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor [v2]
In-Reply-To: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
Message-ID: <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com>

> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure.
> 
> 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/5682/files
  - new: https://git.openjdk.java.net/jdk/pull/5682/files/3fd78e03..e8d87db0

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

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

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


From ayang at openjdk.java.net  Wed Sep 29 12:39:42 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 29 Sep 2021 12:39:42 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor [v2]
In-Reply-To: <JvBUl2oBeDNQxpmVWJogWXdkbMz2cKqIRS3FuLIjfQE=.a9befeae-6e1a-4aea-b3b0-989601da4915@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
 <M4ApLMXyycYiOguyKT4ernw9U8-uJQtcvIL_JLNuXfg=.25ec68d0-6f44-4b15-9659-209316051868@github.com>
 <qMO1m1NE6-P3OroKL5mN4oC23K2S6tYAyam40LTp3Ys=.acdc1801-b78e-4183-8f73-62f2e20495df@github.com>
 <JvBUl2oBeDNQxpmVWJogWXdkbMz2cKqIRS3FuLIjfQE=.a9befeae-6e1a-4aea-b3b0-989601da4915@github.com>
Message-ID: <Q1FAWSHbHxX33024_15LRtP96IxdzZF1ifsjdtfVqfo=.425b8dde-a321-4308-bbc0-8f9f6c6bbb97@github.com>

On Mon, 27 Sep 2021 18:05:11 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Answering my own question. Only G1 currently uses precleaning, and it looks fine wrto a concurrent clear. Indeed, I think it's an expensive nop. I suspect (though haven't thought about it carefully yet) that any GC that uses ReferenceProcessor would do nothing there, and I'm not sure preclean actually needs the keep-alive and complete-gc closures.
>
> @albertnetymk  pointed out that I was confused about what referent access we're dealing with in the assert.  That's the referent that was previously loaded and cached in the iterator.  But that just makes the assert confusing in my opinion.  There is nothing about make_referent_alive that depends on that precondition, and indeed the keep-alive function must *not* depend on it.  So I still think the assert should not be added.

My thought was that it can prevent the scenario of unintentionally introducing an expensive nop (marking null referent). Removed now.

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

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


From sjohanss at openjdk.java.net  Wed Sep 29 12:41:39 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 29 Sep 2021 12:41:39 GMT
Subject: RFR: 8274466 G1: simplify G1 collector states
In-Reply-To: <X05x-dn4PlNXl2jZx4mVPxrpZB8wYX7iBbHpmIuVsJc=.995ccd4b-85a2-48d1-a52d-1633d7984ce9@github.com>
References: <X05x-dn4PlNXl2jZx4mVPxrpZB8wYX7iBbHpmIuVsJc=.995ccd4b-85a2-48d1-a52d-1633d7984ce9@github.com>
Message-ID: <U7xtjFYqhdGBJVq4kFNE5yC5bIaeJLwno0fxDMq5ZQM=.7f5bb49c-0345-4d88-ba2e-fddd2a8d397f@github.com>

On Wed, 29 Sep 2021 01:09:41 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This is a minor improvement which remove the redundant G1 Collector states usages.

src/hotspot/share/gc/g1/g1Policy.cpp line 604:

> 602:   bool result = false;
> 603:   if (marking_request_bytes > marking_initiating_used_threshold) {
> 604:     result = collector_state()->in_young_only_phase();

To me this looks like a change in behavior. The check you have removed is there to prevent requesting a new concurrent cycle when in the "Prepare Mixed" collections (the young GC preceding mixed collections).

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

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


From sjohanss at openjdk.java.net  Wed Sep 29 12:46:33 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 29 Sep 2021 12:46:33 GMT
Subject: RFR: 8274430: Remove some debug error printing code added in
 JDK-8017163
In-Reply-To: <Sxbxv1V_5hPz2vErtFoxnW-JL4R19-fp5OBduxHR7Q8=.10bad668-e217-43fe-bb60-ee720ee85072@github.com>
References: <Sxbxv1V_5hPz2vErtFoxnW-JL4R19-fp5OBduxHR7Q8=.10bad668-e217-43fe-bb60-ee720ee85072@github.com>
Message-ID: <KAolC8LKrV0PtllWu3JcUILsIqmNgz11h6QBWFVPsow=.7898ac1f-cb9d-4f63-9da0-0b1d7001736a@github.com>

On Tue, 28 Sep 2021 08:59:23 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that undoes some logging changes from JDK-8017163, in particular it added the `XXX card set` lines in the output as shown in an example below:
> 
> ``` [171.616s][1632757560415ms][error][gc,verify ] GC(129) Missing rem set entry:
> [171.616s][1632757560415ms][error][gc,verify ] GC(129) Field 0x00000007fb1008f0 of obj 0x00000007fb1008d8 in region 1485:(O)[0x00000007fb000000,0x00000
> [171.616s][1632757560415ms][error][gc,verify ] GC(129) NULL card setjava.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry
> [...]
> points to obj 0x00000004d9abd4c8 in region 683:(S)[0x00000004d9000000,0x00000004da000000,0x00000004da000000] remset Complete
> 
> 
> This string would indicate which card set container does not have the requested remembered set entry. This is unnecessary information, as the "points to obj" string later shows that there should be a remset to this region already, and otherwise only interesting for debugging.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5733


From tschatzl at openjdk.java.net  Wed Sep 29 14:03:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 29 Sep 2021 14:03:37 GMT
Subject: RFR: 8274340: [BACKOUT] JDK-8271880: Tighten condition for
 excluding regions from collecting cards with cross-references
In-Reply-To: <CDCpuRiireua-NmHDFniBVwczOoEQamwmAR4KVFjDdc=.7e5c13c5-b855-427d-8d4e-2500c88824a2@github.com>
References: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
 <CDCpuRiireua-NmHDFniBVwczOoEQamwmAR4KVFjDdc=.7e5c13c5-b855-427d-8d4e-2500c88824a2@github.com>
Message-ID: <h-fqgzaPJIuP5B6WMi7qYlzdDKohxuD3zyfIQGst6oc=.31c1026a-f69e-4827-a1f5-96db3beec322@github.com>

On Wed, 29 Sep 2021 12:05:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this backout of JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references because it causes failures with Kitchensink runs.
>> 
>> As the CR indicates, with proper verification these runs fail fairly quickly after 5-20mins with a remembered set verification failure on the discovered field of some j.l.ref.References instances; without that patch multiple instances are already running for an hour without issue (out of 8h). This is enough evidence for me that the change is responsible, backing it out to keep the CI clean(er) as I do not really have an idea why at this time (another merge issue after splitting up the original change?).
>> 
>> Revert applied cleanly except for the hunk in G1PostEvacuateCollectionSetCleanupTask1::G1PostEvacuateCollectionSetCleanupTask1 line 138: an earlier cleanup moved evacuation failure handling to `G1YoungCollector`, causing some merge problems.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @kimbarrett for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5734


From tschatzl at openjdk.java.net  Wed Sep 29 14:03:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 29 Sep 2021 14:03:38 GMT
Subject: Integrated: 8274340: [BACKOUT] JDK-8271880: Tighten condition for
 excluding regions from collecting cards with cross-references
In-Reply-To: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
References: <YvU-STyI3pfdDO_6GW46FX8Vx5oVYFpr1UHzbY72h9I=.3ccf5071-8be4-4740-9008-8dbeb22a9d52@github.com>
Message-ID: <I4DlK3maHnhJvmK6b4DJyzSa7LDwbUhhtrGxcfbKAuo=.bbcae2b9-0394-4ee7-a8d0-024618afa90f@github.com>

On Tue, 28 Sep 2021 09:14:04 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this backout of JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references because it causes failures with Kitchensink runs.
> 
> As the CR indicates, with proper verification these runs fail fairly quickly after 5-20mins with a remembered set verification failure on the discovered field of some j.l.ref.References instances; without that patch multiple instances are already running for an hour without issue (out of 8h). This is enough evidence for me that the change is responsible, backing it out to keep the CI clean(er) as I do not really have an idea why at this time (another merge issue after splitting up the original change?).
> 
> Revert applied cleanly except for the hunk in G1PostEvacuateCollectionSetCleanupTask1::G1PostEvacuateCollectionSetCleanupTask1 line 138: an earlier cleanup moved evacuation failure handling to `G1YoungCollector`, causing some merge problems.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 1dc8fa99
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1dc8fa9902cf2cfa3556ccffb15244115f594966
Stats:     171 lines in 14 files changed: 74 ins; 76 del; 21 mod

8274340: [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references

Reviewed-by: kbarrett, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/5734


From manc at openjdk.java.net  Wed Sep 29 20:15:53 2021
From: manc at openjdk.java.net (Man Cao)
Date: Wed, 29 Sep 2021 20:15:53 GMT
Subject: RFR: 8274178: Occupancy value in logging and JFR event is inaccurate
 in G1IHOPControl
Message-ID: <eda1d_YlogGjwELjybLTTJCsKrxGQKOo45RvtM8yHpQ=.0c8d10ca-3e4a-4678-b707-c358fbfd21fb@github.com>

Hi all,

Could we have reviews for this minor fix for logging and JFR event occupancy number for G1? See https://bugs.openjdk.java.net/browse/JDK-8274178 for more details.

This fix is contributed by colleague Jonathan Joo <jonathanjoo at google.com>.

-------------

Commit messages:
 - Improve occupancy logging message for G1 IHOP

Changes: https://git.openjdk.java.net/jdk/pull/5762/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5762&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274178
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5762.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5762/head:pull/5762

PR: https://git.openjdk.java.net/jdk/pull/5762


From kbarrett at openjdk.java.net  Wed Sep 29 22:14:45 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 29 Sep 2021 22:14:45 GMT
Subject: RFR: 8274286: Skip null for make_referent_alive in
 referenceProcessor [v2]
In-Reply-To: <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com>
References: <xVOWUdPUZXyn5cKcV6Bn304XbMGJrgqUU8PA2eQQZOw=.9eeddb05-cf68-450b-85b8-022604ea2c40@github.com>
 <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com>
Message-ID: <b3UfgksvXItblcxZbSCyh4uEn4NX3Z88_aX5OzHEEYM=.6c98136e-ecae-4239-8058-79bec60c88dd@github.com>

On Wed, 29 Sep 2021 12:39:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good, other than mentioned over-deletion in comment.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 1130:

> 1128: // Walk the given discovered ref list, and remove all reference objects
> 1129: // whose referents are still alive, whose referents are NULL or which
> 1130: // are not active (have a non-NULL next field). NOTE: When we are

I think the part of the comment beginning with "NOTE" is still relevant and should not be deleted.  Apologies for not pointing this out earlier.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5682


From mli at openjdk.java.net  Thu Sep 30 01:34:28 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 30 Sep 2021 01:34:28 GMT
Subject: RFR: 8274466 G1: simplify G1 collector states [v2]
In-Reply-To: <X05x-dn4PlNXl2jZx4mVPxrpZB8wYX7iBbHpmIuVsJc=.995ccd4b-85a2-48d1-a52d-1633d7984ce9@github.com>
References: <X05x-dn4PlNXl2jZx4mVPxrpZB8wYX7iBbHpmIuVsJc=.995ccd4b-85a2-48d1-a52d-1633d7984ce9@github.com>
Message-ID: <zblNpgOChdXwUJcDUSi0kuNieMelksj4Uv4u2Iv2rSc=.4a3742a6-1349-471d-81d0-81023d771254@github.com>

> This is a minor improvement which remove the redundant G1 Collector states usages.

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  Revert wrong code

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5745/files
  - new: https://git.openjdk.java.net/jdk/pull/5745/files/e2a4eae7..9bbe1ccc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5745&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5745&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5745.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5745/head:pull/5745

PR: https://git.openjdk.java.net/jdk/pull/5745


From mli at openjdk.java.net  Thu Sep 30 01:34:29 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 30 Sep 2021 01:34:29 GMT
Subject: RFR: 8274466 G1: simplify G1 collector states [v2]
In-Reply-To: <U7xtjFYqhdGBJVq4kFNE5yC5bIaeJLwno0fxDMq5ZQM=.7f5bb49c-0345-4d88-ba2e-fddd2a8d397f@github.com>
References: <X05x-dn4PlNXl2jZx4mVPxrpZB8wYX7iBbHpmIuVsJc=.995ccd4b-85a2-48d1-a52d-1633d7984ce9@github.com>
 <U7xtjFYqhdGBJVq4kFNE5yC5bIaeJLwno0fxDMq5ZQM=.7f5bb49c-0345-4d88-ba2e-fddd2a8d397f@github.com>
Message-ID: <mIYxr62oO4wHOOT_rzWNDSc3sP1P0CwyxD7qAzvDM3U=.0f4d34fb-e374-4b54-a6e5-3f199884759e@github.com>

On Wed, 29 Sep 2021 12:38:25 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert wrong code
>
> src/hotspot/share/gc/g1/g1Policy.cpp line 604:
> 
>> 602:   bool result = false;
>> 603:   if (marking_request_bytes > marking_initiating_used_threshold) {
>> 604:     result = collector_state()->in_young_only_phase();
> 
> To me this looks like a change in behavior. The check you have removed is there to prevent requesting a new concurrent cycle when in the "Prepare Mixed" collections (the young GC preceding mixed collections).

Thanks for catching this, I have fixed it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/5745


From github.com+16811675+linade at openjdk.java.net  Thu Sep 30 09:31:46 2021
From: github.com+16811675+linade at openjdk.java.net (Yude Lin)
Date: Thu, 30 Sep 2021 09:31:46 GMT
Subject: RFR: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy
Message-ID: <qgI0F1nYm8hbJT8kyjaE8gSNhr35OrQrWDvXbGxc61g=.5e4a6191-00da-4e5d-a8a8-2d3012a34a19@github.com>

Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp

-------------

Commit messages:
 - 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy

Changes: https://git.openjdk.java.net/jdk/pull/5770/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5770&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274546
  Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5770.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5770/head:pull/5770

PR: https://git.openjdk.java.net/jdk/pull/5770


From zgu at openjdk.java.net  Thu Sep 30 11:20:30 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 30 Sep 2021 11:20:30 GMT
Subject: RFR: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask
 copy
In-Reply-To: <qgI0F1nYm8hbJT8kyjaE8gSNhr35OrQrWDvXbGxc61g=.5e4a6191-00da-4e5d-a8a8-2d3012a34a19@github.com>
References: <qgI0F1nYm8hbJT8kyjaE8gSNhr35OrQrWDvXbGxc61g=.5e4a6191-00da-4e5d-a8a8-2d3012a34a19@github.com>
Message-ID: <fHGf5oCAQO0MBMCW5hU0ZHVLj2NrgMLwt9zWOfArU5I=.0f8e0ecf-b0f8-49f4-b4b0-c92b19614a80@github.com>

On Thu, 30 Sep 2021 09:23:48 GMT, Yude Lin <github.com+16811675+linade at openjdk.org> wrote:

> Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp

Looks good. Thanks for cleaning up.

-------------

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5770