From tschatzl at openjdk.java.net  Tue Mar  1 08:39:06 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Mar 2022 08:39:06 GMT
Subject: RFR: 8282094: [REDO] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <ifaDwJrnTfOeBeTg0zTmfBz5pEwXBDxZm7_LvOAiYS0=.243c34a8-bbc3-4c88-9e68-11e90d765d94@github.com>
References: <ifaDwJrnTfOeBeTg0zTmfBz5pEwXBDxZm7_LvOAiYS0=.243c34a8-bbc3-4c88-9e68-11e90d765d94@github.com>
Message-ID: <A0BHsP80LSwG-EVJNgpZ-sFSRrpg35gFHXstR4dXfq0=.c55fc431-4a3a-4ab0-a711-e620cc835ba1@github.com>

On Tue, 22 Feb 2022 11:59:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly the same as [JDK-8280783](https://bugs.openjdk.java.net/browse/JDK-8280783), except one assertion is weakened.
> 
> 
> assert(*dirty_r == clean_card || dirty_r >= clear_limit_r);
> 
> 
> Test: tier1-6
> I also tried to reproduce the failures in https://bugs.openjdk.java.net/browse/JDK-8282062, but to no avail.

Lgtm.

Fwiw, in redos it is typically a nice to have two commits if the actual change is minimal: the first one re-adding the original change, the second one the actual difference. That makes reviewing even easier. :)

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Mar  1 09:21:04 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Mar 2022 09:21:04 GMT
Subject: RFR: 8282381: Parallel: Remove unnecessary PCReferenceProcessor
In-Reply-To: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>
References: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>
Message-ID: <6cN0GpfoOeOkrbBXmVCwqdyruYv-_6_AollK4aTwT_g=.b30fb56f-a152-44e4-8fba-029d7897a327@github.com>

On Fri, 25 Feb 2022 07:14:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant class.
> 
> Test: tier1-5

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Mar  1 09:34:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Mar 2022 09:34:05 GMT
Subject: RFR: 8267834: Refactor G1CardSetAllocator and
 BufferNode::Allocator to use a common base class [v3]
In-Reply-To: <5uh-Qua4253Tv4PgIQqNte4jCDH8mF1h2g0PW5ySKeI=.d3f1c644-dc54-435b-a8bb-5af145d49e57@github.com>
References: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
 <5uh-Qua4253Tv4PgIQqNte4jCDH8mF1h2g0PW5ySKeI=.d3f1c644-dc54-435b-a8bb-5af145d49e57@github.com>
Message-ID: <6f68B76EWwgZkx3AwaiHy4C1TWyezi9zBPhnVhZYUUs=.b353839c-5e1b-4118-a857-fa245a3d874b@github.com>

On Fri, 25 Feb 2022 12:27:51 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to combine free list allocation used in G1CardSetAllocator and BufferNode::Allocator into a single class. 
>> 
>> Testing: Tier 1-5
>> 
>> Thanks
>> Ivan
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim review

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Tue Mar  1 09:36:16 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Mar 2022 09:36:16 GMT
Subject: RFR: 8282094: [REDO] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <A0BHsP80LSwG-EVJNgpZ-sFSRrpg35gFHXstR4dXfq0=.c55fc431-4a3a-4ab0-a711-e620cc835ba1@github.com>
References: <ifaDwJrnTfOeBeTg0zTmfBz5pEwXBDxZm7_LvOAiYS0=.243c34a8-bbc3-4c88-9e68-11e90d765d94@github.com>
 <A0BHsP80LSwG-EVJNgpZ-sFSRrpg35gFHXstR4dXfq0=.c55fc431-4a3a-4ab0-a711-e620cc835ba1@github.com>
Message-ID: <QCRZSW26bKX3dn4Q2KlEII-Tgj5pN5bcSHJZvV9iQL0=.46087e49-94e7-4f33-a25b-7a22ade09011@github.com>

On Tue, 1 Mar 2022 08:35:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Fwiw, in redos it is typically a nice to have two commits if the actual change is minimal:

Got it; will do so next time.

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Mar  1 09:36:17 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Mar 2022 09:36:17 GMT
Subject: Integrated: 8282094: [REDO] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <ifaDwJrnTfOeBeTg0zTmfBz5pEwXBDxZm7_LvOAiYS0=.243c34a8-bbc3-4c88-9e68-11e90d765d94@github.com>
References: <ifaDwJrnTfOeBeTg0zTmfBz5pEwXBDxZm7_LvOAiYS0=.243c34a8-bbc3-4c88-9e68-11e90d765d94@github.com>
Message-ID: <m8dnb8c1l2yBXv45dmXJQ4yg6NgA840Dxj048nSL4u4=.9471fd8b-a700-480a-a8e8-bef235bf011a@github.com>

On Tue, 22 Feb 2022 11:59:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly the same as [JDK-8280783](https://bugs.openjdk.java.net/browse/JDK-8280783), except one assertion is weakened.
> 
> 
> assert(*dirty_r == clean_card || dirty_r >= clear_limit_r);
> 
> 
> Test: tier1-6
> I also tried to reproduce the failures in https://bugs.openjdk.java.net/browse/JDK-8282062, but to no avail.

This pull request has now been integrated.

Changeset: 22b93a31
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/22b93a31c99403996b6272b7c8eb0b9918988862
Stats:     277 lines in 2 files changed: 103 ins; 101 del; 73 mod

8282094: [REDO] Parallel: Refactor PSCardTable::scavenge_contents_parallel

Reviewed-by: iwalulya, tschatzl

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

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


From mli at openjdk.java.net  Tue Mar  1 10:05:50 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 1 Mar 2022 10:05:50 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v10]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <Drszef97b1TJRltTjCbYuTM0ZPTU_0Akck8N4e0_qdo=.268c940e-f276-471e-b6f2-83f326911c58@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Albert review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/f47a1f36..13a6311e

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

  Stats: 111 lines in 4 files changed: 50 ins; 48 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From mli at openjdk.java.net  Tue Mar  1 10:05:50 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 1 Mar 2022 10:05:50 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v9]
In-Reply-To: <utq8d2qP_IzhEkJINtPAalpApQlpabQhoBaPhK6cFBI=.dc85a91e-0b68-4e9d-b978-f71d4a0fec29@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <rVcZyYfg4vb64MsT8JrIJoQjKg8oZxeCIv4URODTCCo=.28f13f8f-800e-4bf2-86f6-0bdb35c31a3b@github.com>
 <utq8d2qP_IzhEkJINtPAalpApQlpabQhoBaPhK6cFBI=.dc85a91e-0b68-4e9d-b978-f71d4a0fec29@github.com>
Message-ID: <kIt1D2sw8Wz0hYQzwS-kocuHhiSVnPSaeWVWOhutUQo=.dd7bc07b-dfd3-4971-825c-397747fc1fb8@github.com>

On Mon, 28 Feb 2022 09:55:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 4. I don't understand why `RemoveSelfForwardChunksPerRegion` is inside `...WorkItems`. #chunks_per_region should be a constant shared by all workers. Its siblings are worker-local stats, which are sensible to have inside `...WorkItems`.

Thanks, I will update the patch as you suggested except the last one. In fact, I do have the same question as you, but IMO currently G1GCPhaseTimes supports time and work item, and work item only supports in per thread style.

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

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


From tschatzl at openjdk.java.net  Tue Mar  1 11:37:17 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Mar 2022 11:37:17 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v9]
In-Reply-To: <kIt1D2sw8Wz0hYQzwS-kocuHhiSVnPSaeWVWOhutUQo=.dd7bc07b-dfd3-4971-825c-397747fc1fb8@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <rVcZyYfg4vb64MsT8JrIJoQjKg8oZxeCIv4URODTCCo=.28f13f8f-800e-4bf2-86f6-0bdb35c31a3b@github.com>
 <utq8d2qP_IzhEkJINtPAalpApQlpabQhoBaPhK6cFBI=.dc85a91e-0b68-4e9d-b978-f71d4a0fec29@github.com>
 <kIt1D2sw8Wz0hYQzwS-kocuHhiSVnPSaeWVWOhutUQo=.dd7bc07b-dfd3-4971-825c-397747fc1fb8@github.com>
Message-ID: <53PhHUwQ5VB6EfZyVF5fKeOHshRjEGP5kDPMafeNLNs=.6daabf05-7f2a-4002-ae4e-c0cc91241b2f@github.com>

On Tue, 1 Mar 2022 10:01:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > 4. I don't understand why `RemoveSelfForwardChunksPerRegion` is inside `...WorkItems`. #chunks_per_region should be a constant shared by all workers. Its siblings are worker-local stats, which are sensible to have inside `...WorkItems`.
> 
> Thanks, I will update the patch as you suggested except the last one. In fact, I do have the same question as you, but IMO currently G1GCPhaseTimes supports time and work item, and work item only supports in per thread style.

Sorry, I did not catch this question immediately: `RemoveSelfForwardChunksPerRegion` does not need to be stored within this part of the log. It could be included in a message like for other `WorkerThreads` invocations like in `HeapRegionManager::rebuild_free_list` instead of putting it into `G1GCPhaseTimes`:


  log_debug(gc, ergo)("Running %s using %u workers for removing self forwards with %u chunks per region",
                      task.name(), num_workers, chunk_size);


Thomas

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

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


From iwalulya at openjdk.java.net  Tue Mar  1 14:18:09 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 1 Mar 2022 14:18:09 GMT
Subject: RFR: 8267834: Refactor G1CardSetAllocator and
 BufferNode::Allocator to use a common base class [v3]
In-Reply-To: <oTjGSMpg0r50tbSeKPolu1_Ci5YMyJ8VpIc_ASbOsAU=.09a48427-d90d-450b-b3cb-a2fe8ba3f77f@github.com>
References: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
 <5uh-Qua4253Tv4PgIQqNte4jCDH8mF1h2g0PW5ySKeI=.d3f1c644-dc54-435b-a8bb-5af145d49e57@github.com>
 <oTjGSMpg0r50tbSeKPolu1_Ci5YMyJ8VpIc_ASbOsAU=.09a48427-d90d-450b-b3cb-a2fe8ba3f77f@github.com>
Message-ID: <meIi5G-xTB-31cWUqGrvdUiyv5rpJWgtpodc9gN2dq8=.45baec92-6007-473a-bc56-c9842367f60b@github.com>

On Fri, 25 Feb 2022 15:55:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Kim review
>
> Looks good.

Thanks @kimbarrett, @tschatzl for your reviews

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

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


From iwalulya at openjdk.java.net  Tue Mar  1 14:18:10 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 1 Mar 2022 14:18:10 GMT
Subject: Integrated: 8267834: Refactor G1CardSetAllocator and
 BufferNode::Allocator to use a common base class
In-Reply-To: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
References: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
Message-ID: <6PZ8n5mS_02tAKRPLCO5eYSXOxcK9Qss9PHnQ_-pLME=.cbeb8844-7163-470b-9722-446e5c0801b0@github.com>

On Thu, 24 Feb 2022 15:33:58 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to combine free list allocation used in G1CardSetAllocator and BufferNode::Allocator into a single class. 
> 
> Testing: Tier 1-5
> 
> Thanks
> Ivan

This pull request has now been integrated.

Changeset: 341c8bd7
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/341c8bd7f2744d1899e78da34e613817b43b44e5
Stats:     724 lines in 10 files changed: 389 ins; 288 del; 47 mod

8267834: Refactor G1CardSetAllocator and BufferNode::Allocator to use a common base class

Reviewed-by: kbarrett, tschatzl

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

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


From ccheung at openjdk.java.net  Wed Mar  2 07:15:31 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 2 Mar 2022 07:15:31 GMT
Subject: RFR: 8274788: Support archived heap objects in ParallelGC
Message-ID: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>

With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
loaded from the archive.


$ perf stat -r 40 -XX:+UseParallelGC -version

before: 0.069244290 seconds time elapsed            ( +-  0.49% )
after:    0.058555167 seconds time elapsed          ( +-  0.49% )

Passed CI tiers 1 - 4 tests.

Thanks @tschatzl for his help on GC changes.

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

Commit messages:
 - 8274788: Support archived heap objects in ParallelGC

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

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


From iklam at openjdk.java.net  Wed Mar  2 08:07:03 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 2 Mar 2022 08:07:03 GMT
Subject: RFR: 8274788: Support archived heap objects in ParallelGC
In-Reply-To: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
References: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
Message-ID: <FAPa5XhplkTKsPmQ29aP87ohzdCCL9CD_fhHLDCnX10=.6bab8a60-4785-4557-a807-e2d4d11611e4@github.com>

On Wed, 2 Mar 2022 07:04:28 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
> into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
> loaded from the archive.
> 
> 
> $ perf stat -r 40 -XX:+UseParallelGC -version
> 
> before: 0.069244290 seconds time elapsed            ( +-  0.49% )
> after:    0.058555167 seconds time elapsed          ( +-  0.49% )
> 
> Passed CI tiers 1 - 4 tests.
> 
> Thanks @tschatzl for his help on GC changes.

The CDS and test changes look good to me.

test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java line 2:

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

Should be 2022

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

Marked as reviewed by iklam (Reviewer).

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


From ayang at openjdk.java.net  Wed Mar  2 08:29:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Mar 2022 08:29:09 GMT
Subject: RFR: 8274788: Support archived heap objects in ParallelGC
In-Reply-To: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
References: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
Message-ID: <-_NAN4zdzvvsrmgxduuVqcr-VHCqCxF-iHeAPqiARR0=.c1c45d93-fbe3-4691-9542-a7d601dfa479@github.com>

On Wed, 2 Mar 2022 07:04:28 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
> into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
> loaded from the archive.
> 
> 
> $ perf stat -r 40 -XX:+UseParallelGC -version
> 
> before: 0.069244290 seconds time elapsed            ( +-  0.49% )
> after:    0.058555167 seconds time elapsed          ( +-  0.49% )
> 
> Passed CI tiers 1 - 4 tests.
> 
> Thanks @tschatzl for his help on GC changes.

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Mar  2 08:54:04 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 2 Mar 2022 08:54:04 GMT
Subject: RFR: 8274788: Support archived heap objects in ParallelGC
In-Reply-To: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
References: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
Message-ID: <q0S0u9ZTkTwEith6J5xlX8Flg3FCYxrXZM8U2BhdCEo=.6a11a966-2583-4b52-b8b1-3dc5d8c303e1@github.com>

On Wed, 2 Mar 2022 07:04:28 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
> into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
> loaded from the archive.
> 
> 
> $ perf stat -r 40 -XX:+UseParallelGC -version
> 
> before: 0.069244290 seconds time elapsed            ( +-  0.49% )
> after:    0.058555167 seconds time elapsed          ( +-  0.49% )
> 
> Passed CI tiers 1 - 4 tests.
> 
> Thanks @tschatzl for his help on GC changes.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Wed Mar  2 09:15:04 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Mar 2022 09:15:04 GMT
Subject: Integrated: 8282381: Parallel: Remove unnecessary PCReferenceProcessor
In-Reply-To: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>
References: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>
Message-ID: <ZxiN9sp1u7n17lBU5ZpNXSeejU6alMgcWKzcTjmVsDA=.98896a71-2697-4b85-a0ce-62db399853f1@github.com>

On Fri, 25 Feb 2022 07:14:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant class.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 12a822a2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/12a822a2875568f4ffd683e8ad9451ebee03ee7e
Stats:     32 lines in 1 file changed: 3 ins; 27 del; 2 mod

8282381: Parallel: Remove unnecessary PCReferenceProcessor

Reviewed-by: kbarrett, tschatzl

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

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


From ayang at openjdk.java.net  Wed Mar  2 09:15:04 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Mar 2022 09:15:04 GMT
Subject: RFR: 8282381: Parallel: Remove unnecessary PCReferenceProcessor
In-Reply-To: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>
References: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>
Message-ID: <ttw_UTvOPqPSuc6zovfnqbPG4wj9aaFuE-iDeIHSbH4=.a8ac07d8-baf6-4b23-8f25-e7f44316cfc6@github.com>

On Fri, 25 Feb 2022 07:14:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant class.
> 
> Test: tier1-5

Thanks for the review.

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

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


From tschatzl at openjdk.java.net  Wed Mar  2 10:02:30 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 2 Mar 2022 10:02:30 GMT
Subject: RFR: 8282484: G1: Predicted old time in log always zero
Message-ID: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>

Hi all,

  can I get reviews for this change that fixes log output for the amount of expected time the initial set of old gen regions is going to take?

Previously, due to this error, this value has always been zero.

Testing: local testing, gha

Thanks,
  Thomas

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

Commit messages:
 - Initial version

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

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


From ayang at openjdk.java.net  Wed Mar  2 10:12:01 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Mar 2022 10:12:01 GMT
Subject: RFR: 8282484: G1: Predicted old time in log always zero
In-Reply-To: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
References: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
Message-ID: <G7vQDSf0kULVdcA78v6cQQzuar0EGPB5vpvLJLq1wLM=.dfc18777-b077-4a65-aaaa-f5094548d29f@github.com>

On Wed, 2 Mar 2022 09:56:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that fixes log output for the amount of expected time the initial set of old gen regions is going to take?
> 
> Previously, due to this error, this value has always been zero.
> 
> Testing: local testing, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From iwalulya at openjdk.java.net  Wed Mar  2 10:17:03 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 2 Mar 2022 10:17:03 GMT
Subject: RFR: 8282484: G1: Predicted old time in log always zero
In-Reply-To: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
References: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
Message-ID: <Fz3nQmjA7AqsM2ZaanEKiCdB_99DZeY6Tbltq7bZOcs=.8d19b10a-4788-4226-88ff-a1c8d1590009@github.com>

On Wed, 2 Mar 2022 09:56:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that fixes log output for the amount of expected time the initial set of old gen regions is going to take?
> 
> Previously, due to this error, this value has always been zero.
> 
> Testing: local testing, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

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


From mli at openjdk.java.net  Wed Mar  2 14:28:51 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 2 Mar 2022 14:28:51 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v11]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <-05U76-qUQdzA2vDJyBHTuYwwkTrRUS96a38ui8tmVI=.f04949ec-4680-4161-93bb-85a95eaf47c9@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  move 'chunks per region' log

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/13a6311e..2ec162c9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=09-10

  Stats: 19 lines in 8 files changed: 6 ins; 2 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From mli at openjdk.java.net  Wed Mar  2 14:28:52 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 2 Mar 2022 14:28:52 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v10]
In-Reply-To: <Drszef97b1TJRltTjCbYuTM0ZPTU_0Akck8N4e0_qdo=.268c940e-f276-471e-b6f2-83f326911c58@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <Drszef97b1TJRltTjCbYuTM0ZPTU_0Akck8N4e0_qdo=.268c940e-f276-471e-b6f2-83f326911c58@github.com>
Message-ID: <EyEyh2Y6-8z9k5VP9EaRXybjpjrxmL4BiyCpfPKaQjk=.d04a6e6c-a123-4e7b-9b3d-076afb1bfff4@github.com>

On Tue, 1 Mar 2022 10:05:50 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Thanks for clarification, I see the point.
Will update the patch.

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

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


From ccheung at openjdk.java.net  Wed Mar  2 16:08:58 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 2 Mar 2022 16:08:58 GMT
Subject: RFR: 8274788: Support archived heap objects in ParallelGC [v2]
In-Reply-To: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
References: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
Message-ID: <MogEtsDymzzQIpuVVGWfTgDhWxOQMDlPidmmoy4MYLE=.32b045da-adbb-4f44-824d-659554bca2c4@github.com>

> With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
> into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
> loaded from the archive.
> 
> 
> $ perf stat -r 40 -XX:+UseParallelGC -version
> 
> before: 0.069244290 seconds time elapsed            ( +-  0.49% )
> after:    0.058555167 seconds time elapsed          ( +-  0.49% )
> 
> Passed CI tiers 1 - 4 tests.
> 
> Thanks @tschatzl for his help on GC changes.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  update copyright header

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7655/files
  - new: https://git.openjdk.java.net/jdk/pull/7655/files/350a1300..658e6e79

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

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

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


From ccheung at openjdk.java.net  Wed Mar  2 16:21:09 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 2 Mar 2022 16:21:09 GMT
Subject: RFR: 8274788: Support archived heap objects in ParallelGC [v2]
In-Reply-To: <MogEtsDymzzQIpuVVGWfTgDhWxOQMDlPidmmoy4MYLE=.32b045da-adbb-4f44-824d-659554bca2c4@github.com>
References: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
 <MogEtsDymzzQIpuVVGWfTgDhWxOQMDlPidmmoy4MYLE=.32b045da-adbb-4f44-824d-659554bca2c4@github.com>
Message-ID: <qhqr-3zzaec2nXfoTpe1jSDDYqWRE2muLF4t_4QGC2I=.70a4ced2-e301-4ab3-a774-9b79fef46ade@github.com>

On Wed, 2 Mar 2022 16:08:58 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
>> into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
>> loaded from the archive.
>> 
>> 
>> $ perf stat -r 40 -XX:+UseParallelGC -version
>> 
>> before: 0.069244290 seconds time elapsed            ( +-  0.49% )
>> after:    0.058555167 seconds time elapsed          ( +-  0.49% )
>> 
>> Passed CI tiers 1 - 4 tests.
>> 
>> Thanks @tschatzl for his help on GC changes.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyright header

Thanks Ioi, Albert, Thomas for the review.

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

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


From ccheung at openjdk.java.net  Wed Mar  2 16:21:11 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 2 Mar 2022 16:21:11 GMT
Subject: Integrated: 8274788: Support archived heap objects in ParallelGC
In-Reply-To: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
References: <9yUfO8bTAc0FsspTWwp3jEe82C0ea4JPbuItIp-dAPk=.40d38b13-1c6e-41ff-8f48-b1182309bb53@github.com>
Message-ID: <_JuJqOWK-67-rUNyR2Ncd9qgG_pAsEKEavIcRTlnimw=.eb67804b-0093-4613-8972-57182b4e91f5@github.com>

On Wed, 2 Mar 2022 07:04:28 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> With this change when the UseParallelGC is enabled, the CDS archived heap objects could be loaded
> into the PSOldGen during VM bootstrap. This improves startup time since the module graph could be
> loaded from the archive.
> 
> 
> $ perf stat -r 40 -XX:+UseParallelGC -version
> 
> before: 0.069244290 seconds time elapsed            ( +-  0.49% )
> after:    0.058555167 seconds time elapsed          ( +-  0.49% )
> 
> Passed CI tiers 1 - 4 tests.
> 
> Thanks @tschatzl for his help on GC changes.

This pull request has now been integrated.

Changeset: 234c17e8
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/234c17e8ff7b9b9713e9fded693381f985d34d2a
Stats:     156 lines in 7 files changed: 155 ins; 0 del; 1 mod

8274788: Support archived heap objects in ParallelGC

Reviewed-by: iklam, ayang, tschatzl

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 09:30:08 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 09:30:08 GMT
Subject: RFR: 8282484: G1: Predicted old time in log always zero
In-Reply-To: <Fz3nQmjA7AqsM2ZaanEKiCdB_99DZeY6Tbltq7bZOcs=.8d19b10a-4788-4226-88ff-a1c8d1590009@github.com>
References: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
 <Fz3nQmjA7AqsM2ZaanEKiCdB_99DZeY6Tbltq7bZOcs=.8d19b10a-4788-4226-88ff-a1c8d1590009@github.com>
Message-ID: <vE1Yp0odlnPwVH7z1FL6PR2kiraXimtzo9WpaZVo1bs=.fffc125d-96ac-4a54-9e7f-88d7fcb24d6b@github.com>

On Wed, 2 Mar 2022 10:13:31 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that fixes log output for the amount of expected time the initial set of old gen regions is going to take?
>> 
>> Previously, due to this error, this value has always been zero.
>> 
>> Testing: local testing, gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by iwalulya (Reviewer).

Thanks @walulyai @albertnetymk for your reviews

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 09:30:09 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 09:30:09 GMT
Subject: Integrated: 8282484: G1: Predicted old time in log always zero
In-Reply-To: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
References: <NHYbeWyCfn33fH1bpS2HcUSuNrkxVS1XpwL5eu_egsg=.c99b79f3-a125-48ed-8e46-40734a741b29@github.com>
Message-ID: <bA0j4Z-2j7z8cuGCwtOhB5vbnywU7vf8BO0MoavGkWI=.eabba139-4784-4b6a-a3fc-c29f3ea30099@github.com>

On Wed, 2 Mar 2022 09:56:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that fixes log output for the amount of expected time the initial set of old gen regions is going to take?
> 
> Previously, due to this error, this value has always been zero.
> 
> Testing: local testing, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: d4d1fbc2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d4d1fbc27a2382d8d9545b7bf672cdcc81654404
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8282484: G1: Predicted old time in log always zero

Reviewed-by: ayang, iwalulya

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 15:57:21 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 15:57:21 GMT
Subject: RFR: 8282615: G1: Fix some includes
Message-ID: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>

Hi all,

  can I have reviews for this simple change that fixes includes in some G1 files? The most serious is probably the one in `g1CardSetContainers.hpp` which included a `.inline.hpp` file directly.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - Initial version

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

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


From ayang at openjdk.java.net  Thu Mar  3 16:04:05 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 3 Mar 2022 16:04:05 GMT
Subject: RFR: 8282615: G1: Fix some includes
In-Reply-To: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
References: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
Message-ID: <I0E2zsVdWbOrhzQXpLKDlUX2e-RX0wRSffH-YnRJVdI=.ab72fb80-7592-4d46-aab0-a693ce8940bd@github.com>

On Thu, 3 Mar 2022 15:49:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this simple change that fixes includes in some G1 files? The most serious is probably the one in `g1CardSetContainers.hpp` which included a `.inline.hpp` file directly.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 16:06:28 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 16:06:28 GMT
Subject: RFR: 8282619: G1: Fix indentation in
 G1CollectedHeap::mark_evac_failure_object
Message-ID: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>

Hi all,

  please review this trivial fix to indentation in `G1CollectedHeap::mark_evac_failure_object`.

Thanks,
  Thomas

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

Commit messages:
 - Initial version

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

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


From iwalulya at openjdk.java.net  Thu Mar  3 16:13:03 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 3 Mar 2022 16:13:03 GMT
Subject: RFR: 8282615: G1: Fix some includes
In-Reply-To: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
References: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
Message-ID: <wePTmtWtaaa4Xoz8z4avg-u3oSmuO6K7i23NluTsKAg=.2a0d3647-33a1-42d5-902a-27a6bfa1c19d@github.com>

On Thu, 3 Mar 2022 15:49:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this simple change that fixes includes in some G1 files? The most serious is probably the one in `g1CardSetContainers.hpp` which included a `.inline.hpp` file directly.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

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


From ayang at openjdk.java.net  Thu Mar  3 16:13:04 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 3 Mar 2022 16:13:04 GMT
Subject: RFR: 8282619: G1: Fix indentation in
 G1CollectedHeap::mark_evac_failure_object
In-Reply-To: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
References: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
Message-ID: <KjVWn2krTsN3LsA2itcLtzRjrU3rMfm6kbV0zCByAK0=.34a9c1e0-50a3-4d53-9230-57d2e1008129@github.com>

On Thu, 3 Mar 2022 15:55:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial fix to indentation in `G1CollectedHeap::mark_evac_failure_object`.
> 
> Thanks,
>   Thomas

Good and trivial.

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

Marked as reviewed by ayang (Reviewer).

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


From iwalulya at openjdk.java.net  Thu Mar  3 16:13:05 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 3 Mar 2022 16:13:05 GMT
Subject: RFR: 8282619: G1: Fix indentation in
 G1CollectedHeap::mark_evac_failure_object
In-Reply-To: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
References: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
Message-ID: <DWLUlIoenkieHT6Mmp2YkwLnF2QzYQ5egAyjtVWpp2E=.22f719a9-c3a4-4d5a-876b-eecd49ac8cd6@github.com>

On Thu, 3 Mar 2022 15:55:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial fix to indentation in `G1CollectedHeap::mark_evac_failure_object`.
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 16:17:14 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 16:17:14 GMT
Subject: RFR: 8282620: G1/Parallel: Constify is_in_young() predicates
Message-ID: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>

Hi all,

  can I have reviews for this trivial change to further constify `G1Collectedheap/ParallelScavengeHeap::is_in_young()`? Also removes `is_in_old` that does not have a definition.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - const order (2)
 - const order
 - Initial version
 - Initial version

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 16:20:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 16:20:05 GMT
Subject: RFR: 8282619: G1: Fix indentation in
 G1CollectedHeap::mark_evac_failure_object
In-Reply-To: <DWLUlIoenkieHT6Mmp2YkwLnF2QzYQ5egAyjtVWpp2E=.22f719a9-c3a4-4d5a-876b-eecd49ac8cd6@github.com>
References: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
 <DWLUlIoenkieHT6Mmp2YkwLnF2QzYQ5egAyjtVWpp2E=.22f719a9-c3a4-4d5a-876b-eecd49ac8cd6@github.com>
Message-ID: <XMb2bShFK1e2sfbGOqcQ7ztMh8s13HXjy4u4er9SJw4=.7f28d107-a979-4bc8-8867-887edea78db4@github.com>

On Thu, 3 Mar 2022 16:09:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial fix to indentation in `G1CollectedHeap::mark_evac_failure_object`.
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by iwalulya (Reviewer).

Thanks @walulyai @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Mar  3 16:20:06 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 3 Mar 2022 16:20:06 GMT
Subject: Integrated: 8282619: G1: Fix indentation in
 G1CollectedHeap::mark_evac_failure_object
In-Reply-To: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
References: <eGbXpicpSUOj2QLk_4BE5wt14STwSQTxgy48OCvR-S8=.0af49c43-a07d-4022-93ef-d135828fcd32@github.com>
Message-ID: <qsMjcaE7IDExD7UKc1qJeLKPh3hnmnoE5f9rAUE7SVY=.eef7f080-8c12-4d1d-acef-d5b02fee7586@github.com>

On Thu, 3 Mar 2022 15:55:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial fix to indentation in `G1CollectedHeap::mark_evac_failure_object`.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8282619: G1: Fix indentation in G1CollectedHeap::mark_evac_failure_object

Reviewed-by: ayang, iwalulya

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

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


From iwalulya at openjdk.java.net  Thu Mar  3 16:22:04 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 3 Mar 2022 16:22:04 GMT
Subject: RFR: 8282620: G1/Parallel: Constify is_in_young() predicates
In-Reply-To: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
References: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
Message-ID: <UlxHyS1S1jliGEd8f8OPF8RwZxA0F_RWNY3atZ0S55U=.b851799c-b2d4-42a3-b73e-f0fe96a5e6b8@github.com>

On Thu, 3 Mar 2022 16:11:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial change to further constify `G1Collectedheap/ParallelScavengeHeap::is_in_young()`? Also removes `is_in_old` that does not have a definition.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

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


From iwalulya at openjdk.java.net  Fri Mar  4 11:34:26 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 4 Mar 2022 11:34:26 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter
Message-ID: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>

Hi all,

Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.

Testing: Tier 1.

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

Commit messages:
 - hoist parameter independent methods into a base class
 - Remove slote template parameter

Changes: https://git.openjdk.java.net/jdk/pull/7689/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7689&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282621
  Stats: 117 lines in 5 files changed: 47 ins; 31 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7689.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7689/head:pull/7689

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


From tschatzl at openjdk.java.net  Fri Mar  4 13:45:03 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 4 Mar 2022 13:45:03 GMT
Subject: Integrated: 8282615: G1: Fix some includes
In-Reply-To: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
References: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
Message-ID: <zTaS9wn_8PIwq-hi60pkM8oRMarlv3VBfIIwd9fCB9Y=.f9a3d626-0256-4044-b947-8b3d2fe718bd@github.com>

On Thu, 3 Mar 2022 15:49:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this simple change that fixes includes in some G1 files? The most serious is probably the one in `g1CardSetContainers.hpp` which included a `.inline.hpp` file directly.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 52471539
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/52471539c002e38a5c815045913458776381d369
Stats:     4 lines in 4 files changed: 3 ins; 0 del; 1 mod

8282615: G1: Fix some includes

Reviewed-by: ayang, iwalulya

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

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


From tschatzl at openjdk.java.net  Fri Mar  4 13:45:02 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 4 Mar 2022 13:45:02 GMT
Subject: RFR: 8282615: G1: Fix some includes
In-Reply-To: <wePTmtWtaaa4Xoz8z4avg-u3oSmuO6K7i23NluTsKAg=.2a0d3647-33a1-42d5-902a-27a6bfa1c19d@github.com>
References: <i5xAuz6pyfDOPCzFg0dBlRkWGEEDab_fiGXuzCqYpaM=.1bbb0745-3f1c-451d-8e08-25a13e30812d@github.com>
 <wePTmtWtaaa4Xoz8z4avg-u3oSmuO6K7i23NluTsKAg=.2a0d3647-33a1-42d5-902a-27a6bfa1c19d@github.com>
Message-ID: <fp8Xz3m7csbpWMbqK6jNw_KmTqV-sw0h5DSv9C1BYyw=.978f6bc1-9d62-46fd-9431-d5eb49d62f45@github.com>

On Thu, 3 Mar 2022 16:09:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this simple change that fixes includes in some G1 files? The most serious is probably the one in `g1CardSetContainers.hpp` which included a `.inline.hpp` file directly.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by iwalulya (Reviewer).

Thanks @walulyai @albertnetymk for your reviews.

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

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


From kbarrett at openjdk.java.net  Fri Mar  4 19:21:03 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Mar 2022 19:21:03 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter
In-Reply-To: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
Message-ID: <jAII_UARpSkD9EUz3LJlCxVLzaD5J5vT3UufTjXShuM=.cf7c3251-c0b0-41db-a3a5-df17758404ef@github.com>

On Fri, 4 Mar 2022 11:28:14 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
> 
> Testing: Tier 1.

src/hotspot/share/gc/g1/g1CardSetMemory.cpp line 73:

> 71: template <class Slot>
> 72: G1CardSetAllocator<Slot>::G1CardSetAllocator(const char* name,
> 73:                                              const G1CardSetAllocOptions* alloc_options,

There don't seem to be any specializations of this other than `G1CardSetAllocator<G1CardSetContainer>`.  Unless there are future planned specializations it seems like there's no need for the new non-template base class.  Just get rid of the template parameter and directly replace uses of `Slot` with `G1CardSetContainer`.

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

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


From iwalulya at openjdk.java.net  Fri Mar  4 20:13:29 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 4 Mar 2022 20:13:29 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v2]
In-Reply-To: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
Message-ID: <0ra8Kwcq9ez8ggG1n14IZQvO9o7lBH5JRGm4UEz7Q4s=.0870fd9e-816c-4098-8ac1-c74fcae522d3@github.com>

> Hi all,
> 
> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
> 
> Testing: Tier 1.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Kim review: remove template parameter completely

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7689/files
  - new: https://git.openjdk.java.net/jdk/pull/7689/files/49ffecd7..2b51f247

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

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

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


From iwalulya at openjdk.java.net  Fri Mar  4 21:24:37 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 4 Mar 2022 21:24:37 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v3]
In-Reply-To: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
Message-ID: <NnynpfTkFo1QjGbTASEW4gnBWPbuDcz2NQn0EEzqd2c=.677bbd07-023d-4c6d-95a9-cc5e6936d854@github.com>

> Hi all,
> 
> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
> 
> Testing: Tier 1.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Remove G1CardSetContainer type info from the allocator

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7689/files
  - new: https://git.openjdk.java.net/jdk/pull/7689/files/2b51f247..044a15af

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

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

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


From kbarrett at openjdk.java.net  Fri Mar  4 21:45:59 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Mar 2022 21:45:59 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v3]
In-Reply-To: <NnynpfTkFo1QjGbTASEW4gnBWPbuDcz2NQn0EEzqd2c=.677bbd07-023d-4c6d-95a9-cc5e6936d854@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
 <NnynpfTkFo1QjGbTASEW4gnBWPbuDcz2NQn0EEzqd2c=.677bbd07-023d-4c6d-95a9-cc5e6936d854@github.com>
Message-ID: <iGBTBFIAMCNzFhPt_1E21hBaqW-pTNGk_iluvLHIIPI=.74cc87f6-fa42-481a-b7d7-f2d0088ad30f@github.com>

On Fri, 4 Mar 2022 21:24:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
>> 
>> Testing: Tier 1.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove G1CardSetContainer type info from the allocator

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 110:

> 108:   inline size_t wasted_mem_size() const;
> 109: 
> 110:   inline uint num_segments() const;

Do `mem_size` and `wasted_size` need to be inline?  They don't seem like they should be performance critical.  I'm not sure about `num_segments` because I haven't checked uses.

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

> 156: template <MEMFLAGS flag>
> 157: G1SegmentedArray<flag>::G1SegmentedArray(const G1SegmentedArrayAllocOptions* alloc_options,
> 158:                                                G1SegmentedArrayFreeList<flag>* free_segment_list) :

Fix parameter indentation.

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

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


From kbarrett at openjdk.java.net  Fri Mar  4 21:46:00 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 4 Mar 2022 21:46:00 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v2]
In-Reply-To: <0ra8Kwcq9ez8ggG1n14IZQvO9o7lBH5JRGm4UEz7Q4s=.0870fd9e-816c-4098-8ac1-c74fcae522d3@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
 <0ra8Kwcq9ez8ggG1n14IZQvO9o7lBH5JRGm4UEz7Q4s=.0870fd9e-816c-4098-8ac1-c74fcae522d3@github.com>
Message-ID: <bYX9shS7zAAx2XfpnEr2MHHPY0sFImc1UjnD86aOwTc=.127d3eba-7943-4ec6-94db-0f31e34119ab@github.com>

On Fri, 4 Mar 2022 20:13:29 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
>> 
>> Testing: Tier 1.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Kim review: remove template parameter completely

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 181:

> 179:   }
> 180: 
> 181:   ~G1CardSetContainer() = default;

I'd prefer the destructor declaration be close to the constructor, i.e. cluster the special function declarations.

src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 87:

> 85: // own set of allocators, there is intentionally no padding between them to save
> 86: // memory.
> 87: class G1CardSetAllocator {

In the first sentence of the preceding block comment, "(Slot slots)" seems leftover from the template parameter.

src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 96:

> 94:   G1CardSetAllocator(const char* name,
> 95:                          const G1CardSetAllocOptions* alloc_options,
> 96:                          G1CardSetFreeList* free_segment_list);

I think the indentation shouldn't be changed here - the parameters should be aligned.

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

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


From duke at openjdk.java.net  Sat Mar  5 00:32:09 2022
From: duke at openjdk.java.net (duke)
Date: Sat, 5 Mar 2022 00:32:09 GMT
Subject: Withdrawn: 8276887: G1: Move precleaning to Concurrent Mark From Roots
 subphase
In-Reply-To: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
References: <jT-9ZoTHtJg2HbqiKs6nSybaNhQw181IHq8YwJUxI-A=.7b3e48b8-517a-49f9-9104-ea6edea315cf@github.com>
Message-ID: <MLMjDW0tmL6am40USnE7T9TAQ_OdVv4elBS9nV0Jb6Q=.0d935896-565c-4fb0-abb6-0f0a1d239137@github.com>

On Wed, 10 Nov 2021 09:28:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving the "Preclean" subphase into "Mark from roots" subphase so that precleaning becomes parallel automatically. Evaluation using a contrived java program shows that multiple GC threads do precleaning. More detailed testing results are available in the JBS ticket.
> 
> Test: hotspot_gc

This pull request has been closed without being integrated.

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

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


From iwalulya at openjdk.java.net  Sat Mar  5 07:25:46 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Sat, 5 Mar 2022 07:25:46 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v4]
In-Reply-To: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
Message-ID: <kg9rGKf5T-X22-74zrSlBwed0vYGq35wt_-nTRspYJE=.0646ec38-4d43-4910-9a53-675a727a2ce7@github.com>

> Hi all,
> 
> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
> 
> Testing: Tier 1.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  kim review: cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7689/files
  - new: https://git.openjdk.java.net/jdk/pull/7689/files/044a15af..fdb75011

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

  Stats: 63 lines in 4 files changed: 17 ins; 37 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7689.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7689/head:pull/7689

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


From kbarrett at openjdk.java.net  Sat Mar  5 08:56:02 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 5 Mar 2022 08:56:02 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v4]
In-Reply-To: <kg9rGKf5T-X22-74zrSlBwed0vYGq35wt_-nTRspYJE=.0646ec38-4d43-4910-9a53-675a727a2ce7@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
 <kg9rGKf5T-X22-74zrSlBwed0vYGq35wt_-nTRspYJE=.0646ec38-4d43-4910-9a53-675a727a2ce7@github.com>
Message-ID: <0ibz33TbLPJGCFl3wHbW_9oFCJmUUdZn0OeMU8TlKsM=.21307ec1-ee67-4a96-9844-bbacfd3757e5@github.com>

On Sat, 5 Mar 2022 07:25:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
>> 
>> Testing: Tier 1.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kim review: cleanup

Looks good.  Just a minor comment cleanup.

src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 68:

> 66: //
> 67: // Allocation occurs from an internal free list of objects first, if the free list is
> 68: // empty then tries to bump-allocate from the G1SegmentedArray.

I think this would read a bit better if the comma after "first" was changed to a period.  Also suggest changing "bump-allocate" to just "allocate".  Details of how G1SegmentedArray handles allocation should be described there.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar  7 09:12:17 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Mar 2022 09:12:17 GMT
Subject: RFR: 8282728: Remove unused BlockOffsetArray::Action
Message-ID: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>

Simple change of removing dead code.

Test: hotspot_gc

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

Commit messages:
 - bot-action

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

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


From ayang at openjdk.java.net  Mon Mar  7 09:12:37 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Mar 2022 09:12:37 GMT
Subject: RFR: 8282727: Parallel: Remove PSPromotionManager::_totally_drain
Message-ID: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>

Simple change of removing a redundant boolean field.

Test: hotspot_gc

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

Commit messages:
 - pgc-flush

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

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


From ayang at openjdk.java.net  Mon Mar  7 09:25:02 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Mar 2022 09:25:02 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <6MhghRS8-9VQDRVVtluDRKO-d4f5dhgwUog3nVkNIOg=.11cc3a38-c023-433c-82a2-e1c24dad5db4@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>
 <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>
 <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>
 <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>
 <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>
 <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>
 <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>
 <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@github.com>
 <4jUo7n2RZpPa48GqECGWIKvia9v1nzo2mvU
 CtoMLcLY=.838dd8af-d0aa-4045-8cf6-38dd4a0562e0@github.com>
 <6MhghRS8-9VQDRVVtluDRKO-d4f5dhgwUog3nVkNIOg=.11cc3a38-c023-433c-82a2-e1c24dad5db4@github.com>
Message-ID: <049QKT-FX2NE7OApG5DrdfKAFlPzcGVoGto-W2lWyOg=.e5eb4f5e-e52f-48cb-b67d-b103349fd159@github.com>

On Mon, 28 Feb 2022 13:04:39 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Initial version created was having explicit predicate conditions for each test case and was in line to what is being proposed by you. 

Yes, hence my approval. However, I don't feel inclined to approve the current version, because I don't feel confident in maintaining/debugging the test myself, should it fail. If other reviewers are OK with the latest revision, I will not block it either.

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

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


From ayang at openjdk.java.net  Mon Mar  7 09:48:02 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Mar 2022 09:48:02 GMT
Subject: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration
In-Reply-To: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
References: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
Message-ID: <6yqHgw4yYy5L15Ag7jMF-lheZ6aN5V1Amkf9y4D-XFA=.b09e2b72-1fbc-4844-85f9-ea28a8406b85@github.com>

On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc.
> 
> Test: tier1-6

Could someone from serviceability also take a look?

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

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


From tschatzl at openjdk.java.net  Mon Mar  7 10:10:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 7 Mar 2022 10:10:05 GMT
Subject: RFR: 8282728: Serial: Remove unused BlockOffsetArray::Action
In-Reply-To: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>
References: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>
Message-ID: <6R2FsCWqhIP10dVPjxuCp9PTcN2eeur_keqiT1MQgrU=.7b50ba0a-2b9c-48d8-afc4-89d2720b29cf@github.com>

On Mon, 7 Mar 2022 08:58:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Lgtm and trivial

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar  7 10:55:07 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Mar 2022 10:55:07 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v11]
In-Reply-To: <-05U76-qUQdzA2vDJyBHTuYwwkTrRUS96a38ui8tmVI=.f04949ec-4680-4161-93bb-85a95eaf47c9@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <-05U76-qUQdzA2vDJyBHTuYwwkTrRUS96a38ui8tmVI=.f04949ec-4680-4161-93bb-85a95eaf47c9@github.com>
Message-ID: <9jtvLdwn8tVdUg4AIUT9nsKiUNc9h86fFDPBCGBm13A=.410418c2-82b0-4d45-88d3-a93d856430fe@github.com>

On Wed, 2 Mar 2022 14:28:51 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move 'chunks per region' log

Some minor comments/suggestions.

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

> 161:     RegionMarkedWordsCache():
> 162:       _g1h(G1CollectedHeap::heap()),
> 163:       _region_idx(_g1h->max_regions()),

I think `_g1h->max_regions()` should be captured in a field named sth like `uninitialized_idx` or `invalid_idx` to make the intend clearer.

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

> 171:         _marked_words += marked_words;
> 172:       } else {
> 173:         _g1h->region_at(_region_idx)->note_self_forwarding_removal_end_par(_marked_words * BytesPerWord);

The `note_self_forwarding_removal_end_par` calls can be placed in a method to avoid some duplication.

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

> 39:   _max_regions(0),
> 40:   _heap(G1CollectedHeap::heap()),
> 41:   _phase_times(_heap->phase_times()) {

I don't really see where this field is used.

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

> 74:   uint max_regions() const {
> 75:     return _max_regions;
> 76:   }

Looking at how this field is used:

1. `region_idx < _max_regions`; can be caught the underlying bitmap
2.  `_max_regions = 0; // To have any record() attempt fail...`; can be replaced by a null-check of `_evac_failure_regions`.

This issue is preexisting though.

src/hotspot/share/gc/g1/g1HeapRegionChunk.hpp line 69:

> 67:   bool include_first_obj_in_region() const { return _include_first_obj_in_region; }
> 68: 
> 69:   bool include_last_obj_in_region() const { return _include_last_obj_in_region; }

Seems unused.

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

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


From shade at openjdk.java.net  Mon Mar  7 11:06:04 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Mar 2022 11:06:04 GMT
Subject: RFR: 8281254: GCs with survivor spaces report Init > Max through
 MXBeans
In-Reply-To: <zNb-yl2UB34eO3zORuUqw2eYfW0Jg-LS5LPSmMQ70LY=.1898dfb2-0e35-483e-930a-5f38696d3ca5@github.com>
References: <zNb-yl2UB34eO3zORuUqw2eYfW0Jg-LS5LPSmMQ70LY=.1898dfb2-0e35-483e-930a-5f38696d3ca5@github.com>
Message-ID: <UH0MdJul6Wzw82FSWL8kNUQ-XCwKIYkiFSNTGYvvfIA=.efd6ab1f-5063-4408-9f5f-f711fefef2c6@github.com>

On Fri, 4 Feb 2022 09:02:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the discussion in the bug. This realistically affects only Serial and Parallel. My first attempt was to push through `initial_size` to generations properly, but it is too intrusive to my liking. The current patch "just" caps the initial to max.
> 
> Additional testing:
>  - [x] New regression test now passes on all GCs
>  - [x] Linux x86_64 `hotspot:tier1`

Not yet, bot.

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

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


From tschatzl at openjdk.java.net  Mon Mar  7 12:12:11 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 7 Mar 2022 12:12:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v11]
In-Reply-To: <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@github.com>
Message-ID: <qPnx61jc40TVADIZZYu5lBtMMP_gHREA1gKZW6Hs6J4=.d35a0ad2-502a-48aa-b613-6a808ea7de79@github.com>

On Mon, 28 Feb 2022 13:08:34 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Resolved the comments.

Please drop the test.

The test is not able to distinguish failures from problems with the VM logic and other processes spuriously allocating enough large pages to make this test fail afaict. That's just a too annoying failure to debug. We can look into the test in a separate CR.

I kept the other comments I had for reference.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 30:

> 28:  * @summary Use largest available large page size smaller than LargePageSizeInBytes when available.
> 29:  * @requires os.family == "linux"
> 30:  * @requires vm.gc != "Z"

Add a `requires vm.bits == 64` here - it is unlikely that any VM with 2g+ heap can be started on a 32 bit machine.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 62:

> 60:     private static int[] pageCount = new int[MAX_NUMBER_OF_PAGESIZE];
> 61:     private static int largestPageSizeIndex;
> 62:     private static int vmPageSizeIndex;

As others suggested already, all the management and handling of configured page sizes using bit index is very complicated. Please use a simple array of sizes.
This also allows the use of existing query/sort method(s) if needed instead of rolling your own (i.e. the for-loops).

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 74:

> 72:            System.out.println("Exception " + e);
> 73:         }
> 74:     }

Just let the main method throw the exception - it is printed by default anyway.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 76:

> 74:     }
> 75: 
> 76:     private static long requiredPageCount(int index) {

Add documentation of what this (and any other non-obvious) method actually calculates.

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 169:

> 167:                     // Only consider this a test failure if there are enough configured
> 168:                     // pages to allow this reservation to succeeded.
> 169:                     if (requiredPageCount(i) <= pageCount[i]) {

Aren't we going to get false positives if another test run concurrently allocates away all large pages?

test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 178:

> 176:         }
> 177: 
> 178:         if (errorMessage != "") {

`errorMessage` seems to be never assigned to - this code seems to be dead. Remove.

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

Changes requested by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar  7 12:53:03 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Mar 2022 12:53:03 GMT
Subject: RFR: 8282620: G1/Parallel: Constify is_in_young() predicates
In-Reply-To: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
References: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
Message-ID: <Jy4E4SqC_isnUqTgjA-Dr5lYId0zF9TbOsHfFU54Q7o=.d330d8dc-7b5d-4b6a-8f8d-f9571e49b4e0@github.com>

On Thu, 3 Mar 2022 16:11:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial change to further constify `G1Collectedheap/ParallelScavengeHeap::is_in_young()`? Also removes `is_in_old` that does not have a definition.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Mon Mar  7 13:56:24 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 7 Mar 2022 13:56:24 GMT
Subject: RFR: 8282620: G1/Parallel: Constify is_in_young() predicates
In-Reply-To: <Jy4E4SqC_isnUqTgjA-Dr5lYId0zF9TbOsHfFU54Q7o=.d330d8dc-7b5d-4b6a-8f8d-f9571e49b4e0@github.com>
References: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
 <Jy4E4SqC_isnUqTgjA-Dr5lYId0zF9TbOsHfFU54Q7o=.d330d8dc-7b5d-4b6a-8f8d-f9571e49b4e0@github.com>
Message-ID: <DA7MAARjv6WVAIAvqy16CovR2_mYlWPY7rIBkT7vIIA=.3373f224-b36e-4fc9-9562-fb5e1311b7dc@github.com>

On Mon, 7 Mar 2022 12:49:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this trivial change to further constify `G1Collectedheap/ParallelScavengeHeap::is_in_young()`? Also removes `is_in_old` that does not have a definition.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @walulyai for your reviews

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

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


From tschatzl at openjdk.java.net  Mon Mar  7 13:56:25 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 7 Mar 2022 13:56:25 GMT
Subject: Integrated: 8282620: G1/Parallel: Constify is_in_young() predicates
In-Reply-To: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
References: <1ZBY0dmg5vd3UK2oCIHgGjG5MYOg8eRMEnE8RyUn3VM=.2aa8d56e-1938-4d3b-9a03-2407f740523d@github.com>
Message-ID: <eQy9kG7qWTYA-HZsf_v_5cOXMD29xOqjJKygKNr4ESs=.463befcd-cb2a-4100-ba1f-25b551fc65fa@github.com>

On Thu, 3 Mar 2022 16:11:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this trivial change to further constify `G1Collectedheap/ParallelScavengeHeap::is_in_young()`? Also removes `is_in_old` that does not have a definition.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 6fc73f70
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6fc73f709ba9a7f4810027f6c888b63a4604f004
Stats:     5 lines in 4 files changed: 0 ins; 1 del; 4 mod

8282620: G1/Parallel: Constify is_in_young() predicates

Reviewed-by: iwalulya, ayang

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

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


From tschatzl at openjdk.java.net  Mon Mar  7 14:03:13 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 7 Mar 2022 14:03:13 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v4]
In-Reply-To: <kg9rGKf5T-X22-74zrSlBwed0vYGq35wt_-nTRspYJE=.0646ec38-4d43-4910-9a53-675a727a2ce7@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
 <kg9rGKf5T-X22-74zrSlBwed0vYGq35wt_-nTRspYJE=.0646ec38-4d43-4910-9a53-675a727a2ce7@github.com>
Message-ID: <lKgaqQjeNphkP8ek4XktS7mS9BYLnxO76m0lzRvVBv4=.6221bd62-665e-4f2e-be9a-224d3cbdba82@github.com>

On Sat, 5 Mar 2022 07:25:46 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
>> 
>> Testing: Tier 1.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kim review: cleanup

Lgtm apart from that minor indentation issue.

src/hotspot/share/gc/g1/g1CardSetMemory.cpp line 60:

> 58:   return  sizeof(*this) +
> 59:           _segmented_array.num_segments() * sizeof(G1CardSetSegment) +
> 60:           _segmented_array.num_available_slots() * _segmented_array.slot_size();

one space too much after the `return`.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Mon Mar  7 14:22:32 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 7 Mar 2022 14:22:32 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v5]
In-Reply-To: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
Message-ID: <jfCxmU8yQ6ufyJAcIQmkMQJrNyzyvIzdxr0PJ_fcdKA=.8d720886-3dc7-4cfd-ac70-d95bb37a8c43@github.com>

> Hi all,
> 
> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
> 
> Testing: Tier 1.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Kim and Thomas reviews

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7689/files
  - new: https://git.openjdk.java.net/jdk/pull/7689/files/fdb75011..067482ec

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

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

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


From iwalulya at openjdk.java.net  Mon Mar  7 15:09:10 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 7 Mar 2022 15:09:10 GMT
Subject: RFR: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter [v4]
In-Reply-To: <0ibz33TbLPJGCFl3wHbW_9oFCJmUUdZn0OeMU8TlKsM=.21307ec1-ee67-4a96-9844-bbacfd3757e5@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
 <kg9rGKf5T-X22-74zrSlBwed0vYGq35wt_-nTRspYJE=.0646ec38-4d43-4910-9a53-675a727a2ce7@github.com>
 <0ibz33TbLPJGCFl3wHbW_9oFCJmUUdZn0OeMU8TlKsM=.21307ec1-ee67-4a96-9844-bbacfd3757e5@github.com>
Message-ID: <zPunLsJ7Nr6PS5ZKzbZ_2rH7KjQrnwEz3nfTVz85Mvs=.2be6320e-4f05-4b38-bb9d-670d31e0c265@github.com>

On Sat, 5 Mar 2022 08:52:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kim review: cleanup
>
> Looks good.  Just a minor comment cleanup.

Thanks @kimbarrett and @tschatzl for the reviews.

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

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


From iwalulya at openjdk.java.net  Mon Mar  7 15:09:11 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 7 Mar 2022 15:09:11 GMT
Subject: Integrated: 8282621: G1: G1SegmentedArray remove unnecessary template
 parameter
In-Reply-To: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
References: <vL8XVRjRrVHuNStOekZD7JodX10yXpvTqSmWQELuWl0=.56324bfc-e205-40e5-81d3-0c9f1267ef57@github.com>
Message-ID: <NM5DzcBa_u18zcVCTqHb3iQjOZBZ4PUfv8xYozYWYto=.1b0fe2df-b317-48f1-b868-726e5a451375@github.com>

On Fri, 4 Mar 2022 11:28:14 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this refactoring change to remove unnecessary template parameters. The change has two commits, one to remove the template parameter, this allows for the second clean up to hoist `G1CardSetAllocator` parameter independent methods and variables into a base class.
> 
> Testing: Tier 1.

This pull request has now been integrated.

Changeset: e544e354
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e544e354a425a242f23cee1049d6ba31b30740e0
Stats:     115 lines in 5 files changed: 18 ins; 45 del; 52 mod

8282621: G1: G1SegmentedArray remove unnecessary template parameter

Reviewed-by: kbarrett, tschatzl

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

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


From ayang at openjdk.java.net  Tue Mar  8 08:28:07 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 8 Mar 2022 08:28:07 GMT
Subject: RFR: 8282728: Serial: Remove unused BlockOffsetArray::Action
In-Reply-To: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>
References: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>
Message-ID: <DxxiemFpOioiJ-F9xCIb8U3pOnR8wzbpoUbxnq8uIO4=.8bc801c6-7a6d-4df5-9823-e2b4e43a7504@github.com>

On Mon, 7 Mar 2022 08:58:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Mar  8 08:28:07 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 8 Mar 2022 08:28:07 GMT
Subject: Integrated: 8282728: Serial: Remove unused BlockOffsetArray::Action
In-Reply-To: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>
References: <j11ZWMRCvNcaTZ6xKyV2WfeqSCwfh_-Tdb3llA_ZoUs=.467967da-3ca3-4f42-952c-cc929b574624@github.com>
Message-ID: <iMRQk24avdJffqZ-xsuNdDU0hskt5400MYjTzaHo7J0=.e37af8de-253a-4bf5-9523-3ee4fb33cf3b@github.com>

On Mon, 7 Mar 2022 08:58:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

This pull request has now been integrated.

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

8282728: Serial: Remove unused BlockOffsetArray::Action

Reviewed-by: tschatzl

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

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


From iwalulya at openjdk.java.net  Tue Mar  8 12:04:29 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 8 Mar 2022 12:04:29 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list details.
Message-ID: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>

Hi all,

Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.

Testing: tier 1

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

Commit messages:
 - space
 - initial

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

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


From tschatzl at openjdk.java.net  Tue Mar  8 21:22:09 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 8 Mar 2022 21:22:09 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details.
In-Reply-To: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
Message-ID: <vrWT2ZnwUICu_fuYtipe4QAll0MnBaGjnZ1aYDVt9n0=.d88210f4-fcde-4172-b96c-b7d4bf0a2b28@github.com>

On Tue, 8 Mar 2022 11:57:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
> 
> Testing: tier 1

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From kbarrett at openjdk.java.net  Wed Mar  9 20:38:45 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Mar 2022 20:38:45 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details.
In-Reply-To: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
Message-ID: <U6YSjkRLAr8C4dqqRpr2DJSj29YVneFdBB4QHMO9G6g=.2d285a3a-c581-4035-94c4-21c94fbfa632@github.com>

On Tue, 8 Mar 2022 11:57:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
> 
> Testing: tier 1

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 32:

> 30: #include "memory/allocation.hpp"
> 31: #include "runtime/atomic.hpp"
> 32: #include "runtime/thread.hpp"

It's not clear why some of these #includes are here.  log, thread, spinYield all seem unused in this .hpp.

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

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


From iwalulya at openjdk.java.net  Wed Mar  9 21:52:27 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 9 Mar 2022 21:52:27 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v2]
In-Reply-To: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
Message-ID: <uUTQR6HNxk9B-PqV7VsbnLHa5I055akMpCx-q1_-An4=.b43ff2e9-ec13-4da6-8de4-442a23ed2b3d@github.com>

> Hi all,
> 
> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
> 
> Testing: tier 1

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  cleanup includes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7743/files
  - new: https://git.openjdk.java.net/jdk/pull/7743/files/804e1558..cf1ea626

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

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

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


From kbarrett at openjdk.java.net  Thu Mar 10 14:44:46 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 10 Mar 2022 14:44:46 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v2]
In-Reply-To: <uUTQR6HNxk9B-PqV7VsbnLHa5I055akMpCx-q1_-An4=.b43ff2e9-ec13-4da6-8de4-442a23ed2b3d@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
 <uUTQR6HNxk9B-PqV7VsbnLHa5I055akMpCx-q1_-An4=.b43ff2e9-ec13-4da6-8de4-442a23ed2b3d@github.com>
Message-ID: <zFC8N4HruiMR3uKrZehtzucJdrJ4AkR6i0a9BYjPeMk=.7239b54a-5f50-4f74-84ff-778df0fb2c75@github.com>

On Wed, 9 Mar 2022 21:52:27 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
>> 
>> Testing: tier 1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup includes

Looks good.  Just an include nit.

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 29:

> 27: 
> 28: #include "gc/g1/g1CardSet.hpp"
> 29: #include "memory/allocation.hpp"

allocation.hpp is used here - StackObj.  (We really ought to move that into it's own file, as was done for AllStatic.  It's a bit more complicated because of AllocatedObj.)  Presumably it's being picked up indirectly, but "include what you use".  (Hm, I thought that was in the style guide.  But not there yet - JDK-8252896.)

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

Marked as reviewed by kbarrett (Reviewer).

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


From iwalulya at openjdk.java.net  Thu Mar 10 14:49:17 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 10 Mar 2022 14:49:17 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v3]
In-Reply-To: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
Message-ID: <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>

> Hi all,
> 
> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
> 
> Testing: tier 1

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  fix includes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7743/files
  - new: https://git.openjdk.java.net/jdk/pull/7743/files/cf1ea626..773ebdca

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

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

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


From iwalulya at openjdk.java.net  Thu Mar 10 14:49:20 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 10 Mar 2022 14:49:20 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v3]
In-Reply-To: <zFC8N4HruiMR3uKrZehtzucJdrJ4AkR6i0a9BYjPeMk=.7239b54a-5f50-4f74-84ff-778df0fb2c75@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
 <uUTQR6HNxk9B-PqV7VsbnLHa5I055akMpCx-q1_-An4=.b43ff2e9-ec13-4da6-8de4-442a23ed2b3d@github.com>
 <zFC8N4HruiMR3uKrZehtzucJdrJ4AkR6i0a9BYjPeMk=.7239b54a-5f50-4f74-84ff-778df0fb2c75@github.com>
Message-ID: <OXsj6lGs5mCON_ubjZU8EXqfsO8k-1SFPGmfvLrgIfQ=.698c11f0-73cf-4be7-8c9f-48523166b6ac@github.com>

On Thu, 10 Mar 2022 14:40:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix includes
>
> src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 29:
> 
>> 27: 
>> 28: #include "gc/g1/g1CardSet.hpp"
>> 29: #include "logging/log.hpp"
> 
> allocation.hpp is used here - StackObj.  (We really ought to move that into it's own file, as was done for AllStatic.  It's a bit more complicated because of AllocatedObj.)  Presumably it's being picked up indirectly, but "include what you use".  (Hm, I thought that was in the style guide.  But not there yet - JDK-8252896.)

Thanks @kimbarrett I missed that

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

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


From ayang at openjdk.java.net  Thu Mar 10 16:23:43 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 10 Mar 2022 16:23:43 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v3]
In-Reply-To: <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
 <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>
Message-ID: <nntDVhBiGjX8IZdrhme3VDTn_U4WH9VwMEiFEtPF8sA=.976c7d34-36ae-493f-828a-7aeaad716edb@github.com>

On Thu, 10 Mar 2022 14:49:17 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
>> 
>> Testing: tier 1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix includes

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 146:

> 144:   uintptr_t _ref_count;
> 145: protected:
> 146:   ~G1CardSetContainer() = default;

I think the destructor can be omitted completely.

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

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


From kbarrett at openjdk.java.net  Thu Mar 10 17:22:45 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 10 Mar 2022 17:22:45 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v3]
In-Reply-To: <nntDVhBiGjX8IZdrhme3VDTn_U4WH9VwMEiFEtPF8sA=.976c7d34-36ae-493f-828a-7aeaad716edb@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
 <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>
 <nntDVhBiGjX8IZdrhme3VDTn_U4WH9VwMEiFEtPF8sA=.976c7d34-36ae-493f-828a-7aeaad716edb@github.com>
Message-ID: <fbCz4RrrcAcz9eqSw9ep1wGDryKKiYLuaZylTzMf0YE=.174d466d-a0ed-4591-83fe-b6859a756a4b@github.com>

On Thu, 10 Mar 2022 16:20:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix includes
>
> src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 146:
> 
>> 144:   uintptr_t _ref_count;
>> 145: protected:
>> 146:   ~G1CardSetContainer() = default;
> 
> I think the destructor can be omitted completely.

Omitting this destructor declaration would make the destructor implicitly public, which would make accidental slicing possible.

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

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


From ayang at openjdk.java.net  Thu Mar 10 22:20:39 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 10 Mar 2022 22:20:39 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v3]
In-Reply-To: <fbCz4RrrcAcz9eqSw9ep1wGDryKKiYLuaZylTzMf0YE=.174d466d-a0ed-4591-83fe-b6859a756a4b@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
 <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>
 <nntDVhBiGjX8IZdrhme3VDTn_U4WH9VwMEiFEtPF8sA=.976c7d34-36ae-493f-828a-7aeaad716edb@github.com>
 <fbCz4RrrcAcz9eqSw9ep1wGDryKKiYLuaZylTzMf0YE=.174d466d-a0ed-4591-83fe-b6859a756a4b@github.com>
Message-ID: <yUtYpUYKWZ0tuWhrei_S0wblHsmyziromnNMldkSuD4=.8aeb6f0f-890a-4b19-823d-6e253f2bf409@github.com>

On Thu, 10 Mar 2022 17:19:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 146:
>> 
>>> 144:   uintptr_t _ref_count;
>>> 145: protected:
>>> 146:   ~G1CardSetContainer() = default;
>> 
>> I think the destructor can be omitted completely.
>
> Omitting this destructor declaration would make the destructor implicitly public, which would make accidental slicing possible.

Got it; TIL: "The destructor for a base class should be public and virtual or non-public and non-virtual."

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

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


From iwalulya at openjdk.java.net  Fri Mar 11 08:46:45 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 11 Mar 2022 08:46:45 GMT
Subject: RFR: 8282763: G1: G1CardSetContainer remove intrusive-list
 details. [v3]
In-Reply-To: <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
 <frOtRuahOAiDhMfcFjR9R-DQR7YnzpqciyJVEAEUXk8=.f7bdfc9c-bb69-4f58-9784-1541f720cb33@github.com>
Message-ID: <8whj07_E68ufvaO84U7ZR1EWnfCXI2rhrFj-dhDUHBc=.1e2cdae1-f0b6-4d66-9a9d-45559e1c7c32@github.com>

On Thu, 10 Mar 2022 14:49:17 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
>> 
>> Testing: tier 1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix includes

Thanks for the reviews!

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

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


From iwalulya at openjdk.java.net  Fri Mar 11 08:46:45 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 11 Mar 2022 08:46:45 GMT
Subject: Integrated: 8282763: G1: G1CardSetContainer remove intrusive-list
 details.
In-Reply-To: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
References: <JSsUhP-iS5_86rqu-WxYVZJgcWuSS-OuY7amED3UuCo=.e1370e64-fd12-4538-b68e-aff372c6bd73@github.com>
Message-ID: <Bj_uE8234ZZRlwrKV5JsBqpqjtg_c7RWZZMCjtZIvwU=.cb3f0461-8787-45d6-ae40-b48aba0ad8cb@github.com>

On Tue, 8 Mar 2022 11:57:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this trivial cleanup to remove unnecessary G1CardSetContainer list details.
> 
> Testing: tier 1

This pull request has now been integrated.

Changeset: 1a5a496a
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a5a496aee0f4c33cb67b0853bbf23313fd6ec7d
Stats:     27 lines in 2 files changed: 1 ins; 23 del; 3 mod

8282763: G1: G1CardSetContainer remove intrusive-list details.

Reviewed-by: tschatzl, kbarrett, ayang

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

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


From mli at openjdk.java.net  Fri Mar 11 12:33:42 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 11 Mar 2022 12:33:42 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v11]
In-Reply-To: <9jtvLdwn8tVdUg4AIUT9nsKiUNc9h86fFDPBCGBm13A=.410418c2-82b0-4d45-88d3-a93d856430fe@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <-05U76-qUQdzA2vDJyBHTuYwwkTrRUS96a38ui8tmVI=.f04949ec-4680-4161-93bb-85a95eaf47c9@github.com>
 <9jtvLdwn8tVdUg4AIUT9nsKiUNc9h86fFDPBCGBm13A=.410418c2-82b0-4d45-88d3-a93d856430fe@github.com>
Message-ID: <c7uJ8U_w34FjoIihPr80zYbY0RoEya4F2YNYNB0Wd5I=.68ea9e41-16fb-4c47-a99d-76c8e12c6cba@github.com>

On Mon, 7 Mar 2022 10:13:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move 'chunks per region' log
>
> src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp line 76:
> 
>> 74:   uint max_regions() const {
>> 75:     return _max_regions;
>> 76:   }
> 
> Looking at how this field is used:
> 
> 1. `region_idx < _max_regions`; can be caught the underlying bitmap
> 2.  `_max_regions = 0; // To have any record() attempt fail...`; can be replaced by a null-check of `_evac_failure_regions`.
> 
> This issue is preexisting though.

Thanks for the detailed review, sorry for the delayed response.

Nice catch! And I think the second one can also be caught by the underlying bitmap.
I will update the patch later.

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

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


From mli at openjdk.java.net  Fri Mar 11 14:28:22 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 11 Mar 2022 14:28:22 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v12]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <P5IZSwrTuMkBnqJYXlXJu2_DqHvSH9QNv4ukFhEwPtE=.2f7f979a-8b65-4a38-85e0-21d98f2076d8@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Albert review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/2ec162c9..ead76594

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=10-11

  Stats: 35 lines in 6 files changed: 6 ins; 21 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From duke at openjdk.java.net  Fri Mar 11 14:36:44 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 11 Mar 2022 14:36:44 GMT
Subject: Withdrawn: 8256265 G1: Improve parallelism in regions that failed
 evacuation
In-Reply-To: <pgOskFPQeIhWfIqQJYz1YnJXeoEgWpOQI9dYr1jdN9Y=.af95d8b5-d9ef-4ddc-80ec-dc361d33ba33@github.com>
References: <pgOskFPQeIhWfIqQJYz1YnJXeoEgWpOQI9dYr1jdN9Y=.af95d8b5-d9ef-4ddc-80ec-dc361d33ba33@github.com>
Message-ID: <f9I6qpgFF4i03zIN80iuPtHWTlmYt4f9q_iV9IewCXU=.8916c3c0-060a-41e6-86ab-edf0c35d470d@github.com>

On Wed, 1 Dec 2021 07:57:51 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Summary
> -------
> 
> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> Try to improve the parallelsim when walking over the regions by 
> 
>  - first, split a region into tasks;
>  - then, process these task in parallel and load balance among GC threads;
>  - last, necessary cleanup
> 
> NOTE: load balance part of code is almost same as G1ParScanThreadState, if necessary and feasible, consider to refactor this part into a shared code base.
> 
> Performance Test
> -------
> 
> The perf test based on lastest implementation + JDK-8277736 shows that:
> 
>  - when `ParallelGCThreads`=32, when `G1EvacuationFailureALotCSetPercent` <= 50, the parallelism bring more benefit than regression;
> - when `ParallelGCThreads`=128, whatever `G1EvacuationFailureALotCSetPercent` is, the parallelism bring more benefit than regression;
> 
> other related evac failure vm options:
>  - `G1EvacuationFailureALotInterval`=1
>  - `G1EvacuationFailureALotCount`=1
> 
> For detailed perf test result, please check:
> 
>  - https://bugs.openjdk.java.net/secure/attachment/97227/parallel.evac.failure-threads.32.png
>  - https://bugs.openjdk.java.net/secure/attachment/97228/parallel.evac.failure-threads.128.png
>  
> For the situation like G1EvacuationFailureALotCSetPercent > 50 and ParallelGCThreads=32 , we could fall back to current implmentation, or further optimize the thread sizing at this phase if necessary.
> 
> NOTE: I don't include perf data for `Remove Self Forwards`, because the comparison of pause time in this phase does not well show the improvement of this implementation, I think the reason is that the original implementation is not load balanced, and the new implementation is. But as `Remove Self Forwards` is part of `Post Evacuate Cleanup 1`, so only `Post Evacuate Cleanup 1` well show the improvement of the new implementation.
> It could be a potential improvement to refine the Pause time data in `Remove Self Forwards` phase.

This pull request has been closed without being integrated.

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

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


From duke at openjdk.java.net  Fri Mar 11 17:32:41 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 11 Mar 2022 17:32:41 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v12]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <J47VeZ4pNtiXaeKemmUb5p7oN3-2wPAx_vtmLeThncU=.9493cbc0-71f2-4b38-950e-39d983fc7c78@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Review comments resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/ea081a1b..30453b3f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=10-11

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

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


From duke at openjdk.java.net  Fri Mar 11 17:42:51 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 11 Mar 2022 17:42:51 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v11]
In-Reply-To: <qPnx61jc40TVADIZZYu5lBtMMP_gHREA1gKZW6Hs6J4=.d35a0ad2-502a-48aa-b613-6a808ea7de79@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@github.com>
 <qPnx61jc40TVADIZZYu5lBtMMP_gHREA1gKZW6Hs6J4=.d35a0ad2-502a-48aa-b613-6a808ea7de79@github.com>
Message-ID: <hjYI7y_VUR2umpkplfe7h4c0VYKCU0m1rgA7GKv15vA=.cc468b75-ad82-462f-83d3-c87f38b545af@github.com>

On Mon, 7 Mar 2022 12:08:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271195: Resolved the comments.
>
> Please drop the test.
> 
> The test is not able to distinguish failures from problems with the VM logic and other processes spuriously allocating enough large pages to make this test fail afaict. That's just a too annoying failure to debug. We can look into the test in a separate CR.
> 
> I kept the other comments I had for reference.

Hello @tschatzl,

All your comments have been incorporated, and also created a minimal test case as per @albertnetymk suggestion to test a point scenario.
Please suggest if the test changes looks good or should we add the below point test case.

Thanks,
Swati

------------------------------------------------------------------------------------------------
/*
 * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

package runtime.os;

/* @test
 * @bug 8271195
 * @summary Use largest available large page size smaller than LargePageSizeInBytes when available.
 * @requires os.family == "linux"
 * @requires os.arch == "amd64" | os.arch == "x86_64"
 * @requires vm.bits == 64
 * @requires vm.gc != "Z"
 * @library /test/lib
 * @run main/othervm runtime.os.TestExplicitPageAllocation
 */

import jdk.test.lib.process.ProcessTools;
import jdk.test.lib.process.OutputAnalyzer;
import jdk.test.lib.Utils;
import java.util.regex.Pattern;
import java.util.regex.Matcher;
import java.util.List;
import java.io.*;
import java.util.Scanner;

public class TestExplicitPageAllocation {

    private static final String HUGE_PAGES_1G = "/sys/kernel/mm/hugepages/hugepages-1048576kB/free_hugepages";
    private static final String HUGE_PAGES_2M = "/sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages";
    private static final int HEAP_SIZE_IN_KB = 2 * 1024 * 1024;
    private static final int CODE_CACHE_SIZE_IN_KB = 256 * 1024;
    private static final Pattern HEAP_PATTERN = Pattern.compile("Heap:");
    private static final Pattern PAGE_SIZE_PATTERN = Pattern.compile(".*page_size=([^ ]+).*");
    private static final Pattern HUGEPAGE_PATTERN = Pattern.compile(".*hugepages-([^ ]+).*kB");

    public static void main(String args[]) throws Exception {
        int pageCount1G = -1, pageCount2M = -1;
        try {
            pageCount1G = readPageCount(HUGE_PAGES_1G, "1G");
            pageCount2M = readPageCount(HUGE_PAGES_2M, "2M");
        } catch (Exception e) {
            System.out.println("Setup Exception " + e);
        }
        if (pageCount1G < 2 && pageCount2M >= ((HEAP_SIZE_IN_KB + CODE_CACHE_SIZE_IN_KB) / (2 * 1024))) {
            testCase();
        }
    }

    public static int readPageCount(String filename, String pageSize) throws Exception {
        BufferedReader d = new BufferedReader(new FileReader(filename));
        int pageCount = Integer.parseInt(d.readLine());
        if (pageCount == 0) {
            System.out.println("No pages configured for " + pageSize);
        }
        return pageCount;
    }

    private static boolean checkOutput(OutputAnalyzer out, String pageSize) {
        List<String> lines = out.asLines();
        for (int i = 0; i < lines.size(); ++i) {
            String line = lines.get(i);
            System.out.println(line);
            if (HEAP_PATTERN.matcher(line).find()) {
                Matcher trace = PAGE_SIZE_PATTERN.matcher(line);
                trace.find();
                String tracePageSize = trace.group(1);
                if (pageSize.equals(tracePageSize)) {
                    return true;
                }
            }
        }
        return false;
    }

    public static void testCase() throws Exception {
        ProcessBuilder pb = ProcessTools.createJavaProcessBuilder("-Xlog:pagesize",
                                                                  "-XX:ReservedCodeCacheSize=" + CODE_CACHE_SIZE_IN_KB + "k",
                                                                  "-XX:InitialCodeCacheSize=160k",
                                                                  "-XX:LargePageSizeInBytes=1g",
                                                                  "-XX:+UseParallelGC",
                                                                  "-XX:+UseLargePages",
                                                                  "-Xmx" + HEAP_SIZE_IN_KB + "k",
                                                                  "-Xms" + HEAP_SIZE_IN_KB + "k",
                                                                  "-version");
        OutputAnalyzer output = new OutputAnalyzer(pb.start());
        output.shouldHaveExitValue(0);
        if (checkOutput(output, "2M")) {
            System.out.println("TestCase Passed for pagesize: 1G, allocated pagesize: 2M");
        } else {
            throw new AssertionError("TestCase Failed for 2M page allocation");
        }
    }
}

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

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


From tschatzl at openjdk.java.net  Mon Mar 14 11:06:46 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 14 Mar 2022 11:06:46 GMT
Subject: RFR: 8282727: Parallel: Remove PSPromotionManager::_totally_drain
In-Reply-To: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
References: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
Message-ID: <eu1Br1txHI6LNbc1BeG8xi29caP6AXcU06OzmqfHx5s=.f48f64bd-7726-4428-a66c-fd893a701e29@github.com>

On Mon, 7 Mar 2022 08:55:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant boolean field.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar 14 11:17:25 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 14 Mar 2022 11:17:25 GMT
Subject: RFR: 8283097: Parallel: Move filler object logic inside
 PSPromotionLAB::unallocate_object
Message-ID: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>

Simple cleanup in the unallocation path in `PSPromotionManager::copy_unmarked_to_survivor_space`.

Test: hotspot_gc

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

Commit messages:
 - ps-unalloc

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

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


From tschatzl at openjdk.java.net  Mon Mar 14 13:49:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 14 Mar 2022 13:49:42 GMT
Subject: RFR: 8283097: Parallel: Move filler object logic inside
 PSPromotionLAB::unallocate_object
In-Reply-To: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
References: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
Message-ID: <lISKhhyN2Cwa54YWYNaUI-3_lqsPjUIDL2DTteEyaiA=.7ded182a-8637-44c8-9522-6ffaaa94e679@github.com>

On Mon, 14 Mar 2022 11:11:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup in the unallocation path in `PSPromotionManager::copy_unmarked_to_survivor_space`.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Tue Mar 15 11:07:51 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 15 Mar 2022 11:07:51 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v11]
In-Reply-To: <qPnx61jc40TVADIZZYu5lBtMMP_gHREA1gKZW6Hs6J4=.d35a0ad2-502a-48aa-b613-6a808ea7de79@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@github.com>
 <qPnx61jc40TVADIZZYu5lBtMMP_gHREA1gKZW6Hs6J4=.d35a0ad2-502a-48aa-b613-6a808ea7de79@github.com>
Message-ID: <jxxR2n5sn7XU8Go5v1u10JIVlshjx0CgfmGiRevZFC8=.c0ef7077-a9b7-43f6-80ad-395f644a927a@github.com>

On Mon, 7 Mar 2022 12:08:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The test is not able to distinguish failures from problems with the VM logic and other processes spuriously allocating enough large pages to make this test fail afaict.

I don't see any easy way fixing this and including this test in CI can cause undesirable false-positives.

> also created a minimal test case as per @albertnetymk suggestion to test a point scenario.

I personally like the minimal test case you posted above, as it makes debugging easier, but it still suffers from the same false-positive problem. It's probably best to study/discuss that in its own ticket/PR.

In summary, I believe it's very unlikely that someone accidentally breaks the large-page fall-back logic this test tries to verify. Even if the large-page fall-back logic were broken somehow, it's trivially reproducible and should be simple to fix as well. Therefore, the benefit of this test is questionable. OTOH, the cost of maintaining this test (e.g. dealing with false positives) is very real.

Given such low benefit-cost ratio, I suggest dropping the test in this PR.

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

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


From iwalulya at openjdk.java.net  Tue Mar 15 11:40:05 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 15 Mar 2022 11:40:05 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr
Message-ID: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>

Hi all,
Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 

Testing: tier1

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

Commit messages:
 - refactor

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

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


From duke at openjdk.java.net  Tue Mar 15 12:22:37 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Tue, 15 Mar 2022 12:22:37 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v13]
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <I2uz4lDD0pIfUDFXl2hX2H7b_BLxdq8X9AXMMVipjgw=.bfe2fd11-8ef6-474b-9bed-26907a274140@github.com>

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:

  8271195: Removed the jtreg testcase.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/30453b3f..3848e988

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=11-12

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

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


From duke at openjdk.java.net  Tue Mar 15 12:45:43 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Tue, 15 Mar 2022 12:45:43 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v11]
In-Reply-To: <jxxR2n5sn7XU8Go5v1u10JIVlshjx0CgfmGiRevZFC8=.c0ef7077-a9b7-43f6-80ad-395f644a927a@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@github.com>
 <qPnx61jc40TVADIZZYu5lBtMMP_gHREA1gKZW6Hs6J4=.d35a0ad2-502a-48aa-b613-6a808ea7de79@github.com>
 <jxxR2n5sn7XU8Go5v1u10JIVlshjx0CgfmGiRevZFC8=.c0ef7077-a9b7-43f6-80ad-395f644a927a@github.com>
Message-ID: <hIxTjw1yqqVDLiFmJfpys7i_cXwWMsQNGizJXXixjyo=.a2d421ed-c710-4710-9186-7e56bbbf65c3@github.com>

On Tue, 15 Mar 2022 11:04:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please drop the test.
>> 
>> The test is not able to distinguish failures from problems with the VM logic and other processes spuriously allocating enough large pages to make this test fail afaict. That's just a too annoying failure to debug. We can look into the test in a separate CR.
>> 
>> I kept the other comments I had for reference.
>
>> The test is not able to distinguish failures from problems with the VM logic and other processes spuriously allocating enough large pages to make this test fail afaict.
> 
> I don't see any easy way fixing this and including this test in CI can cause undesirable false-positives.
> 
>> also created a minimal test case as per @albertnetymk suggestion to test a point scenario.
> 
> I personally like the minimal test case you posted above, as it makes debugging easier, but it still suffers from the same false-positive problem. It's probably best to study/discuss that in its own ticket/PR.
> 
> In summary, I believe it's very unlikely that someone accidentally breaks the large-page fall-back logic this test tries to verify. Even if the large-page fall-back logic were broken somehow, it's trivially reproducible and should be simple to fix as well. Therefore, the benefit of this test is questionable. OTOH, the cost of maintaining this test (e.g. dealing with false positives) is very real.
> 
> Given such low benefit-cost ratio, I suggest dropping the test in this PR.

Hello @albertnetymk , @kstefanj , @tschatzl 

Removed the test case, looking forward to your review clearance.

Thanks,
Swati

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

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


From ayang at openjdk.java.net  Tue Mar 15 12:53:44 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 15 Mar 2022 12:53:44 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr
In-Reply-To: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
Message-ID: <5TbTrCvUxatd-G7beIT4IlSXW0g3HOMt1ntW6m65TM4=.e4f15296-24f7-4504-ada7-a4e72bb80f16@github.com>

On Tue, 15 Mar 2022 11:32:35 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
> 
> Testing: tier1

Marked as reviewed by ayang (Reviewer).

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

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


From ayang at openjdk.java.net  Tue Mar 15 12:56:43 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 15 Mar 2022 12:56:43 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v13]
In-Reply-To: <I2uz4lDD0pIfUDFXl2hX2H7b_BLxdq8X9AXMMVipjgw=.bfe2fd11-8ef6-474b-9bed-26907a274140@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <I2uz4lDD0pIfUDFXl2hX2H7b_BLxdq8X9AXMMVipjgw=.bfe2fd11-8ef6-474b-9bed-26907a274140@github.com>
Message-ID: <gXzsV-uRqTkRxVWnknzIUHdEDNRWm6rk50NDJpM9rYU=.7abb68f2-eb7b-481e-8627-3d28f2ea442a@github.com>

On Tue, 15 Mar 2022 12:22:37 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Removed the jtreg testcase.

Thank you for the revision.

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

Marked as reviewed by ayang (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Mar 15 14:43:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 15 Mar 2022 14:43:50 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v12]
In-Reply-To: <P5IZSwrTuMkBnqJYXlXJu2_DqHvSH9QNv4ukFhEwPtE=.2f7f979a-8b65-4a38-85e0-21d98f2076d8@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <P5IZSwrTuMkBnqJYXlXJu2_DqHvSH9QNv4ukFhEwPtE=.2f7f979a-8b65-4a38-85e0-21d98f2076d8@github.com>
Message-ID: <wZe3YRj2NK0N1mkhtSMJelFmhqtoVaZhRUTR8OzTleY=.107cc3f3-e133-48bc-b16f-cf59b99a44fa@github.com>

On Fri, 11 Mar 2022 14:28:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Changes requested by tschatzl (Reviewer).

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

> 153: 
> 154: class RemoveSelfForwardPtrHRChunkClosure : public G1HeapRegionChunkClosure {
> 155:   class RegionMarkedWordsCache {

Suggestion:


  // Caches the currently accumulated number of live/marked words found in this heap region. Avoids direct (frequent) atomic operations on the HeapRegion's marked words.
  class RegionMarkedWordsCache {

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

> 168:     void note_self_forwarding_removal_end_par() {
> 169:       _g1h->region_at(_region_idx)->note_self_forwarding_removal_end_par(_marked_words * BytesPerWord);
> 170:     }

This helper should be `private` afaict.

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

> 48:   _regions_failed_evacuation.resize(max_regions);
> 49:   _evac_failure_regions = NEW_C_HEAP_ARRAY(uint, max_regions, mtGC);
> 50:   _chunks_in_regions = new (NEW_C_HEAP_OBJ(G1ScanChunksInHeapRegions, mtGC)) G1ScanChunksInHeapRegions();

If the code made `G1ScanChunksInHeapRegions` inherit from `CHeapObj<mtGC>`, then the macros to allocate/delete would not be required.

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

> 96: 
> 97:     void prepare_region(uint region_idx, uint worker_id) {
> 98:       G1CollectedHeap* _heap = G1CollectedHeap::heap();

Locals should not have an underscore. Also we tend to use `g1h` for variables containing `G1CollectedHeap::heap()`.

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

> 96: 
> 97:     void prepare_region(uint region_idx, uint worker_id) {
> 98:       G1CollectedHeap* _heap = G1CollectedHeap::heap();

Locals should not have an underscore. I personally also prefer `g1h` for `G1CollectedHeap::heap()`, but `heap` is fine.

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

> 137: public:
> 138:   PrepareEvacFailureRegionTask(G1EvacFailureRegions* evac_failure_regions, uint num_workers) :
> 139:   WorkerTask("Prepare Evacuation Failure Region Task"),

The whole initializer list should indented one more level.

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

> 150: 
> 151: void G1EvacFailureRegions::prepare_regions() {
> 152:   uint num_workers = MAX2(1u, MIN2(_evac_failure_regions_cur_length, G1CollectedHeap::heap()->workers()->active_workers()));

There is this `clamp(value, min max)` function which is a bit more readable than this. Please also introduce a helper variable `g1h` to improve readability.

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

> 152:   uint num_workers = MAX2(1u, MIN2(_evac_failure_regions_cur_length, G1CollectedHeap::heap()->workers()->active_workers()));
> 153:   PrepareEvacFailureRegionTask task(this, num_workers);
> 154:   G1CollectedHeap::heap()->workers()->run_task(&task, num_workers);

Suggestion:

  WorkerThreads* workers = G1CollectedHeap::heap()->workers();
  uint num_workers = clamp(_evac_failure_regions_cur_length, 1u, workers->active_workers()));
  PrepareEvacFailureRegionTask task(this, num_workers);
  workers->run_task(&task, num_workers);


This suggestion is kind of obsolete when wrapping this into a `G1AbstractSubTask`

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

> 66: 
> 67:   // Do necessary preparation for evacuation failure regions
> 68:   void prepare_regions();

I think the whole of `prepare_regions` should be integrated as a `G1BatchedTask`; from an initial look there does not seem to be anything in cleanup phase 1 that is dependent on what this code updates.
Simply add a method that returns an `G1AbstractSubTask` for use in the `G1BatchedGangTask` as done e.g. for `G1RemSet::create_cleanup_after_scan_heap_roots_task`.

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

> 116:   _gc_par_phases[EagerlyReclaimHumongousObjects] = new WorkerDataArray<double>("EagerlyReclaimHumongousObjects", "Eagerly Reclaim Humongous Objects (ms):", max_gc_threads);
> 117:   _gc_par_phases[RestorePreservedMarks] = new WorkerDataArray<double>("RestorePreservedMarks", "Restore Preserved Marks (ms):", max_gc_threads);
> 118:   _gc_par_phases[VerifyAfterSelfForwardingPtrRemoval] = new WorkerDataArray<double>("VerifyAfterSelfForwardingPtrRemoval", "Verify Retained Regions (ms):", max_gc_threads);

Not sure if we need extra verification pass time logging, but keep it if you think it is useful.

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.

It's 2022 already :)

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2021, Huawei Technologies Co. Ltd. All rights reserved.

It's 2022 now :)

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 30:

> 28: #include "gc/g1/g1ConcurrentMarkBitMap.inline.hpp"
> 29: #include "gc/g1/g1HeapRegionChunk.hpp"
> 30: #include "gc/g1/heapRegion.hpp"

I think including the .inline is better here as likely one or more of its methods are used in this code (I did not check), but there is a risk on the .inline contents being imported from somewhere else.

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 55:

> 53: 
> 54: void G1ScanChunksInHeapRegions::process_chunk(G1HeapRegionChunkClosure* chunk_closure, uint chunk_id, uint worker_id) {
> 55:   G1GCPhaseTimes* p = G1CollectedHeap::heap()->phase_times();

Introduce a `g1h` variable for `G1CollectedHeap::heap()` here (your call)

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 55:

> 53: 
> 54: void G1ScanChunksInHeapRegions::process_chunk(G1HeapRegionChunkClosure* chunk_closure, uint chunk_id, uint worker_id) {
> 55:   G1GCPhaseTimes* p = G1CollectedHeap::heap()->phase_times();

Please extract `G1CollectedHeap::heap()` into a variable (`g1h`).

src/hotspot/share/gc/g1/g1HeapRegionChunk.hpp line 80:

> 78:   uint _chunks_per_region;
> 79:   uint _chunk_size;
> 80:   uint _total_chunks;

This can be retrieved (via a getter) from `_chunks` to avoid storing the same value multiple times.

src/hotspot/share/gc/g1/g1HeapRegionChunk.hpp line 80:

> 78:   uint _chunks_per_region;
> 79:   uint _chunk_size;
> 80:   uint _total_chunks;

Instead of the explicit variable, I recommend having a getter that returns `_chunks.size()`. This avoids duplication of that information.

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 986:

> 984:   allocator()->release_gc_alloc_regions(evacuation_info);
> 985: 
> 986:   _evac_failure_regions.prepare_regions();

Can this task be moved into the `post_evacuate_cleanup_1` phase as a `G1BatchedTask`?

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 70:

> 68: 
> 69: class G1PostEvacuateCollectionSetCleanupTask1::SampleCollectionSetCandidatesTask : public G1AbstractSubTask {
> 70: 

Seems to be an unrelated cleanup. Please remove.

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 73:

> 71: public:
> 72:   SampleCollectionSetCandidatesTask() :
> 73:     G1AbstractSubTask(G1GCPhaseTimes::SampleCollectionSetCandidates) { }

Seems to be an unrelated cleanup. Please remove.

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp line 90:

> 88: 
> 89:       bool do_heap_region(HeapRegion* hr) override {
> 90:         _total.add(hr->rem_set()->card_set_memory_stats());

Seems to be an unrelated cleanup. Please remove.

src/hotspot/share/gc/g1/g1_globals.hpp line 391:

> 389:           "for evecuation failure regions.")                                \
> 390:           range(1, 1024)                                                    \
> 391:                                                                             \

Please make these diagnostic. They really are just for troubleshooting and not general use.

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

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


From tschatzl at openjdk.java.net  Wed Mar 16 08:58:43 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 16 Mar 2022 08:58:43 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v13]
In-Reply-To: <I2uz4lDD0pIfUDFXl2hX2H7b_BLxdq8X9AXMMVipjgw=.bfe2fd11-8ef6-474b-9bed-26907a274140@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <I2uz4lDD0pIfUDFXl2hX2H7b_BLxdq8X9AXMMVipjgw=.bfe2fd11-8ef6-474b-9bed-26907a274140@github.com>
Message-ID: <ncAsUaK-g0dFyJjH7KG5FeksNwVXr9v-dnxT4uwcrTg=.91f30578-7872-4250-b76e-ee8c5edf4ffe@github.com>

On Tue, 15 Mar 2022 12:22:37 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> Hi Team,
>> 
>> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
>> 
>> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
>> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
>> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
>> 
>> ?
>> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
>> 
>> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
>> 
>> 
>> Please review and provide your valuable comments.
>> 
>> 
>> 
>> Thanks,
>> Swati Sharma
>> Runtime Software Development Engineer 
>> Intel
>
> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271195: Removed the jtreg testcase.

Lgtm. Thanks.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Mar 16 09:41:41 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 16 Mar 2022 09:41:41 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr
In-Reply-To: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
Message-ID: <ujWP5kfitpUvPsWGBVSpt_tvGSqoItbl3auXnm48CwI=.541109ad-351f-401a-9ed2-def77f428afe@github.com>

On Tue, 15 Mar 2022 11:32:35 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
> 
> Testing: tier1

Lgtm with some minor formatting comments.

src/hotspot/share/gc/g1/g1CardSet.hpp line 210:

> 208:   //                              limited to a sub-range of the original range. Currently only one level of this
> 209:   //                              container is supported.
> 210:   using ContainerPtr = void*;

I can't anchor this elsewhere: the below `CardSetInlinePtr` etc tag names should also be `ContainerInlinePtr` etc, shouldn't they?

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

> 219: 
> 220:   // The special sentinel values
> 221:   static constexpr ContainerPtr FreeCardSet    = nullptr;

Suggestion:

  static constexpr ContainerPtr FreeCardSet = nullptr;

Let's avoid lining up fairly unrelated constants.

src/hotspot/share/gc/g1/g1CardSet.hpp line 226:

> 224:   static ContainerPtr FullCardSet;
> 225: 
> 226:   static const uintptr_t ContainerPtrTypeMask  = ((uintptr_t)1 << ContainerPtrHeaderSize) - 1;

Suggestion:

  static const uintptr_t ContainerPtrTypeMask = ((uintptr_t)1 << ContainerPtrHeaderSize) - 1;

Same here.

src/hotspot/share/gc/g1/g1CardSet.hpp line 262:

> 260:   bool coarsen_container(ContainerPtr volatile* container_addr,
> 261:                         ContainerPtr cur_container,
> 262:                         uint card_in_region, bool within_howl = false);

Suggestion:

  bool coarsen_container(ContainerPtr volatile* container_addr,
                         ContainerPtr cur_container,
                         uint card_in_region, bool within_howl = false);

src/hotspot/share/gc/g1/g1CardSet.hpp line 303:

> 301: 
> 302:   // Adds the given card to this set, returning an appropriate result.
> 303:   // If added, updates the total count.

Suggestion:

  // If incremental_count is true and the card has been added, updates the total count.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Wed Mar 16 09:51:27 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 16 Mar 2022 09:51:27 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr [v2]
In-Reply-To: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
Message-ID: <bXr3-VStDRqpWJgjn3J3CPYGCJ_RI8aSU8AIf_qTquo=.387e748a-f215-46a1-936b-2a2d21b5016a@github.com>

> Hi all,
> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
> 
> Testing: tier1

Ivan Walulya has updated the pull request incrementally with four additional commits since the last revision:

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7816/files
  - new: https://git.openjdk.java.net/jdk/pull/7816/files/4e036f5b..88ca4ac9

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

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

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


From duke at openjdk.java.net  Wed Mar 16 09:51:52 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Wed, 16 Mar 2022 09:51:52 GMT
Subject: Integrated: 8271195: Use largest available large page size smaller
 than LargePageSizeInBytes when available
In-Reply-To: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
Message-ID: <FkwkYawXg6iwVBBxRglHFHvfKQHxe2s5DYc5BHecEyI=.29d7c12b-6e60-47db-84ae-3830cae082d6@github.com>

On Wed, 2 Feb 2022 15:58:53 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Hi Team,
> 
> In this patch I have fixed two issues related to large pages, following is the summary of changes :-
> 
> 1. Patch fixes existing large page allocation functionality where if a commit over 1GB pages fails allocation should happen over next small page size i.e. 2M where as currently its happening over 4kb pages resulting into significant TLB miss penalty.
> Patch includes new JTREG Test case covering various scenarios for checking the correct explicit page allocation according ?to the 1G, 2M, 4K priority.
> 2. While attempting commit over larger pages we first try to reserve requested bytes over the virtual address space, in case commit to large page fails we should be un reserving entire reservation to avoid leaving any leaks in virtual address space.
> 
> ?
> Please find below the performance data with and without patch for the JMH benchmark included with the patch.
> 
> ![image](https://user-images.githubusercontent.com/96874289/152189587-4822a4ca-f5e2-4621-b405-0da941485143.png)
> 
> 
> Please review and provide your valuable comments.
> 
> 
> 
> Thanks,
> Swati Sharma
> Runtime Software Development Engineer 
> Intel

This pull request has now been integrated.

Changeset: 08cadb47
Author:    Swati Sharma <swati.sharma at intel.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08cadb4754da0d5e68ee2df45f4098d203d14115
Stats:     109 lines in 3 files changed: 87 ins; 14 del; 8 mod

8271195: Use largest available large page size smaller than LargePageSizeInBytes when available

Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Reviewed-by: ayang, tschatzl

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

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


From iwalulya at openjdk.java.net  Wed Mar 16 12:44:36 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 16 Mar 2022 12:44:36 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr [v3]
In-Reply-To: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
Message-ID: <n5EoYzjAFlndAzpblJvp1DOJ7uX45R92cGIfCgpe3Lw=.7ccf20c1-7855-41f5-bcd0-0e76129f4af7@github.com>

> Hi all,
> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
> 
> Testing: tier1

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  CardSet Container types

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7816/files
  - new: https://git.openjdk.java.net/jdk/pull/7816/files/88ca4ac9..92161dc9

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

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

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


From ayang at openjdk.java.net  Wed Mar 16 13:04:03 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 16 Mar 2022 13:04:03 GMT
Subject: RFR: 8283188: Build time regression caused by JDK-8278917
Message-ID: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>

Move `G1CollectedHeap::mark_evac_failure_object` to cpp so that `g1CollectedHeap.inline.hpp` doesn't need to include `g1ConcurrentMark.inline.hpp`.

With the patch, the build time of clean fastdebug is reduced by ~16s.

Before: 6:25.72
After: 6:09.76

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

Commit messages:
 - build-time

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

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


From iwalulya at openjdk.java.net  Wed Mar 16 13:12:38 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 16 Mar 2022 13:12:38 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr [v4]
In-Reply-To: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
Message-ID: <bOXWxlfkpVGzJ3I3hCNvH24_6mbpWBo_mpVkAE4EQCg=.803f6c45-8bf9-4be9-8d03-0a19c775a09a@github.com>

> Hi all,
> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
> 
> Testing: tier1

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  space

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7816/files
  - new: https://git.openjdk.java.net/jdk/pull/7816/files/92161dc9..38e59685

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

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

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


From tschatzl at openjdk.java.net  Wed Mar 16 13:36:53 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 16 Mar 2022 13:36:53 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr [v4]
In-Reply-To: <bOXWxlfkpVGzJ3I3hCNvH24_6mbpWBo_mpVkAE4EQCg=.803f6c45-8bf9-4be9-8d03-0a19c775a09a@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
 <bOXWxlfkpVGzJ3I3hCNvH24_6mbpWBo_mpVkAE4EQCg=.803f6c45-8bf9-4be9-8d03-0a19c775a09a@github.com>
Message-ID: <oVJ35jqfeUF9Afn6CXfI3OKKOuUZMO1AQTYzZWkt8tI=.2ca5d98a-ae76-4512-80f8-bc6bfb16da84@github.com>

On Wed, 16 Mar 2022 13:12:38 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
>> 
>> Testing: tier1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space

Marked as reviewed by tschatzl (Reviewer).

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

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


From ayang at openjdk.java.net  Wed Mar 16 14:04:55 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 16 Mar 2022 14:04:55 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr [v4]
In-Reply-To: <bOXWxlfkpVGzJ3I3hCNvH24_6mbpWBo_mpVkAE4EQCg=.803f6c45-8bf9-4be9-8d03-0a19c775a09a@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
 <bOXWxlfkpVGzJ3I3hCNvH24_6mbpWBo_mpVkAE4EQCg=.803f6c45-8bf9-4be9-8d03-0a19c775a09a@github.com>
Message-ID: <aOHL1A2cufB-NzeqXlWM03yT_yB_1WkH13ZC7GYX1lU=.1cbefd19-1476-49be-b916-6689dd8ab9db@github.com>

On Wed, 16 Mar 2022 13:12:38 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
>> 
>> Testing: tier1
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   space

Marked as reviewed by ayang (Reviewer).

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

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


From kbarrett at openjdk.java.net  Wed Mar 16 16:13:40 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 16 Mar 2022 16:13:40 GMT
Subject: RFR: 8283188: Build time regression caused by JDK-8278917
In-Reply-To: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
References: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
Message-ID: <H9ZLib1ftDsoGEZelqNQMO4K_wYXWon3YTyAXilZ9d0=.0df82ce7-e6c4-4d47-b054-c3995d41949c@github.com>

On Wed, 16 Mar 2022 12:29:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Move `G1CollectedHeap::mark_evac_failure_object` to cpp so that `g1CollectedHeap.inline.hpp` doesn't need to include `g1ConcurrentMark.inline.hpp`.
> 
> With the patch, the build time of clean fastdebug is reduced by ~16s.
> 
> Before: 6:25.72
> After: 6:09.76

Looks good.

I was curious, so a dug into the data a bit.  According to the build system's generated .d files, this removes 61 files from transitive closure of the includes for g1CollectedHeap.inline.hpp, some of them fairly large.  And g1CollectedHeap.inline.hpp is itself included 59 times.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Wed Mar 16 16:29:45 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 16 Mar 2022 16:29:45 GMT
Subject: RFR: 8282727: Parallel: Remove PSPromotionManager::_totally_drain
In-Reply-To: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
References: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
Message-ID: <yjThdaQeuhHGwLGxPKGZUAiEVCBbbvFe8PFgHZvaw5U=.6520443f-7a8b-40d2-83af-c2e3b239c16f@github.com>

On Mon, 7 Mar 2022 08:55:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant boolean field.
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From iwalulya at openjdk.java.net  Thu Mar 17 08:58:37 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 17 Mar 2022 08:58:37 GMT
Subject: RFR: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr [v4]
In-Reply-To: <aOHL1A2cufB-NzeqXlWM03yT_yB_1WkH13ZC7GYX1lU=.1cbefd19-1476-49be-b916-6689dd8ab9db@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
 <bOXWxlfkpVGzJ3I3hCNvH24_6mbpWBo_mpVkAE4EQCg=.803f6c45-8bf9-4be9-8d03-0a19c775a09a@github.com>
 <aOHL1A2cufB-NzeqXlWM03yT_yB_1WkH13ZC7GYX1lU=.1cbefd19-1476-49be-b916-6689dd8ab9db@github.com>
Message-ID: <8Vpg1EtUlnplVoNHfds33xzFJc0lwgVmHapXdxbIgjo=.99b8a228-3972-4ea6-867a-3a11461002b0@github.com>

On Wed, 16 Mar 2022 14:01:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   space
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk and @tschatzl for the reviews.

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

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


From iwalulya at openjdk.java.net  Thu Mar 17 08:58:38 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 17 Mar 2022 08:58:38 GMT
Subject: Integrated: 8282072: G1: Rename CardSetPtr to CardSetContainerPtr
In-Reply-To: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
References: <L-GD_DRq8OL0O3hsnk9O_fwR4lqhEoKNJjiAXxQtIgg=.a6113353-b668-4be0-93a6-929437de43a0@github.com>
Message-ID: <3eGLBzM5DXMGhQG0JSWU_GL45ncJq8VGGphfFSQAC7s=.5056a53a-59ec-465a-957b-b5de462ac51c@github.com>

On Tue, 15 Mar 2022 11:32:35 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> Please review this change to rename CardSetPtr to ContainerPtr since it is a pointer to the containers. 
> 
> Testing: tier1

This pull request has now been integrated.

Changeset: a5ebcc0c
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a5ebcc0c04bedd87bc9a523b0a45b50fc4b0f5f0
Stats:     359 lines in 8 files changed: 6 ins; 13 del; 340 mod

8282072: G1: Rename CardSetPtr to CardSetContainerPtr

Reviewed-by: ayang, tschatzl

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

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


From ayang at openjdk.java.net  Thu Mar 17 09:53:36 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 17 Mar 2022 09:53:36 GMT
Subject: RFR: 8282727: Parallel: Remove PSPromotionManager::_totally_drain
In-Reply-To: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
References: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
Message-ID: <6BtPrig27G7pkVukxP_ptiR4j21fISSr0Hi-L4L_KKk=.b97c3150-ef12-4292-94b4-f6ac31c646d6@github.com>

On Mon, 7 Mar 2022 08:55:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant boolean field.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Mar 17 09:53:36 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 17 Mar 2022 09:53:36 GMT
Subject: Integrated: 8282727: Parallel: Remove
 PSPromotionManager::_totally_drain
In-Reply-To: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
References: <AYqtC9hpk1ogQdf-nKUE37PpXmhgPMs7q0ZJqyf6KQo=.14108b77-52cb-44dd-96a1-a0f2541dd21c@github.com>
Message-ID: <lm50if7iWDVWd_cTOEP_QBcLs0RuCg2pCBESc6CqlNw=.4d5211ef-c00c-46a2-98ee-29921f70c55a@github.com>

On Mon, 7 Mar 2022 08:55:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a redundant boolean field.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8282727: Parallel: Remove PSPromotionManager::_totally_drain

Reviewed-by: tschatzl, kbarrett

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

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


From tschatzl at openjdk.java.net  Thu Mar 17 15:46:32 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 17 Mar 2022 15:46:32 GMT
Subject: RFR: 8283188: Build time regression caused by JDK-8278917
In-Reply-To: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
References: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
Message-ID: <mkhWw0XYZEgzEc5KUhH1DEAtZNqwdG6G3mqnM09Z5X8=.be928fa7-59ea-4e93-89c8-f9a1ca910340@github.com>

On Wed, 16 Mar 2022 12:29:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Move `G1CollectedHeap::mark_evac_failure_object` to cpp so that `g1CollectedHeap.inline.hpp` doesn't need to include `g1ConcurrentMark.inline.hpp`.
> 
> With the patch, the build time of clean fastdebug is reduced by ~16s.
> 
> Before: 6:25.72
> After: 6:09.76

Marked as reviewed by tschatzl (Reviewer).

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

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


From ayang at openjdk.java.net  Thu Mar 17 16:20:35 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 17 Mar 2022 16:20:35 GMT
Subject: RFR: 8283188: Build time regression caused by JDK-8278917
In-Reply-To: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
References: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
Message-ID: <PGp70_kD5p1iCKyfza7lJLlYPKuahcaIWsoveuVY0Mg=.5c98c1d8-e03b-443d-92a6-9693baa9a5ea@github.com>

On Wed, 16 Mar 2022 12:29:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Move `G1CollectedHeap::mark_evac_failure_object` to cpp so that `g1CollectedHeap.inline.hpp` doesn't need to include `g1ConcurrentMark.inline.hpp`.
> 
> With the patch, the build time of clean fastdebug is reduced by ~16s.
> 
> Before: 6:25.72
> After: 6:09.76

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Mar 17 16:20:36 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 17 Mar 2022 16:20:36 GMT
Subject: Integrated: 8283188: Build time regression caused by JDK-8278917
In-Reply-To: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
References: <sPrISsUVsZ1GzxPqBFdzu4UQ8vv39NHtNhHwh9g2ib0=.613d24ad-2629-4859-a0fb-36083dc85d61@github.com>
Message-ID: <lL5PXcBcX0QP2_YjRn3pVNOQvTrhqyxEXhGB-RSPT0Y=.5d23f1ee-b9b5-4a99-b4f1-dc264ad80546@github.com>

On Wed, 16 Mar 2022 12:29:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Move `G1CollectedHeap::mark_evac_failure_object` to cpp so that `g1CollectedHeap.inline.hpp` doesn't need to include `g1ConcurrentMark.inline.hpp`.
> 
> With the patch, the build time of clean fastdebug is reduced by ~16s.
> 
> Before: 6:25.72
> After: 6:09.76

This pull request has now been integrated.

Changeset: 31df6a60
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31df6a60a8853be224d8c8b8c8ca6aea1bae2167
Stats:     16 lines in 3 files changed: 7 ins; 8 del; 1 mod

8283188: Build time regression caused by JDK-8278917

Reviewed-by: kbarrett, tschatzl

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

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


From ayang at openjdk.java.net  Thu Mar 17 17:01:51 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 17 Mar 2022 17:01:51 GMT
Subject: RFR: 8283332: G1: Stricter assertion in
 G1BlockOffsetTablePart::forward_to_block_containing_addr
Message-ID: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>

Stricter assertion to match the assert message.

Test: hotspot_gc

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

Commit messages:
 - g1-bot

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

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


From kbarrett at openjdk.java.net  Thu Mar 17 23:35:31 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 17 Mar 2022 23:35:31 GMT
Subject: RFR: 8283332: G1: Stricter assertion in
 G1BlockOffsetTablePart::forward_to_block_containing_addr
In-Reply-To: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
References: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
Message-ID: <00hm1Gmj1wX_qkqIVnGcA1UixjjP2stvNogY_Dj_vfg=.9538e6c2-5ae6-42e3-8dca-bdd9b5463e7e@github.com>

On Thu, 17 Mar 2022 16:53:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Stricter assertion to match the assert message.
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Fri Mar 18 04:51:20 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 04:51:20 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v13]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <Ctnk8v1jBpNTZxp0XCidOQ69tTESTcXoqbksHjlIOKc=.8eb00e31-933d-4d5f-bb08-0f835834c576@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Thomas review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/ead76594..4efb91c7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=11-12

  Stats: 47 lines in 9 files changed: 10 ins; 9 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From mli at openjdk.java.net  Fri Mar 18 04:51:21 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 04:51:21 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v12]
In-Reply-To: <P5IZSwrTuMkBnqJYXlXJu2_DqHvSH9QNv4ukFhEwPtE=.2f7f979a-8b65-4a38-85e0-21d98f2076d8@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <P5IZSwrTuMkBnqJYXlXJu2_DqHvSH9QNv4ukFhEwPtE=.2f7f979a-8b65-4a38-85e0-21d98f2076d8@github.com>
Message-ID: <k1d40lrRPEgKpBNB5Xl2grlY5DxXjeoZf5xTA-wBor0=.35ba8943-549b-445f-8e6b-cfed29091e02@github.com>

On Fri, 11 Mar 2022 14:28:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Thanks for the detailed reviews. :)

I'm not sure if it's feasible to move `prepare_regions` into post_evacuate_cleanup_1 as a G1BatchedTask.
My concern is that in `prepare_regions()->PrepareEvacFailureRegionTask::prepare_region()->HeapRegion::note_self_forwarding_removal_start()`, nTAMS is set, and nTAMS is used *cleanup 1* phase at RemoveSelfForwardPtrObjClosure to set next bitmap. If move `prepare_regions` into post_evacuate_cleanup_1 as a G1BatchedTask, there is no guarantee that preparation will be done before the usage of nTAMS in RemoveSelfForwardPtrObjClosure.
How do you think about it?

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

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


From mli at openjdk.java.net  Fri Mar 18 04:51:21 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 04:51:21 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v12]
In-Reply-To: <wZe3YRj2NK0N1mkhtSMJelFmhqtoVaZhRUTR8OzTleY=.107cc3f3-e133-48bc-b16f-cf59b99a44fa@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <P5IZSwrTuMkBnqJYXlXJu2_DqHvSH9QNv4ukFhEwPtE=.2f7f979a-8b65-4a38-85e0-21d98f2076d8@github.com>
 <wZe3YRj2NK0N1mkhtSMJelFmhqtoVaZhRUTR8OzTleY=.107cc3f3-e133-48bc-b16f-cf59b99a44fa@github.com>
Message-ID: <Lf7XLRE0tZiqZf1YVF-I6iKqxHfT9zNiZa8iw7jnpWc=.f34d7d82-3f98-4e28-8aa9-fd1246472a61@github.com>

On Tue, 15 Mar 2022 14:02: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:
>> 
>>   Albert review
>
> src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 30:
> 
>> 28: #include "gc/g1/g1ConcurrentMarkBitMap.inline.hpp"
>> 29: #include "gc/g1/g1HeapRegionChunk.hpp"
>> 30: #include "gc/g1/heapRegion.hpp"
> 
> I think including the .inline is better here as likely one or more of its methods are used in this code (I did not check), but there is a risk on the .inline contents being imported from somewhere else.

Seems no inline methods of HeapRegion are used here.

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

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


From mli at openjdk.java.net  Fri Mar 18 08:02:12 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 08:02:12 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v14]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Fix compilation error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/4efb91c7..abd99935

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=12-13

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

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


From iwalulya at openjdk.java.net  Fri Mar 18 08:23:31 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 18 Mar 2022 08:23:31 GMT
Subject: RFR: 8283332: G1: Stricter assertion in
 G1BlockOffsetTablePart::forward_to_block_containing_addr
In-Reply-To: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
References: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
Message-ID: <L7QWWJ6V5bQZNzi92S5ixJJo-BOOtTwn1CbniBY8xIo=.f58bc00f-1ffa-46c3-aac9-84bf9e7a0625@github.com>

On Thu, 17 Mar 2022 16:53:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Stricter assertion to match the assert message.
> 
> Test: hotspot_gc

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Mar 18 08:32:36 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Mar 2022 08:32:36 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v14]
In-Reply-To: <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
Message-ID: <-_RSU4tn6Lc1tBjLzOFQxo4xTKMTqZJJbZD3XK7KZFc=.6e3f144d-de54-44b8-834c-b541d991807f@github.com>

On Fri, 18 Mar 2022 08:02:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation error

> Thanks for the detailed reviews. :)
> 
> I'm not sure if it's feasible to move `prepare_regions` into post_evacuate_cleanup_1 as a G1BatchedTask. My concern is that in `prepare_regions()->PrepareEvacFailureRegionTask::prepare_region()->HeapRegion::note_self_forwarding_removal_start()`, nTAMS is set, and nTAMS is used _cleanup 1_ phase at RemoveSelfForwardPtrObjClosure to set next bitmap. If move `prepare_regions` into post_evacuate_cleanup_1 as a G1BatchedTask, there is no guarantee that preparation will be done before the usage of nTAMS in RemoveSelfForwardPtrObjClosure. How do you think about it?

I believe this is an unnecessary dependency.

`PrepareEvacFailureRegionTask::prepare_region()->HeapRegion::note_self_forwarding_removal_start` sets nTAMS to `top()` unconditionally with the intent that the mark always happens.

So instead of calling `_cm->mark_in_next_bitmap(_worker_id, obj);` which checks nTAMS, just *unconditionally* mark the next bitmap (not sure if there is already a method for this) to achieve the same effect.

The alternative would be to add a new `G1BatchedTask` for just this preparation, which seems much more work not only in terms of code, but also much more work spinning up threads.

Of course, the use of this "raw" mark method needs to be documented.

Fwiw, in the protoype we have for [JDK-8210708](https://bugs.openjdk.java.net/browse/JDK-8210708), which looks fairly good at this point, a similar change would be needed anyway.

Thanks,
  Thomas

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

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


From mli at openjdk.java.net  Fri Mar 18 09:21:37 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 09:21:37 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v14]
In-Reply-To: <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
Message-ID: <8RkwuMEi9FEu3PCtBcqdJQENO8cmUglt9v4coupuxd0=.6a759d1f-9bef-4325-9cff-1754b82cd00d@github.com>

On Fri, 18 Mar 2022 08:02:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation error

Seems there is another dependency: in `RemoveSelfForwardPtrHRChunkClosure`, `_prev_marked_bytes` is accumulated concurrently;  `_prev_marked_bytes` should be reset to zero in `prepare_regions`.

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

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


From ayang at openjdk.java.net  Fri Mar 18 09:35:55 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 18 Mar 2022 09:35:55 GMT
Subject: RFR: 8283365: G1: Remove duplicate assertions in
 HeapRegion::oops_on_memregion_seq_iterate_careful
Message-ID: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>

Simple change of removing duplicate assertions.

Test: build

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

Commit messages:
 - g1-remove-assert

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

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


From tschatzl at openjdk.java.net  Fri Mar 18 09:46:37 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Mar 2022 09:46:37 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v14]
In-Reply-To: <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
Message-ID: <t5BtyunyksHSwcNaDLW06LAdOOQe4tFp-fjBKhWXDfE=.f7bba031-60c3-4453-84c7-3a40c3fdc65e@github.com>

On Fri, 18 Mar 2022 08:02:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation error

After a quick look through the code, I think we could just call `note_self_forwarding_removal_start` in `G1ParScanThreadState::handle_evacuation_failure_par()`, when a region is added to the list of failed regions the first time instead.

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

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


From mli at openjdk.java.net  Fri Mar 18 11:46:13 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 11:46:13 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v15]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <dgfUxezK8cHYQ7EXmGbnzdOiQhkzPi_y0VNOPxQOIcg=.64223d19-51b8-4c63-bb0b-4547b26a305b@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Move prepare_regions to post cleanup 1 phase

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/abd99935..f48aa051

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=13-14

  Stats: 46 lines in 8 files changed: 21 ins; 13 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7047.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7047/head:pull/7047

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


From mli at openjdk.java.net  Fri Mar 18 11:46:14 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Mar 2022 11:46:14 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v14]
In-Reply-To: <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <JW04E-lfgoOrT1gkMKn-_T20PZ4Qgo7jIKFAaasw0F0=.323ebaeb-90da-4174-b876-a71d8b24bded@github.com>
Message-ID: <s0KSr5e-HRjHIwbRrktV22j3bRvvZQFXvDupuJaxcjw=.4f6188b0-2317-45e9-8f31-8e994270c521@github.com>

On Fri, 18 Mar 2022 08:02:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix compilation error

Thanks, I've moved the `note_self_forwarding_removal_start` to `G1EvacFailureRegions::record`

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

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


From kbarrett at openjdk.java.net  Fri Mar 18 11:53:36 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 18 Mar 2022 11:53:36 GMT
Subject: RFR: 8283365: G1: Remove duplicate assertions in
 HeapRegion::oops_on_memregion_seq_iterate_careful
In-Reply-To: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
References: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
Message-ID: <tG4qOX4gF-dBHN4DHltpUJfFwelaNU26De-AqebSmeU=.4e1d96c4-95d3-4275-b6a4-9474be7688e6@github.com>

On Fri, 18 Mar 2022 09:29:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate assertions.
> 
> Test: build

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Mar 18 12:46:33 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Mar 2022 12:46:33 GMT
Subject: RFR: 8283365: G1: Remove duplicate assertions in
 HeapRegion::oops_on_memregion_seq_iterate_careful
In-Reply-To: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
References: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
Message-ID: <bZRRLwBROuP8ZzgETd89dEZc81BMN9TpV_loktRQxrQ=.6591c3cb-ce7a-4ebf-83b4-dde5ddc9a53d@github.com>

On Fri, 18 Mar 2022 09:29:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate assertions.
> 
> Test: build

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar 21 08:40:42 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 08:40:42 GMT
Subject: RFR: 8283332: G1: Stricter assertion in
 G1BlockOffsetTablePart::forward_to_block_containing_addr
In-Reply-To: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
References: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
Message-ID: <gKDdrgkVfzyZH6K1zot73p8LqEesRG-qSNv3aUBG6l0=.876dbcd8-d988-4d52-890e-818046c1c9e6@github.com>

On Thu, 17 Mar 2022 16:53:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Stricter assertion to match the assert message.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Mar 21 08:43:41 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 08:43:41 GMT
Subject: Integrated: 8283332: G1: Stricter assertion in
 G1BlockOffsetTablePart::forward_to_block_containing_addr
In-Reply-To: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
References: <WIWBxiv9uQCO-mCcDlwopPAmQ4MmMSktpmAvM7mj0gA=.58f6fb1b-8ecb-46a1-9530-3953ae66905d@github.com>
Message-ID: <iVA4Hb9dGxWob6QosnZApsISAYC6kDlVWdFarD9pBeU=.145bef65-7cf2-4ef7-856a-904db98e3624@github.com>

On Thu, 17 Mar 2022 16:53:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Stricter assertion to match the assert message.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: fd930151
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fd9301514e2093d9dcd7bcd9e4b812146b20dd03
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283332: G1: Stricter assertion in G1BlockOffsetTablePart::forward_to_block_containing_addr

Reviewed-by: kbarrett, iwalulya

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

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


From ayang at openjdk.java.net  Mon Mar 21 08:43:42 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 08:43:42 GMT
Subject: RFR: 8283365: G1: Remove duplicate assertions in
 HeapRegion::oops_on_memregion_seq_iterate_careful
In-Reply-To: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
References: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
Message-ID: <13TdDLuBvk4nrqFzp1JT3EqWwN2UIuN1BMTFYeldfF0=.6a5c6072-96e9-4d00-b507-df53b7b8fd42@github.com>

On Fri, 18 Mar 2022 09:29:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate assertions.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Mar 21 08:43:42 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 08:43:42 GMT
Subject: Integrated: 8283365: G1: Remove duplicate assertions in
 HeapRegion::oops_on_memregion_seq_iterate_careful
In-Reply-To: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
References: <tKaTS8aBwlC9AKS4YBLpHZ1JwD6gvIuIfh6pc6BB72Q=.9044b2a5-0a9b-445e-a85d-6ad7e0feac5e@github.com>
Message-ID: <oE4MvDZKpjO0LSXJOnFH7hoLTxk2dc8eluoXVxYh_R4=.e8840dd2-d1f2-4506-8bda-83fbfd53c37d@github.com>

On Fri, 18 Mar 2022 09:29:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing duplicate assertions.
> 
> Test: build

This pull request has now been integrated.

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

8283365: G1: Remove duplicate assertions in HeapRegion::oops_on_memregion_seq_iterate_careful

Reviewed-by: kbarrett, tschatzl

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

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


From iwalulya at openjdk.java.net  Mon Mar 21 14:08:01 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 21 Mar 2022 14:08:01 GMT
Subject: RFR: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template
 parameter
Message-ID: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>

Hi all,

Please review this change to remove the MEMFLAGS template parameter for G1SegmentedArraySegment and make it a runtime configuration parameter. This reduces on the code bloat due to templating because many of the methods in G1SegmentedArraySegment are independent of the template parameter.

Thanks
Ivan

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

Commit messages:
 - initial

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

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


From iwalulya at openjdk.java.net  Mon Mar 21 14:13:35 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 21 Mar 2022 14:13:35 GMT
Subject: RFR: 8283097: Parallel: Move filler object logic inside
 PSPromotionLAB::unallocate_object
In-Reply-To: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
References: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
Message-ID: <zU01y0DvJm8eHvYrpHVE5J6xfZ_Qi9qPF5Mj5AMA_vo=.a26929b1-5bc2-42fc-89eb-65bf9174597f@github.com>

On Mon, 14 Mar 2022 11:11:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup in the unallocation path in `PSPromotionManager::copy_unmarked_to_survivor_space`.
> 
> Test: hotspot_gc

Marked as reviewed by iwalulya (Reviewer).

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

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


From iwalulya at openjdk.java.net  Mon Mar 21 14:52:27 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 21 Mar 2022 14:52:27 GMT
Subject: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration
In-Reply-To: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
References: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
Message-ID: <WKCFw-ZYTHBsAbRb0v-Fl_cOcn3ELBupYm2M3rdRzOc=.8631828e-2b81-4b63-a700-cfe4b4a6b150@github.com>

On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc.
> 
> Test: tier1-6

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar 21 16:22:38 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 16:22:38 GMT
Subject: RFR: 8283097: Parallel: Move filler object logic inside
 PSPromotionLAB::unallocate_object
In-Reply-To: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
References: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
Message-ID: <MoeNaHzUaQlquic866W06zA7BGaT93vXoV5aPFcCScU=.decce4c2-7542-4e8e-88fa-d7d649f7c2bb@github.com>

On Mon, 14 Mar 2022 11:11:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup in the unallocation path in `PSPromotionManager::copy_unmarked_to_survivor_space`.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Mar 21 16:25:42 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 16:25:42 GMT
Subject: Integrated: 8283097: Parallel: Move filler object logic inside
 PSPromotionLAB::unallocate_object
In-Reply-To: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
References: <_Rm_EDfxhYMPFV1nhX8gQBjgD3MbPnbJUCzIjMjOe4k=.5dcc5087-6695-4b31-ac90-a17c56dd9df2@github.com>
Message-ID: <VIalGnPBCL7QgMLQIXwlsgsOqunr_gUcKuq3vs2GANc=.82079810-22bd-42b6-aa18-a4426402473d@github.com>

On Mon, 14 Mar 2022 11:11:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup in the unallocation path in `PSPromotionManager::copy_unmarked_to_survivor_space`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: f4f87284
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f4f87284cbbe95958d8c7d8adc0f5c5e260892ca
Stats:     16 lines in 3 files changed: 3 ins; 7 del; 6 mod

8283097: Parallel: Move filler object logic inside PSPromotionLAB::unallocate_object

Reviewed-by: tschatzl, iwalulya

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

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


From ayang at openjdk.java.net  Mon Mar 21 16:25:56 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 16:25:56 GMT
Subject: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration
In-Reply-To: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
References: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
Message-ID: <xYVIpFOhEEZoQu7QnRDV6Wlbs0sFgqS-qOfnyKfsP2g=.ae58f177-3350-493f-b053-895126d3ca93@github.com>

On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc.
> 
> Test: tier1-6

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Mar 21 16:25:56 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Mar 2022 16:25:56 GMT
Subject: Integrated: 8281879: Serial: Merge CardGeneration into
 TenuredGeneration
In-Reply-To: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
References: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>
Message-ID: <Fh6JkL0zGi4htPAkUVTyEvAOvkeKoMpd8eTydFjYPwE=.7404bac3-05a1-41b6-b8d6-7c09df03d88a@github.com>

On Tue, 15 Feb 2022 20:21:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes; `git diff --color-moved=zebra` probably helps to see the actual (small) change, such as dropping the `virtual` modifier, introducing small helper methods to avoid naming collision, etc.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: 19d34bdf
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19d34bdf99e98a9ef614cb7f93c141e6c82bedcb
Stats:     893 lines in 14 files changed: 350 ins; 526 del; 17 mod

8281879: Serial: Merge CardGeneration into TenuredGeneration

Reviewed-by: tschatzl, iwalulya

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

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


From tschatzl at openjdk.java.net  Mon Mar 21 16:33:39 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Mar 2022 16:33:39 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v15]
In-Reply-To: <dgfUxezK8cHYQ7EXmGbnzdOiQhkzPi_y0VNOPxQOIcg=.64223d19-51b8-4c63-bb0b-4547b26a305b@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <dgfUxezK8cHYQ7EXmGbnzdOiQhkzPi_y0VNOPxQOIcg=.64223d19-51b8-4c63-bb0b-4547b26a305b@github.com>
Message-ID: <3OvTN_R0PH7pDyYP4OBeqKCWyxXZ6ye8QBOrRi63eLc=.a97b522b-acf9-4d7b-9f5e-db024359b0c7@github.com>

On Fri, 18 Mar 2022 11:46:13 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move prepare_regions to post cleanup 1 phase

I will push the change through our testing again since so much time and so many changes happened since last time.

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

> 98:       // (implicitly) live. So, we won't mark them explicitly and
> 99:       // we'll leave them over NTAMS.
> 100:       _cm->mark_in_next_bitmap_unconditionally(_worker_id, obj);

I think this change, the introduction of this method, is unnecessary after moving the update to the nTAMS into the `G1EvacFailureRegions::record` method.

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

Changes requested by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Mar 22 08:12:38 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 22 Mar 2022 08:12:38 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v15]
In-Reply-To: <3OvTN_R0PH7pDyYP4OBeqKCWyxXZ6ye8QBOrRi63eLc=.a97b522b-acf9-4d7b-9f5e-db024359b0c7@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <dgfUxezK8cHYQ7EXmGbnzdOiQhkzPi_y0VNOPxQOIcg=.64223d19-51b8-4c63-bb0b-4547b26a305b@github.com>
 <3OvTN_R0PH7pDyYP4OBeqKCWyxXZ6ye8QBOrRi63eLc=.a97b522b-acf9-4d7b-9f5e-db024359b0c7@github.com>
Message-ID: <c7onyZV6BVQfQP4XV-CZAQlHQSx7RDIyPQDcTNe5iME=.f27aa969-04b5-4d6a-b7d0-8c7ba15197d1@github.com>

On Mon, 21 Mar 2022 16:30:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I will push the change through our testing again since so much time and so many changes happened since last time.

Testing seems good.

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

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


From mli at openjdk.java.net  Tue Mar 22 12:13:11 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 22 Mar 2022 12:13:11 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v16]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <-fRDKf14vBIjHeBjqxT71g_KSY919fi6ihnqkBw6g3g=.bd65fd9b-2d41-44cf-9d77-e51ff0a99c49@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  Remove unnecessary method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/f48aa051..391fdced

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=14-15

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

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


From mli at openjdk.java.net  Tue Mar 22 12:13:12 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Tue, 22 Mar 2022 12:13:12 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v15]
In-Reply-To: <c7onyZV6BVQfQP4XV-CZAQlHQSx7RDIyPQDcTNe5iME=.f27aa969-04b5-4d6a-b7d0-8c7ba15197d1@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <dgfUxezK8cHYQ7EXmGbnzdOiQhkzPi_y0VNOPxQOIcg=.64223d19-51b8-4c63-bb0b-4547b26a305b@github.com>
 <3OvTN_R0PH7pDyYP4OBeqKCWyxXZ6ye8QBOrRi63eLc=.a97b522b-acf9-4d7b-9f5e-db024359b0c7@github.com>
 <c7onyZV6BVQfQP4XV-CZAQlHQSx7RDIyPQDcTNe5iME=.f27aa969-04b5-4d6a-b7d0-8c7ba15197d1@github.com>
Message-ID: <T77clRG4dUIjyyr_MFKqOXsDG8qeVuR7P9M7wbwFH1Q=.513f2949-0337-4682-9a11-2c41fbf031d0@github.com>

On Tue, 22 Mar 2022 08:09:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> > I will push the change through our testing again since so much time and so many changes happened since last time.
> 
> Testing seems good.

Thanks Thomas for reviewing and testing. :)
I'll update the patch soon.

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

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


From ayang at openjdk.java.net  Tue Mar 22 14:02:03 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 22 Mar 2022 14:02:03 GMT
Subject: RFR: 8283513: Parallel: Skip the card marking in PSRootsClosure
Message-ID: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>

This PR consists of two commits:

1. Skip card marking in `PSRootsClosure`
2. Make in-heap `oop*` a precondition of `copy_and_push_safe_barrier`

Test: tier1-3

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

Commit messages:
 - off-heap check
 - ps-root-closure

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

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


From tschatzl at openjdk.java.net  Tue Mar 22 15:47:39 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 22 Mar 2022 15:47:39 GMT
Subject: RFR: 8283513: Parallel: Skip the card marking in PSRootsClosure
In-Reply-To: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
References: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
Message-ID: <Dn7L2PhaP4aDqEHF_TkioWpCYa9K-ro43SxnCCPPc4o=.5a502042-cb30-4d86-ba31-d896240ff6cf@github.com>

On Tue, 22 Mar 2022 13:54:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. Skip card marking in `PSRootsClosure`
> 2. Make in-heap `oop*` a precondition of `copy_and_push_safe_barrier`
> 
> Test: tier1-3

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Tue Mar 22 15:53:33 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 22 Mar 2022 15:53:33 GMT
Subject: RFR: 8283513: Parallel: Skip the card marking in PSRootsClosure
In-Reply-To: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
References: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
Message-ID: <u6HSmH3bYCUBRaQgjlDWuYeYzN8JsZyKmPMIrnGizrw=.f4fc4c18-126f-4f96-8ee1-abd8cd4ebd0b@github.com>

On Tue, 22 Mar 2022 13:54:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. Skip card marking in `PSRootsClosure`
> 2. Make in-heap `oop*` a precondition of `copy_and_push_safe_barrier`
> 
> Test: tier1-3

Marked as reviewed by iwalulya (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Mar 23 10:39:35 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 23 Mar 2022 10:39:35 GMT
Subject: RFR: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template
 parameter
In-Reply-To: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
References: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
Message-ID: <FUAV3cO0hjo7vXXveOMwWeybbkzgA8VxCzuh1sx6jAU=.35f15fb1-619a-4c3a-a4ec-0fc970409d12@github.com>

On Mon, 21 Mar 2022 14:02:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to remove the MEMFLAGS template parameter for G1SegmentedArraySegment and make it a runtime configuration parameter. This reduces on the code bloat due to templating because many of the methods in G1SegmentedArraySegment are independent of the template parameter.
> 
> To achieve this we added factory methods for handling allocation and deallocation. Having the factory methods allows us to embed the array data with the G1SegmentedArraySegment struct thus limiting the allocation to a single allocation as well as the deallocation. One upside to this approach is that we limit the allocation and deallocation overheads. 
> 
> Thanks
> Ivan

Lgtm. Would have been nice to have done the refactoring and the segment inlining separately.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Wed Mar 23 12:22:58 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Mar 2022 12:22:58 GMT
Subject: RFR: 8283558: Parallel: Pass PSIsAliveClosure to ReferenceProcessor
 constructor
Message-ID: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>

Simple change around non-strong ref discovery in young-gc ref-processing.

Test: tier1-6

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

Commit messages:
 - ps-is-alive-closure

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

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


From shade at openjdk.java.net  Wed Mar 23 13:42:56 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 23 Mar 2022 13:42:56 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance
Message-ID: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>

While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 

Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.

On a simple test:


import java.lang.invoke.MethodHandles;
import java.lang.invoke.VarHandle;

public class VHWarmup {

    static final int SIZE = 1_000_000;

    private VarHandle[] vhs;
    private int x;

    public static void main(String... args) throws Exception {
        new VHWarmup().run();
    }

    public void run() throws Exception {
        vhs = new VarHandle[SIZE];
        for (int c = 0; c < SIZE; c++) {
            VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
            vh.get(this);
            vhs[c] = vh;
        }
    }
}


Baseline:


$ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null

 Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):

          1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
               887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
                 6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
            31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
     4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
       168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
       790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
     9,094,235,238      instructions              #    1.93  insn per cycle         
                                                  #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
     1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
         3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)

           1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )


Patched:


$ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null

 Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):

          1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
               860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
                 7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
            31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
     4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
       151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
       604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
     8,517,580,297      instructions              #    1.97  insn per cycle         
                                                  #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
     1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
         4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)

           1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )


Additional testing:
 - [ ] Linux x86_64 fastdebug `tier1`
 - [ ] More benchmarks

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

Commit messages:
 - Cleanups
 - More complete patch
 - Inlining

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

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


From ayang at openjdk.java.net  Wed Mar 23 14:12:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Mar 2022 14:12:32 GMT
Subject: RFR: 8283513: Parallel: Skip the card marking in PSRootsClosure
In-Reply-To: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
References: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
Message-ID: <zV_vvfwba22MjpRIJn_GjyOHB5mwf7lna7Ifvy0uGIc=.7eab5040-ad22-4a1a-816a-412245386959@github.com>

On Tue, 22 Mar 2022 13:54:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. Skip card marking in `PSRootsClosure`
> 2. Make in-heap `oop*` a precondition of `copy_and_push_safe_barrier`
> 
> Test: tier1-3

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Mar 23 14:12:32 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Mar 2022 14:12:32 GMT
Subject: Integrated: 8283513: Parallel: Skip the card marking in PSRootsClosure
In-Reply-To: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
References: <32Hupl1sjJtJ8Gs7Un1WrnngozTxX_b-TW0nCrIBFWo=.0fd1306d-423a-4846-b57c-a32587333589@github.com>
Message-ID: <P3RE9EwmIWMxMYBU-sKb7EXRrGofx4mlVXOdzBG7JSc=.3335e5b5-2a53-4c4f-acd8-aa7a668a3a97@github.com>

On Tue, 22 Mar 2022 13:54:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. Skip card marking in `PSRootsClosure`
> 2. Make in-heap `oop*` a precondition of `copy_and_push_safe_barrier`
> 
> Test: tier1-3

This pull request has now been integrated.

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

8283513: Parallel: Skip the card marking in PSRootsClosure

Reviewed-by: tschatzl, iwalulya

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

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


From tschatzl at openjdk.java.net  Wed Mar 23 16:04:52 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 23 Mar 2022 16:04:52 GMT
Subject: RFR: 8283555: G1: Concurrent mark accesses uninitialized BOT of closed
 archive regions
Message-ID: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>

Hi all,

  please review this change that fixes crashes occurring in the Loom repo because of missing initialization in the BOT of closed archive regions. This is a bug here too, just typically not occurring.

So during marking through the closed archive regions (for statistics mainly) it can happen that there are objects in these closed archive regions that are split into chunks. To get the start of the object that contains this chunk, we use the BOT.

Since it is not initialized for the closed archive regions G1 crashes as that call returns garbage.

The fix is to not only initialize open archive regions, but also closed archive regions.

The problem started with [JDK-8264908](https://bugs.openjdk.java.net/browse/JDK-8264908) which means that there will be a JDK 18 backport.

Testing: failing test with Loom, GHA

Thanks,
  Thomas

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

Commit messages:
 - Initial version, initialize BOT for CA regions

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

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


From ayang at openjdk.java.net  Wed Mar 23 16:12:26 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Mar 2022 16:12:26 GMT
Subject: RFR: 8283555: G1: Concurrent mark accesses uninitialized BOT of
 closed archive regions
In-Reply-To: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
References: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
Message-ID: <JOf6DGhDnY2Ksanz5cfvlbQGhmHjKS5GcCvu0Et51GU=.08f7e20a-357c-4aa7-9aaf-b3d6928bca07@github.com>

On Wed, 23 Mar 2022 15:29:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes crashes occurring in the Loom repo because of missing initialization in the BOT of closed archive regions. This is a bug here too, just typically not occurring.
> 
> So during marking through the closed archive regions (for statistics mainly) it can happen that there are objects in these closed archive regions that are split into chunks. To get the start of the object that contains this chunk, we use the BOT.
> 
> Since it is not initialized for the closed archive regions G1 crashes as that call returns garbage.
> 
> The fix is to not only initialize open archive regions, but also closed archive regions.
> 
> The problem started with [JDK-8264908](https://bugs.openjdk.java.net/browse/JDK-8264908) which means that there will be a JDK 18 backport.
> 
> Testing: failing test with Loom, GHA
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/cds/filemap.cpp line 2333:

> 2331:     G1CollectedHeap::heap()->fill_archive_regions(closed_heap_regions,
> 2332:                                                   num_closed_heap_regions);
> 2333:     // G1 marking uses the BOT for object chunking; for this reason we need to

It would be good to have a reference to the actual method/class name performing "object chunking" in the comment.

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

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


From tschatzl at openjdk.java.net  Wed Mar 23 16:23:07 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 23 Mar 2022 16:23:07 GMT
Subject: RFR: 8283555: G1: Concurrent mark accesses uninitialized BOT of
 closed archive regions [v2]
In-Reply-To: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
References: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
Message-ID: <sUw2YXmx99TnMiQbX9qlCLzU_4j1VgFIozEfbmvoXd8=.e3c67014-a701-4f30-93f8-8bab01def258@github.com>

> Hi all,
> 
>   please review this change that fixes crashes occurring in the Loom repo because of missing initialization in the BOT of closed archive regions. This is a bug here too, just typically not occurring.
> 
> So during marking through the closed archive regions (for statistics mainly) it can happen that there are objects in these closed archive regions that are split into chunks. To get the start of the object that contains this chunk, we use the BOT.
> 
> Since it is not initialized for the closed archive regions G1 crashes as that call returns garbage.
> 
> The fix is to not only initialize open archive regions, but also closed archive regions.
> 
> The problem started with [JDK-8264908](https://bugs.openjdk.java.net/browse/JDK-8264908) which means that there will be a JDK 18 backport.
> 
> Testing: failing test with Loom, GHA
> 
> Thanks,
>   Thomas

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

  Improve comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7923/files
  - new: https://git.openjdk.java.net/jdk/pull/7923/files/ddc51e03..0645bec5

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

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

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


From tschatzl at openjdk.java.net  Wed Mar 23 16:23:27 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 23 Mar 2022 16:23:27 GMT
Subject: RFR: 8283558: Parallel: Pass PSIsAliveClosure to
 ReferenceProcessor constructor
In-Reply-To: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
References: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
Message-ID: <9Ntw3GewkRvb30CGja2OryRvtFCjTkCT82bjs7uaEY0=.09cbeacc-6738-40fb-b311-a18b57f9fdb9@github.com>

On Wed, 23 Mar 2022 12:17:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around non-strong ref discovery in young-gc ref-processing.
> 
> Test: tier1-6

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Wed Mar 23 16:55:28 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 23 Mar 2022 16:55:28 GMT
Subject: RFR: 8283555: G1: Concurrent mark accesses uninitialized BOT of
 closed archive regions [v2]
In-Reply-To: <sUw2YXmx99TnMiQbX9qlCLzU_4j1VgFIozEfbmvoXd8=.e3c67014-a701-4f30-93f8-8bab01def258@github.com>
References: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
 <sUw2YXmx99TnMiQbX9qlCLzU_4j1VgFIozEfbmvoXd8=.e3c67014-a701-4f30-93f8-8bab01def258@github.com>
Message-ID: <Uv4bFtkJD8-o1EbdoT32bYOpCIaVk-FJcHd4RV5VLmE=.5006e751-2a25-4bd8-934e-c947568e763f@github.com>

On Wed, 23 Mar 2022 16:23:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that fixes crashes occurring in the Loom repo because of missing initialization in the BOT of closed archive regions. This is a bug here too, just typically not occurring.
>> 
>> So during marking through the closed archive regions (for statistics mainly) it can happen that there are objects in these closed archive regions that are split into chunks. To get the start of the object that contains this chunk, we use the BOT.
>> 
>> Since it is not initialized for the closed archive regions G1 crashes as that call returns garbage.
>> 
>> The fix is to not only initialize open archive regions, but also closed archive regions.
>> 
>> The problem started with [JDK-8264908](https://bugs.openjdk.java.net/browse/JDK-8264908) which means that there will be a JDK 18 backport.
>> 
>> Testing: failing test with Loom, GHA
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Mar 24 09:17:52 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 24 Mar 2022 09:17:52 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance
In-Reply-To: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
Message-ID: <W0EcbstHm-Khm55_6fPa_N5hP_HVgCLaBtxHN3HNKi4=.44c56f3e-c04a-4a7a-93b6-245be9e34975@github.com>

On Wed, 23 Mar 2022 13:34:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 
> 
> Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.
> 
> On a simple test:
> 
> 
> import java.lang.invoke.MethodHandles;
> import java.lang.invoke.VarHandle;
> 
> public class VHWarmup {
> 
>     static final int SIZE = 1_000_000;
> 
>     private VarHandle[] vhs;
>     private int x;
> 
>     public static void main(String... args) throws Exception {
>         new VHWarmup().run();
>     }
> 
>     public void run() throws Exception {
>         vhs = new VarHandle[SIZE];
>         for (int c = 0; c < SIZE; c++) {
>             VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
>             vh.get(this);
>             vhs[c] = vh;
>         }
>     }
> }
> 
> 
> Baseline:
> 
> 
> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
> 
>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
> 
>           1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
>                887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
>                  6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
>             31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
>      4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
>        168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
>        790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
>      9,094,235,238      instructions              #    1.93  insn per cycle         
>                                                   #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
>      1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
>          3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)
> 
>            1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )
> 
> 
> Patched:
> 
> 
> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
> 
>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
> 
>           1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
>                860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
>                  7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
>             31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
>      4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
>        151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
>        604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
>      8,517,580,297      instructions              #    1.97  insn per cycle         
>                                                   #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
>      1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
>          4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)
> 
>            1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier2`
>  - [x] SPECjvm2008 shows no regressions

Maybe rename `enqueue_oop` to `enqueue_not_null`? This is a fairly common naming scheme for methods specialized that way.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Mar 24 10:02:08 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 24 Mar 2022 10:02:08 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v16]
In-Reply-To: <-fRDKf14vBIjHeBjqxT71g_KSY919fi6ihnqkBw6g3g=.bd65fd9b-2d41-44cf-9d77-e51ff0a99c49@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <-fRDKf14vBIjHeBjqxT71g_KSY919fi6ihnqkBw6g3g=.bd65fd9b-2d41-44cf-9d77-e51ff0a99c49@github.com>
Message-ID: <GrqdCYdnCXjsjsM1E99Fo8w7h1MxUky66E0oHIhpXI0=.31d63a6f-6265-48b0-94d5-4a0824f2b00c@github.com>

On Tue, 22 Mar 2022 12:13:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary method

This looks good to me, with some final cleanup comments. Apologies for taking a bit.

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

> 104:       assert(_evac_failure_regions->contains(hr->hrm_index()), "precondition");
> 105: 
> 106:       hr->clear_index_in_opt_cset();

One optional suggestion: Let's also move this into `HeapRegion::note_self_forwarding_removal_start`. It seems so lonely here for that trivial assignment, right now better fitting over there so that this preparation only deals with the more expensive remembered sets.

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

> 112: 
> 113:       hr->rem_set()->clean_code_roots(hr);
> 114:       hr->rem_set()->clear_locked(true);

Suggestion:

      HeapRegionRemSet* rem_set = hr->rem_set();
      rem_set->clean_code_roots(hr);
      rem_set->clear_locked(true);

Optional cleanup.

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 71:

> 69:   chunk_closure->do_heap_region_chunk(&chunk);
> 70:   p->record_or_add_time_secs(G1GCPhaseTimes::RemoveSelfForwardsInChunks, worker_id, (Ticks::now() - start).seconds());
> 71: }

Suggestion:

  G1CollectedHeap* glh = G1CollectedHeap::heap();
  G1GCPhaseTimes* p = glh->phase_times();

  // Prepare and analyze assigned chunk.
  Ticks chunk_prepare_start = Ticks::now();
  uint region_idx = _evac_failure_regions[chunk_id / _chunks_per_region];
  G1HeapRegionChunk chunk(glh->region_at(region_idx), chunk_id % _chunks_per_region, _chunk_size, _bitmap);
  p->record_or_add_time_secs(G1GCPhaseTimes::PrepareChunks, worker_id, (Ticks::now() - chunk_prepare_start).seconds());

  if (chunk.empty()) {
    p->record_or_add_thread_work_item(G1GCPhaseTimes::RemoveSelfForwardsInChunks, worker_id, 1, G1GCPhaseTimes::RemoveSelfForwardEmptyChunksNum);
    return;
  }
  p->record_or_add_thread_work_item(G1GCPhaseTimes::RemoveSelfForwardsInChunks, worker_id, 1, G1GCPhaseTimes::RemoveSelfForwardChunksNum);

  // Process the chunk.
  Ticks start = Ticks::now();
  chunk_closure->do_heap_region_chunk(&chunk);
  p->record_or_add_time_secs(G1GCPhaseTimes::RemoveSelfForwardsInChunks, worker_id, (Ticks::now() - start).seconds());
}

That method looks so busy, I tried improving it by adding newlines.

src/hotspot/share/gc/g1/g1HeapRegionChunk.cpp line 84:

> 82:   log_debug(gc, ergo)("Running %s using %u workers for removing self forwards with %u chunks per region",
> 83:                       task_name, num_workers, _chunk_size);
> 84: 

Suggestion:

  log_debug(gc, ergo)("Initializing removing self forwards with %u chunks per region given %u workers", _chunk_size, num_workers);


Since we successfully moved this work into the `G1BatchedGangTask` API, I do not think we need the information about the task and #workers any more. The batch API provides this information afair.
This also allows removal of the `task_name` passed through.

src/hotspot/share/gc/g1/g1HeapRegionChunk.hpp line 35:

> 33: class HeapRegion;
> 34: 
> 35: class G1HeapRegionChunk {

Suggestion:

// Unit of work for removing self forwards in regions.
class G1HeapRegionChunk {

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

Changes requested by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Thu Mar 24 10:09:46 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Mar 2022 10:09:46 GMT
Subject: RFR: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template
 parameter
In-Reply-To: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
References: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
Message-ID: <id7H5zK8bKJUZ6fVM9zxI7Hwoc2RvBKwpB22KKc6NxQ=.d5544ac6-24b8-48ae-94d1-4e4e7c7a25d1@github.com>

On Mon, 21 Mar 2022 14:02:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to remove the MEMFLAGS template parameter for G1SegmentedArraySegment and make it a runtime configuration parameter. This reduces on the code bloat due to templating because many of the methods in G1SegmentedArraySegment are independent of the template parameter.
> 
> To achieve this we added factory methods for handling allocation and deallocation. Having the factory methods allows us to embed the array data with the G1SegmentedArraySegment struct thus limiting the allocation to a single allocation as well as the deallocation. One upside to this approach is that we limit the allocation and deallocation overheads. 
> 
> Thanks
> Ivan

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/g1/g1SegmentedArray.cpp line 107:

> 105: 
> 106:     next = G1SegmentedArraySegment::create_segment(slot_size(), num_slots, prev, _alloc_options->mem_flag());
> 107:     // next = new G1SegmentedArraySegment(slot_size(), num_slots, prev);

Seems unneeded.

src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 116:

> 114:     return segment.next_addr();
> 115:   }
> 116:   typedef LockFreeStack<G1SegmentedArraySegment, &G1SegmentedArrayFreeList::next_ptr> SegmentStack;

`using` to be consistent?

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

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


From iwalulya at openjdk.java.net  Thu Mar 24 10:27:28 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 24 Mar 2022 10:27:28 GMT
Subject: RFR: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template
 parameter [v2]
In-Reply-To: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
References: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
Message-ID: <r9v4DvJMPUkUlUqdwo39l_WBaIecUomQA4cn3IRkaLk=.1bd46bf7-068c-43e4-9ec1-b0c86924205b@github.com>

> Hi all,
> 
> Please review this change to remove the MEMFLAGS template parameter for G1SegmentedArraySegment and make it a runtime configuration parameter. This reduces on the code bloat due to templating because many of the methods in G1SegmentedArraySegment are independent of the template parameter.
> 
> To achieve this we added factory methods for handling allocation and deallocation. Having the factory methods allows us to embed the array data with the G1SegmentedArraySegment struct thus limiting the allocation to a single allocation as well as the deallocation. One upside to this approach is that we limit the allocation and deallocation overheads. 
> 
> Thanks
> Ivan

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7891/files
  - new: https://git.openjdk.java.net/jdk/pull/7891/files/ea77e81b..c1f80a9f

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

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

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


From tschatzl at openjdk.java.net  Thu Mar 24 10:41:41 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 24 Mar 2022 10:41:41 GMT
Subject: RFR: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template
 parameter [v2]
In-Reply-To: <r9v4DvJMPUkUlUqdwo39l_WBaIecUomQA4cn3IRkaLk=.1bd46bf7-068c-43e4-9ec1-b0c86924205b@github.com>
References: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
 <r9v4DvJMPUkUlUqdwo39l_WBaIecUomQA4cn3IRkaLk=.1bd46bf7-068c-43e4-9ec1-b0c86924205b@github.com>
Message-ID: <uZgnxhm04jCBMkCAM69ipk1gi5Sr67pFu030nO2bfmA=.6b806e2e-fa29-45ae-a344-fca737c0a31f@github.com>

On Thu, 24 Mar 2022 10:27:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to remove the MEMFLAGS template parameter for G1SegmentedArraySegment and make it a runtime configuration parameter. This reduces on the code bloat due to templating because many of the methods in G1SegmentedArraySegment are independent of the template parameter.
>> 
>> To achieve this we added factory methods for handling allocation and deallocation. Having the factory methods allows us to embed the array data with the G1SegmentedArraySegment struct thus limiting the allocation to a single allocation as well as the deallocation. One upside to this approach is that we limit the allocation and deallocation overheads. 
>> 
>> Thanks
>> Ivan
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Thu Mar 24 14:39:48 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 24 Mar 2022 14:39:48 GMT
Subject: RFR: 8283555: G1: Concurrent mark accesses uninitialized BOT of
 closed archive regions [v2]
In-Reply-To: <JOf6DGhDnY2Ksanz5cfvlbQGhmHjKS5GcCvu0Et51GU=.08f7e20a-357c-4aa7-9aaf-b3d6928bca07@github.com>
References: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
 <JOf6DGhDnY2Ksanz5cfvlbQGhmHjKS5GcCvu0Et51GU=.08f7e20a-357c-4aa7-9aaf-b3d6928bca07@github.com>
Message-ID: <0Jmi8dbuzC9d6vVBmzxU5HDHVAuN7n3Ce19uJ9Xz0bc=.a8e1dff2-e448-4697-9516-e2595d43ae81@github.com>

On Wed, 23 Mar 2022 16:09:45 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:
>> 
>>   Improve comment
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @walulyai for your reviews

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

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


From tschatzl at openjdk.java.net  Thu Mar 24 14:39:49 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 24 Mar 2022 14:39:49 GMT
Subject: Integrated: 8283555: G1: Concurrent mark accesses uninitialized BOT of
 closed archive regions
In-Reply-To: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
References: <jql-_BS4V8VekYKqdk5VNxoCfCNnKfi7L_LWTdXC_hM=.e9dd8906-d79d-42cd-aadb-a6a784997e17@github.com>
Message-ID: <NgMwVvJ4rF_qeZqVkwgTuy9AkwKH0heSKPl0jmTuFO8=.5a2edbf8-f8d8-44ab-aa36-adfbbdab508f@github.com>

On Wed, 23 Mar 2022 15:29:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes crashes occurring in the Loom repo because of missing initialization in the BOT of closed archive regions. This is a bug here too, just typically not occurring.
> 
> So during marking through the closed archive regions (for statistics mainly) it can happen that there are objects in these closed archive regions that are split into chunks. To get the start of the object that contains this chunk, we use the BOT.
> 
> Since it is not initialized for the closed archive regions G1 crashes as that call returns garbage.
> 
> The fix is to not only initialize open archive regions, but also closed archive regions.
> 
> The problem started with [JDK-8264908](https://bugs.openjdk.java.net/browse/JDK-8264908) which means that there will be a JDK 18 backport.
> 
> Testing: failing test with Loom, GHA
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 19f01ab7
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/19f01ab70133d244422684f63f118249178bce4a
Stats:     10 lines in 1 file changed: 5 ins; 5 del; 0 mod

8283555: G1: Concurrent mark accesses uninitialized BOT of closed archive regions

Reviewed-by: ayang, iwalulya

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

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


From shade at openjdk.java.net  Thu Mar 24 19:37:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 24 Mar 2022 19:37:40 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance
In-Reply-To: <W0EcbstHm-Khm55_6fPa_N5hP_HVgCLaBtxHN3HNKi4=.44c56f3e-c04a-4a7a-93b6-245be9e34975@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <W0EcbstHm-Khm55_6fPa_N5hP_HVgCLaBtxHN3HNKi4=.44c56f3e-c04a-4a7a-93b6-245be9e34975@github.com>
Message-ID: <5fjhk4m3vZhXF4YkNBGOwR3nLbxFmZi-N8wE9n6Xahs=.afc483ab-941e-4d0a-8489-672db9ff7d45@github.com>

On Thu, 24 Mar 2022 09:14:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Maybe rename `enqueue_oop` to `enqueue_not_null`? This is a fairly common naming scheme for methods specialized that way.

Thing is, it is not about nullity. It is about whether we have already loaded the oop or not. Maybe `enqueue_loaded`?

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

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


From tschatzl at openjdk.java.net  Fri Mar 25 09:14:41 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 25 Mar 2022 09:14:41 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance
In-Reply-To: <5fjhk4m3vZhXF4YkNBGOwR3nLbxFmZi-N8wE9n6Xahs=.afc483ab-941e-4d0a-8489-672db9ff7d45@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <W0EcbstHm-Khm55_6fPa_N5hP_HVgCLaBtxHN3HNKi4=.44c56f3e-c04a-4a7a-93b6-245be9e34975@github.com>
 <5fjhk4m3vZhXF4YkNBGOwR3nLbxFmZi-N8wE9n6Xahs=.afc483ab-941e-4d0a-8489-672db9ff7d45@github.com>
Message-ID: <Md1hyJ1lTHGrc5Z15x_o4QT8gorlbd7Qg_dzM9U5_6U=.01ee98fe-cc50-4e64-b654-05bfb669e6c4@github.com>

On Thu, 24 Mar 2022 19:34:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thing is, it is not about nullity. It is about whether we have already loaded the oop or not. Maybe `enqueue_loaded`?

Okay.

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

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


From iwalulya at openjdk.java.net  Fri Mar 25 09:44:47 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 25 Mar 2022 09:44:47 GMT
Subject: RFR: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template
 parameter [v2]
In-Reply-To: <id7H5zK8bKJUZ6fVM9zxI7Hwoc2RvBKwpB22KKc6NxQ=.d5544ac6-24b8-48ae-94d1-4e4e7c7a25d1@github.com>
References: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
 <id7H5zK8bKJUZ6fVM9zxI7Hwoc2RvBKwpB22KKc6NxQ=.d5544ac6-24b8-48ae-94d1-4e4e7c7a25d1@github.com>
Message-ID: <Ypd1TjpYieTJznz-SIKBIRX0Y61v2JsUe5S5-Y55ams=.e19390e9-d047-4a5b-9374-be3de2d9817c@github.com>

On Thu, 24 Mar 2022 10:06:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert review
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk and @tschatzl  for the reviews.

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

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


From iwalulya at openjdk.java.net  Fri Mar 25 09:44:48 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 25 Mar 2022 09:44:48 GMT
Subject: Integrated: 8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS
 template parameter
In-Reply-To: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
References: <NEr2KZaTkAJoD7_l0J_B7dKkShcBSuQzs6q8MJ0IM_E=.7b17434a-848c-45d4-9185-6ff1a6aa222e@github.com>
Message-ID: <Nrf0Vwgun0CSrUOnUWcaOYiga9NljYA3PGgsU9BSbGM=.76b2c111-7a38-4cae-938c-25da5521b4ee@github.com>

On Mon, 21 Mar 2022 14:02:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to remove the MEMFLAGS template parameter for G1SegmentedArraySegment and make it a runtime configuration parameter. This reduces on the code bloat due to templating because many of the methods in G1SegmentedArraySegment are independent of the template parameter.
> 
> To achieve this we added factory methods for handling allocation and deallocation. Having the factory methods allows us to embed the array data with the G1SegmentedArraySegment struct thus limiting the allocation to a single allocation as well as the deallocation. One upside to this approach is that we limit the allocation and deallocation overheads. 
> 
> Thanks
> Ivan

This pull request has now been integrated.

Changeset: 70648a6a
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70648a6a153e5d321f78cf6445a9703f41083725
Stats:     583 lines in 9 files changed: 271 ins; 239 del; 73 mod

8283368: G1: Remove G1SegmentedArraySegment MEMFLAGS template parameter

Reviewed-by: tschatzl, ayang

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

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


From mli at openjdk.java.net  Fri Mar 25 14:19:34 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 25 Mar 2022 14:19:34 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v17]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <NHa1GapUYmG5d8d2SFhezD5XhJQQrner53M0liSiKpg=.b071aa3e-1aef-4884-9a43-04766bbba187@github.com>

> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
> 
> This patch tries to improve parallelism when walking over the regions in chunks
> 
> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
> 
> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
> 
> The performance benefit trend is:
>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
> ( Other common Evacuation Failure configurations are:
> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
> 
> For more detailed performance data, please check the related bug.

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

  some cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/391fdced..66fd5af6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=15-16

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

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


From mli at openjdk.java.net  Fri Mar 25 14:19:34 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 25 Mar 2022 14:19:34 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v16]
In-Reply-To: <-fRDKf14vBIjHeBjqxT71g_KSY919fi6ihnqkBw6g3g=.bd65fd9b-2d41-44cf-9d77-e51ff0a99c49@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <-fRDKf14vBIjHeBjqxT71g_KSY919fi6ihnqkBw6g3g=.bd65fd9b-2d41-44cf-9d77-e51ff0a99c49@github.com>
Message-ID: <stbH23Tnr7Y68s3RMYrkVbdXsauhMOHmCwZcbGMVqhk=.9f0d166c-d33d-4d08-80a0-d59996105e1d@github.com>

On Tue, 22 Mar 2022 12:13:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up.
>> 
>> This patch tries to improve parallelism when walking over the regions in chunks
>> 
>> Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs.
>> 
>> Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.)
>> 
>> The performance benefit trend is:
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8)
>>  - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=<default=123>)
>> ( Other common Evacuation Failure configurations are:
>> -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 )
>> 
>> For more detailed performance data, please check the related bug.
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary method

Thanks, it's fine :). I've just updated the patch as suggested.

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

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


From duke at openjdk.java.net  Fri Mar 25 15:14:52 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 25 Mar 2022 15:14:52 GMT
Subject: Withdrawn: 8280579: Shenandoah: Skip regions in the back of sorted
 array when choosing cset
In-Reply-To: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
References: <nYLzGTgyJJz-nMksbGNBfbx0UwAErHfGY_IjBrtNjGA=.4dd14581-063d-4b50-aa25-1cbcf6d6474c@github.com>
Message-ID: <KEFFcI8zAYfNtDvAzGeKLyNbIYfwzbhFgnFSsJWXTO0=.3114f53c-a620-40a8-b95f-2d068d7ba9fa@github.com>

On Tue, 25 Jan 2022 10:10:04 GMT, Yude Lin <duke at openjdk.java.net> wrote:

> Can I have review on this small change that skips some unnecessary work in cset choosing?
> 
> When choosing regions to add to cset, we sort the regions from most garbage to least garbage. We then iterate the sorted array. We can break early from the loop if we find a region with (garbage <= garbage_threshold). Because we know the regions left won't have enough garbage and won't be added anyway.

This pull request has been closed without being integrated.

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

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


From kbarrett at openjdk.java.net  Fri Mar 25 19:10:49 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 25 Mar 2022 19:10:49 GMT
Subject: RFR: 8283558: Parallel: Pass PSIsAliveClosure to
 ReferenceProcessor constructor
In-Reply-To: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
References: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
Message-ID: <7KYIWfxDscHsaNxyxvaFbm_CNSMgNoGhtwA9UWw8jJk=.c22149d3-1fe6-497d-bd10-c9b3c9938a08@github.com>

On Wed, 23 Mar 2022 12:17:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around non-strong ref discovery in young-gc ref-processing.
> 
> Test: tier1-6

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Mon Mar 28 08:03:47 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 28 Mar 2022 08:03:47 GMT
Subject: RFR: 8283558: Parallel: Pass PSIsAliveClosure to
 ReferenceProcessor constructor
In-Reply-To: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
References: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
Message-ID: <bBtuD3XTU6YOee6UANVq5fAiqOWmuxgsqgkmMQS8rtQ=.78505946-ab17-49c8-ae8c-54af86491cf3@github.com>

On Wed, 23 Mar 2022 12:17:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around non-strong ref discovery in young-gc ref-processing.
> 
> Test: tier1-6

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Mar 28 08:03:47 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 28 Mar 2022 08:03:47 GMT
Subject: Integrated: 8283558: Parallel: Pass PSIsAliveClosure to
 ReferenceProcessor constructor
In-Reply-To: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
References: <JrDF_BA0nkAiUD9cqK4QGHqH_hIRLY82zrRMqaWjXFI=.443a5457-0d1e-4ecf-9fba-215eb8d88860@github.com>
Message-ID: <XLegENmxOPCPjxTWI3JvuWbj_NeugdSnrFwl80uwAAo=.78c4e25a-7aaf-4c66-b23f-6b3a46dbf7a1@github.com>

On Wed, 23 Mar 2022 12:17:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around non-strong ref discovery in young-gc ref-processing.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: 7f125373
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7f125373a7f178d2ae7ebefe58a3a47b2792fcb6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283558: Parallel: Pass PSIsAliveClosure to ReferenceProcessor constructor

Reviewed-by: tschatzl, kbarrett

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

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


From shade at openjdk.java.net  Mon Mar 28 11:04:30 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Mar 2022 11:04:30 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v2]
In-Reply-To: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
Message-ID: <1hkS9KYWWiQXJAon8pmy2YMAwET419pRhrn2jG2ootg=.58239091-7cc6-49c5-9863-44cd19f7aad3@github.com>

> While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 
> 
> Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.
> 
> On a simple test:
> 
> 
> import java.lang.invoke.MethodHandles;
> import java.lang.invoke.VarHandle;
> 
> public class VHWarmup {
> 
>     static final int SIZE = 1_000_000;
> 
>     private VarHandle[] vhs;
>     private int x;
> 
>     public static void main(String... args) throws Exception {
>         new VHWarmup().run();
>     }
> 
>     public void run() throws Exception {
>         vhs = new VarHandle[SIZE];
>         for (int c = 0; c < SIZE; c++) {
>             VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
>             vh.get(this);
>             vhs[c] = vh;
>         }
>     }
> }
> 
> 
> Baseline:
> 
> 
> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
> 
>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
> 
>           1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
>                887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
>                  6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
>             31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
>      4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
>        168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
>        790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
>      9,094,235,238      instructions              #    1.93  insn per cycle         
>                                                   #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
>      1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
>          3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)
> 
>            1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )
> 
> 
> Patched:
> 
> 
> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
> 
>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
> 
>           1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
>                860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
>                  7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
>             31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
>      4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
>        151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
>        604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
>      8,517,580,297      instructions              #    1.97  insn per cycle         
>                                                   #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
>      1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
>          4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)
> 
>            1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier2`
>  - [x] SPECjvm2008 shows no regressions

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

 - enqueue_loc
 - Merge branch 'master' into JDK-8283566-g1-enqueue
 - Cleanups
 - More complete patch
 - Inlining

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7921/files
  - new: https://git.openjdk.java.net/jdk/pull/7921/files/76b54655..cdfd7891

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

  Stats: 64376 lines in 470 files changed: 61853 ins; 722 del; 1801 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7921.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7921/head:pull/7921

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


From shade at openjdk.java.net  Mon Mar 28 11:04:30 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Mar 2022 11:04:30 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v2]
In-Reply-To: <Md1hyJ1lTHGrc5Z15x_o4QT8gorlbd7Qg_dzM9U5_6U=.01ee98fe-cc50-4e64-b654-05bfb669e6c4@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <W0EcbstHm-Khm55_6fPa_N5hP_HVgCLaBtxHN3HNKi4=.44c56f3e-c04a-4a7a-93b6-245be9e34975@github.com>
 <5fjhk4m3vZhXF4YkNBGOwR3nLbxFmZi-N8wE9n6Xahs=.afc483ab-941e-4d0a-8489-672db9ff7d45@github.com>
 <Md1hyJ1lTHGrc5Z15x_o4QT8gorlbd7Qg_dzM9U5_6U=.01ee98fe-cc50-4e64-b654-05bfb669e6c4@github.com>
Message-ID: <8J2UK1qTdNiz5HBd8CGMxhdECxvU_qWuadF7wzskRoc=.055ed4f4-8bc4-4195-930a-812f23854467@github.com>

On Fri, 25 Mar 2022 09:11:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> > Thing is, it is not about nullity. It is about whether we have already loaded the oop or not. Maybe `enqueue_loaded`?
> 
> Okay.

After some back and forth, I settled on `enqueue_loc` for new method. This matches some of the related methods we have in Shenandoah. This also simplifies the patch.

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

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


From vishalchand2492 at gmail.com  Mon Mar 28 12:55:22 2022
From: vishalchand2492 at gmail.com (Vishal Chand)
Date: Mon, 28 Mar 2022 18:25:22 +0530
Subject: JDK-8277373: Make maximum card table size dependent on
 ObjectAlignmentInBytes
Message-ID: <CAJWYcHiWV807gd3T66b4DVXpHOEB0xomJ2+a7W_=fYjq+j1gdg@mail.gmail.com>

Hi,

This is regarding the open issue - JDK-8277373
<https://bugs.openjdk.java.net/browse/JDK-8277373>.
By making the necessary changes to the code and running a test program with
G1GC, CardSize=2048, ObjectAlignment=16, I observed the following guarantee
in
*/home/javauser/vishal/jdk_dev/jdk/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp:175*
failing -  guarantee(_bot->offset_array(start_card) ==
BOTConstants::card_size_in_words()) failed: Wrong value in second card. 0
observed, 256 expected. This is expected as a bot entry is only 1 byte.

Digging deeper into the code made it clear that the HeapWord size puts the
restriction on max. card size to 1024 bytes on 64-bit machines and 512
bytes on 32-bit machines.

There are two options to proceed from here:

   1. Increase the bot entry size. Seems like a straightforward change with
   straightforward issues.
   2. Introduce ObjectAlignment in offset calculations. Seems like this was
   the original goal of  JDK-8277373
   <https://bugs.openjdk.java.net/browse/JDK-8277373>.

Is there any other option that might have been missed and which option
would be preferred? Looking forward to hearing from the community soon.

Thanks and Regards,
Vishal


From ayang at openjdk.java.net  Mon Mar 28 13:41:01 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 28 Mar 2022 13:41:01 GMT
Subject: RFR: 8283790: G1: Remove redundant card/heap-address transition
Message-ID: <dhwAft3Lp0LJuKeigwur9hcShbuMdRzsOqmYo5uYRRE=.6741aeae-5aad-489b-bf4e-632b6a3f54bf@github.com>

Simple change of removing some unnecessary code.

(Also checked the assembly in `release` build and these redundant transitions are *not* optimized away.)

Test: hotspot_gc

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

Commit messages:
 - g1-bot-cleanup

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

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


From thomas.schatzl at oracle.com  Mon Mar 28 15:26:43 2022
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 28 Mar 2022 17:26:43 +0200
Subject: JDK-8277373: Make maximum card table size dependent on
 ObjectAlignmentInBytes
In-Reply-To: <CAJWYcHiWV807gd3T66b4DVXpHOEB0xomJ2+a7W_=fYjq+j1gdg@mail.gmail.com>
References: <CAJWYcHiWV807gd3T66b4DVXpHOEB0xomJ2+a7W_=fYjq+j1gdg@mail.gmail.com>
Message-ID: <e5be1e3c-0041-8ee5-ff69-818f1f314463@oracle.com>

Hi,

On 28.03.22 14:55, Vishal Chand wrote:
> Hi,
> 
> This is regarding the open issue - JDK-8277373 
> <https://bugs.openjdk.java.net/browse/JDK-8277373>.
> By making the necessary changes to the code and running a test program 
> with G1GC, CardSize=2048, ObjectAlignment=16, I observed the following 
> guarantee in 
> //home/javauser/vishal/jdk_dev/jdk/src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp:175/ 
> failing - guarantee(_bot->offset_array(start_card) == 
> BOTConstants::card_size_in_words()) failed: Wrong value in second card. 
> 0 observed, 256 expected. This is expected as a bot entry is only 1 byte.
> 
> Digging deeper into the code made it?clear that the HeapWord size puts 
> the restriction on max. card size to 1024 bytes on 64-bit machines and 
> 512 bytes on 32-bit machines.
> 
> There are two options to proceed from here:
> 
>  1. Increase the?bot entry size. Seems like a straightforward change
>     with straightforward issues.
>  2. Introduce ObjectAlignment in offset calculations. Seems like this
>     was the original goal of JDK-8277373
>     <https://bugs.openjdk.java.net/browse/JDK-8277373>.
> 
> Is there any?other option that might have been missed and which option 
> would be preferred? Looking forward to hearing from the community soon.
> 

   it is preferred to avoid the additional significant memory overhead 
by doubling card table entry size. This seems to be a fairly uncommon 
use case. So please investigate approach 2 first.

Thanks,
   Thomas

Thanks,
   Thomas


From tschatzl at openjdk.java.net  Mon Mar 28 15:40:49 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 28 Mar 2022 15:40:49 GMT
Subject: RFR: 8283790: G1: Remove redundant card/heap-address transition
In-Reply-To: <dhwAft3Lp0LJuKeigwur9hcShbuMdRzsOqmYo5uYRRE=.6741aeae-5aad-489b-bf4e-632b6a3f54bf@github.com>
References: <dhwAft3Lp0LJuKeigwur9hcShbuMdRzsOqmYo5uYRRE=.6741aeae-5aad-489b-bf4e-632b6a3f54bf@github.com>
Message-ID: <BZD_SPzfyLklaki_6PP81_2omGWtLygmZR-fAzOaqww=.5c47a8bc-7d8f-4d56-a1b2-c450cbe0949f@github.com>

On Mon, 28 Mar 2022 13:18:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing some unnecessary code.
> 
> (Also checked the assembly in `release` build and these redundant transitions are *not* optimized away.)
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

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

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


From ayang at openjdk.java.net  Mon Mar 28 16:04:21 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 28 Mar 2022 16:04:21 GMT
Subject: RFR: 8283791: Parallel: Remove unnecessary condition in
 PSKeepAliveClosure
Message-ID: <awfurJpI313ZfXo3mPuy6_Fvw9e-xJRhf2wc5tO9QbE=.15a5ae78-be0e-467d-b6f5-865d1c85fa89@github.com>

Simple change of removing an unnecessary if-check.

Test: tier1-3, hotspot_gc

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

Commit messages:
 - pgc-weak-keep-alive

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

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


From dholmes at openjdk.java.net  Tue Mar 29 07:06:38 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 29 Mar 2022 07:06:38 GMT
Subject: RFR: 8280761: UseCompressedOops should be set after
 limit_heap_by_allocatable_memory
In-Reply-To: <AShYPY_uDfuJiGmpfli6QVD3UT3wTIKso7iOKSYkQt8=.e0c781b5-3c70-40c0-9629-c89771f18b10@github.com>
References: <AShYPY_uDfuJiGmpfli6QVD3UT3wTIKso7iOKSYkQt8=.e0c781b5-3c70-40c0-9629-c89771f18b10@github.com>
Message-ID: <pGUmfY-UxG72RNfH47hct5KZp7UjnO55cbomozsaXDc=.82bb3895-27ab-4c6b-9faf-cbc3cc3dc7f0@github.com>

On Thu, 24 Mar 2022 06:52:34 GMT, KIRIYAMA Takuya <duke at openjdk.java.net> wrote:

> I fixed to set UseCompressedOops flag after limit_heap_by_allocatable_memory(). 
> So when ulimit -v is called and -XX:MaxRAM is set, UseCompressedOops does not become false. 
> And all hotspot tier1 test are passed.
> Would you please review this fix?

I cc'd hotspot-gc as they should probably be the ones to look at this for you.

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

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


From tschatzl at openjdk.java.net  Tue Mar 29 09:57:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 29 Mar 2022 09:57:42 GMT
Subject: RFR: 8283791: Parallel: Remove unnecessary condition in
 PSKeepAliveClosure
In-Reply-To: <awfurJpI313ZfXo3mPuy6_Fvw9e-xJRhf2wc5tO9QbE=.15a5ae78-be0e-467d-b6f5-865d1c85fa89@github.com>
References: <awfurJpI313ZfXo3mPuy6_Fvw9e-xJRhf2wc5tO9QbE=.15a5ae78-be0e-467d-b6f5-865d1c85fa89@github.com>
Message-ID: <I1M5o9apxwffBC1Fwk16wuHJ8GU-B3C-b5b6X6-z5ow=.eb21581c-dd7f-4347-a561-5525190a6a83@github.com>

On Mon, 28 Mar 2022 15:57:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary if-check.
> 
> Test: tier1-3, hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Tue Mar 29 14:43:54 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 29 Mar 2022 14:43:54 GMT
Subject: RFR: 8283791: Parallel: Remove unnecessary condition in
 PSKeepAliveClosure
In-Reply-To: <awfurJpI313ZfXo3mPuy6_Fvw9e-xJRhf2wc5tO9QbE=.15a5ae78-be0e-467d-b6f5-865d1c85fa89@github.com>
References: <awfurJpI313ZfXo3mPuy6_Fvw9e-xJRhf2wc5tO9QbE=.15a5ae78-be0e-467d-b6f5-865d1c85fa89@github.com>
Message-ID: <P3nPK--4VIlwYoQmi87r-Vekg1TnmlA846xzSAPGF5s=.0f15704b-513b-4273-92e7-46d1efa715fb@github.com>

On Mon, 28 Mar 2022 15:57:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing an unnecessary if-check.
> 
> Test: tier1-3, hotspot_gc

Marked as reviewed by iwalulya (Reviewer).

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

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


From shade at openjdk.java.net  Wed Mar 30 07:45:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 07:45:45 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v2]
In-Reply-To: <8J2UK1qTdNiz5HBd8CGMxhdECxvU_qWuadF7wzskRoc=.055ed4f4-8bc4-4195-930a-812f23854467@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <W0EcbstHm-Khm55_6fPa_N5hP_HVgCLaBtxHN3HNKi4=.44c56f3e-c04a-4a7a-93b6-245be9e34975@github.com>
 <5fjhk4m3vZhXF4YkNBGOwR3nLbxFmZi-N8wE9n6Xahs=.afc483ab-941e-4d0a-8489-672db9ff7d45@github.com>
 <Md1hyJ1lTHGrc5Z15x_o4QT8gorlbd7Qg_dzM9U5_6U=.01ee98fe-cc50-4e64-b654-05bfb669e6c4@github.com>
 <8J2UK1qTdNiz5HBd8CGMxhdECxvU_qWuadF7wzskRoc=.055ed4f4-8bc4-4195-930a-812f23854467@github.com>
Message-ID: <-MS9ULwvSmvVqQ4FZ8BwpgqkQWZFpfMoILyqycyQTIY=.17fcea21-52b8-421c-aae8-e96f7399a8cd@github.com>

On Mon, 28 Mar 2022 11:00:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > > Thing is, it is not about nullity. It is about whether we have already loaded the oop or not. Maybe `enqueue_loaded`?
> > 
> > 
> > Okay.
> 
> After some back and forth, I settled on `enqueue_loc` for new method. This matches some of the related methods we have in Shenandoah. This also simplifies the patch.

Any opinions about this version?

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

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


From ayang at openjdk.java.net  Wed Mar 30 08:58:39 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 30 Mar 2022 08:58:39 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v2]
In-Reply-To: <1hkS9KYWWiQXJAon8pmy2YMAwET419pRhrn2jG2ootg=.58239091-7cc6-49c5-9863-44cd19f7aad3@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <1hkS9KYWWiQXJAon8pmy2YMAwET419pRhrn2jG2ootg=.58239091-7cc6-49c5-9863-44cd19f7aad3@github.com>
Message-ID: <xnfX2JuI2J2fuzSrsCp50x0onsjfUK2hBSey-dlE9a8=.91adc8f1-d5b0-4560-99c6-54d4a00169cf@github.com>

On Mon, 28 Mar 2022 11:04:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 
>> 
>> Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.
>> 
>> On a simple test:
>> 
>> 
>> import java.lang.invoke.MethodHandles;
>> import java.lang.invoke.VarHandle;
>> 
>> public class VHWarmup {
>> 
>>     static final int SIZE = 1_000_000;
>> 
>>     private VarHandle[] vhs;
>>     private int x;
>> 
>>     public static void main(String... args) throws Exception {
>>         new VHWarmup().run();
>>     }
>> 
>>     public void run() throws Exception {
>>         vhs = new VarHandle[SIZE];
>>         for (int c = 0; c < SIZE; c++) {
>>             VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
>>             vh.get(this);
>>             vhs[c] = vh;
>>         }
>>     }
>> }
>> 
>> 
>> Baseline:
>> 
>> 
>> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
>> 
>>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
>> 
>>           1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
>>                887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
>>                  6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
>>             31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
>>      4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
>>        168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
>>        790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
>>      9,094,235,238      instructions              #    1.93  insn per cycle         
>>                                                   #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
>>      1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
>>          3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)
>> 
>>            1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )
>> 
>> 
>> Patched:
>> 
>> 
>> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
>> 
>>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
>> 
>>           1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
>>                860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
>>                  7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
>>             31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
>>      4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
>>        151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
>>        604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
>>      8,517,580,297      instructions              #    1.97  insn per cycle         
>>                                                   #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
>>      1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
>>          4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)
>> 
>>            1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug `tier2`
>>  - [x] SPECjvm2008 shows no regressions
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - enqueue_loc
>  - Merge branch 'master' into JDK-8283566-g1-enqueue
>  - Cleanups
>  - More complete patch
>  - Inlining

src/hotspot/share/gc/g1/g1BarrierSet.hpp line 61:

> 59:   // pre-marking object graph. Prefer the version that takes location, as it
> 60:   // can avoid touching the heap unnecessarily.
> 61:   template <class T> static void enqueue_loc(T* dst);

Since the "location" version should be preferred, I would have used


templace <class T>
static void enqueue(T* dst);

static void enqueue_preloaded(oop pre_val);

to make the preferred version "default". Just my 2c.

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

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


From shade at openjdk.java.net  Wed Mar 30 10:11:36 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 10:11:36 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v3]
In-Reply-To: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
Message-ID: <8gsbim-llDqk43T-R3H8zpYSaWhwzBK3KU-7ESjgsPw=.b7241b30-0ee6-4d56-b956-53909849528c@github.com>

> While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 
> 
> Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.
> 
> On a simple test:
> 
> 
> import java.lang.invoke.MethodHandles;
> import java.lang.invoke.VarHandle;
> 
> public class VHWarmup {
> 
>     static final int SIZE = 1_000_000;
> 
>     private VarHandle[] vhs;
>     private int x;
> 
>     public static void main(String... args) throws Exception {
>         new VHWarmup().run();
>     }
> 
>     public void run() throws Exception {
>         vhs = new VarHandle[SIZE];
>         for (int c = 0; c < SIZE; c++) {
>             VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
>             vh.get(this);
>             vhs[c] = vh;
>         }
>     }
> }
> 
> 
> Baseline:
> 
> 
> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
> 
>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
> 
>           1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
>                887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
>                  6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
>             31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
>      4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
>        168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
>        790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
>      9,094,235,238      instructions              #    1.93  insn per cycle         
>                                                   #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
>      1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
>          3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)
> 
>            1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )
> 
> 
> Patched:
> 
> 
> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
> 
>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
> 
>           1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
>                860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
>                  7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
>             31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
>      4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
>        151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
>        604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
>      8,517,580,297      instructions              #    1.97  insn per cycle         
>                                                   #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
>      1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
>          4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)
> 
>            1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )
> 
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_64 fastdebug `tier2`
>  - [x] SPECjvm2008 shows no regressions

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

 - Merge branch 'master' into JDK-8283566-g1-enqueue
 - enqueue_preloaded*
 - enqueue_loc
 - Merge branch 'master' into JDK-8283566-g1-enqueue
 - Cleanups
 - More complete patch
 - Inlining

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7921/files
  - new: https://git.openjdk.java.net/jdk/pull/7921/files/cdfd7891..b64f25a0

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

  Stats: 4823 lines in 168 files changed: 3654 ins; 674 del; 495 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7921.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7921/head:pull/7921

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


From shade at openjdk.java.net  Wed Mar 30 10:11:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 10:11:39 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v2]
In-Reply-To: <xnfX2JuI2J2fuzSrsCp50x0onsjfUK2hBSey-dlE9a8=.91adc8f1-d5b0-4560-99c6-54d4a00169cf@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <1hkS9KYWWiQXJAon8pmy2YMAwET419pRhrn2jG2ootg=.58239091-7cc6-49c5-9863-44cd19f7aad3@github.com>
 <xnfX2JuI2J2fuzSrsCp50x0onsjfUK2hBSey-dlE9a8=.91adc8f1-d5b0-4560-99c6-54d4a00169cf@github.com>
Message-ID: <x52nIuRI7CEKfC1N2E43ieKaZ7eJQpIzC2cZ4U3z1v0=.75dfcabf-abdc-4788-ba1e-3d745d125cde@github.com>

On Wed, 30 Mar 2022 08:55:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - enqueue_loc
>>  - Merge branch 'master' into JDK-8283566-g1-enqueue
>>  - Cleanups
>>  - More complete patch
>>  - Inlining
>
> src/hotspot/share/gc/g1/g1BarrierSet.hpp line 61:
> 
>> 59:   // pre-marking object graph. Prefer the version that takes location, as it
>> 60:   // can avoid touching the heap unnecessarily.
>> 61:   template <class T> static void enqueue_loc(T* dst);
> 
> Since the "location" version should be preferred, I would have used
> 
> 
> templace <class T>
> static void enqueue(T* dst);
> 
> static void enqueue_preloaded(oop pre_val);
> 
> to make the preferred version "default". Just my 2c.

`enqueue_preloaded` it is! See new commit.

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

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


From ayang at openjdk.java.net  Wed Mar 30 10:49:39 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 30 Mar 2022 10:49:39 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v3]
In-Reply-To: <8gsbim-llDqk43T-R3H8zpYSaWhwzBK3KU-7ESjgsPw=.b7241b30-0ee6-4d56-b956-53909849528c@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <8gsbim-llDqk43T-R3H8zpYSaWhwzBK3KU-7ESjgsPw=.b7241b30-0ee6-4d56-b956-53909849528c@github.com>
Message-ID: <RoCcmeXialksdGPd2r0hrnntsKP_84jZhT8z5e1vC3c=.933971d4-d7ce-493c-97bb-124071145118@github.com>

On Wed, 30 Mar 2022 10:11:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 
>> 
>> Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.
>> 
>> On a simple test:
>> 
>> 
>> import java.lang.invoke.MethodHandles;
>> import java.lang.invoke.VarHandle;
>> 
>> public class VHWarmup {
>> 
>>     static final int SIZE = 1_000_000;
>> 
>>     private VarHandle[] vhs;
>>     private int x;
>> 
>>     public static void main(String... args) throws Exception {
>>         new VHWarmup().run();
>>     }
>> 
>>     public void run() throws Exception {
>>         vhs = new VarHandle[SIZE];
>>         for (int c = 0; c < SIZE; c++) {
>>             VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
>>             vh.get(this);
>>             vhs[c] = vh;
>>         }
>>     }
>> }
>> 
>> 
>> Baseline:
>> 
>> 
>> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
>> 
>>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
>> 
>>           1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
>>                887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
>>                  6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
>>             31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
>>      4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
>>        168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
>>        790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
>>      9,094,235,238      instructions              #    1.93  insn per cycle         
>>                                                   #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
>>      1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
>>          3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)
>> 
>>            1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )
>> 
>> 
>> Patched:
>> 
>> 
>> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
>> 
>>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
>> 
>>           1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
>>                860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
>>                  7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
>>             31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
>>      4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
>>        151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
>>        604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
>>      8,517,580,297      instructions              #    1.97  insn per cycle         
>>                                                   #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
>>      1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
>>          4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)
>> 
>>            1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug `tier2`
>>  - [x] SPECjvm2008 shows no regressions
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8283566-g1-enqueue
>  - enqueue_preloaded*
>  - enqueue_loc
>  - Merge branch 'master' into JDK-8283566-g1-enqueue
>  - Cleanups
>  - More complete patch
>  - Inlining

Marked as reviewed by ayang (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Mar 30 11:20:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 30 Mar 2022 11:20:42 GMT
Subject: RFR: 8283566: G1: Improve G1BarrierSet::enqueue performance [v3]
In-Reply-To: <8gsbim-llDqk43T-R3H8zpYSaWhwzBK3KU-7ESjgsPw=.b7241b30-0ee6-4d56-b956-53909849528c@github.com>
References: <1K-b5r0GDMqZgE8MfWohJ7rRJKkBwnn1JITfqQh3BF0=.f0351331-98e7-44d4-8881-c1bbbaade22e@github.com>
 <8gsbim-llDqk43T-R3H8zpYSaWhwzBK3KU-7ESjgsPw=.b7241b30-0ee6-4d56-b956-53909849528c@github.com>
Message-ID: <UoHiNcul7lSItMkktk_FeNUuC4UlXRPngc43OHKFp9E=.2a086e39-8cbf-4fba-aeba-9e6d8aba4ed2@github.com>

On Wed, 30 Mar 2022 10:11:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> While looking at startup/warmup benchmarks for VarHandles, I noticed that `G1BarrierSet::enqueue` is not inlined and quite hot. Its uses also load the oop first, and then check if queues are active. This could be improved a bit. This only matters for the barrier paths that VM takes, which is the case for `java.lang.invoke` VM infra. 
>> 
>> Not sure about `enqueue_oop` name, I did it to avoid accidental overload clash with `enqueue(T* dst)`. Open for suggestions.
>> 
>> On a simple test:
>> 
>> 
>> import java.lang.invoke.MethodHandles;
>> import java.lang.invoke.VarHandle;
>> 
>> public class VHWarmup {
>> 
>>     static final int SIZE = 1_000_000;
>> 
>>     private VarHandle[] vhs;
>>     private int x;
>> 
>>     public static void main(String... args) throws Exception {
>>         new VHWarmup().run();
>>     }
>> 
>>     public void run() throws Exception {
>>         vhs = new VarHandle[SIZE];
>>         for (int c = 0; c < SIZE; c++) {
>>             VarHandle vh = MethodHandles.lookup().findVarHandle(VHWarmup.class, "x", int.class);
>>             vh.get(this);
>>             vhs[c] = vh;
>>         }
>>     }
>> }
>> 
>> 
>> Baseline:
>> 
>> 
>> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
>> 
>>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
>> 
>>           1,392.13 msec task-clock                #    1.183 CPUs utilized            ( +-  0.45% )
>>                887      context-switches          #    0.637 K/sec                    ( +-  1.05% )
>>                  6      cpu-migrations            #    0.004 K/sec                    ( +- 14.72% )
>>             31,755      page-faults               #    0.023 M/sec                    ( +-  0.17% )
>>      4,708,582,477      cycles                    #    3.382 GHz                      ( +-  0.44% )  (50.46%)
>>        168,230,638      stalled-cycles-frontend   #    3.57% frontend cycles idle     ( +-  2.75% )  (50.35%)
>>        790,033,580      stalled-cycles-backend    #   16.78% backend cycles idle      ( +-  1.82% )  (50.03%)
>>      9,094,235,238      instructions              #    1.93  insn per cycle         
>>                                                   #    0.09  stalled cycles per insn  ( +-  0.22% )  (49.54%)
>>      1,716,367,002      branches                  # 1232.909 M/sec                    ( +-  0.38% )  (49.65%)
>>          3,908,772      branch-misses             #    0.23% of all branches          ( +-  2.89% )  (49.97%)
>> 
>>            1.17642 +- 0.00616 seconds time elapsed  ( +-  0.52% )
>> 
>> 
>> Patched:
>> 
>> 
>> $ perf stat -r 10 build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup > /dev/null
>> 
>>  Performance counter stats for 'build/linux-x86_64-server-release/images/jdk/bin/java -Xms128m -Xmx128m VHWarmup' (10 runs):
>> 
>>           1,288.69 msec task-clock                #    1.203 CPUs utilized            ( +-  0.73% )
>>                860      context-switches          #    0.667 K/sec                    ( +-  1.38% )
>>                  7      cpu-migrations            #    0.006 K/sec                    ( +- 11.96% )
>>             31,830      page-faults               #    0.025 M/sec                    ( +-  0.13% )
>>      4,331,508,315      cycles                    #    3.361 GHz                      ( +-  0.72% )  (50.01%)
>>        151,638,797      stalled-cycles-frontend   #    3.50% frontend cycles idle     ( +-  2.94% )  (49.56%)
>>        604,797,159      stalled-cycles-backend    #   13.96% backend cycles idle      ( +-  4.17% )  (49.70%)
>>      8,517,580,297      instructions              #    1.97  insn per cycle         
>>                                                   #    0.07  stalled cycles per insn  ( +-  0.50% )  (49.99%)
>>      1,600,179,319      branches                  # 1241.714 M/sec                    ( +-  0.46% )  (50.44%)
>>          4,129,679      branch-misses             #    0.26% of all branches          ( +-  4.39% )  (50.30%)
>> 
>>            1.07125 +- 0.00822 seconds time elapsed  ( +-  0.77% )
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `tier1`
>>  - [x] Linux x86_64 fastdebug `tier2`
>>  - [x] SPECjvm2008 shows no regressions
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8283566-g1-enqueue
>  - enqueue_preloaded*
>  - enqueue_loc
>  - Merge branch 'master' into JDK-8283566-g1-enqueue
>  - Cleanups
>  - More complete patch
>  - Inlining

Marked as reviewed by tschatzl (Reviewer).

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

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