From iklam at openjdk.java.net  Tue Feb  1 01:00:09 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 1 Feb 2022 01:00:09 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
Message-ID: <_7ho-2xCD3tAv6mIdlebA2bbhLupmVY8ofDGV0sIJx8=.4492cdcb-e646-43c0-8ed4-576db5a06797@github.com>

On Mon, 31 Jan 2022 23:57:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
>> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
>> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
>> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
>> 
>> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
>> 
>> Preliminary HelloWorld startup perf. improvement:
>> 
>> instr delta =    -68813432    -49.7140%
>> time  delta =      -14.720 ms -20.3599%
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup and added a test case

LGTM. The start-up performance improvement is good! Thanks.

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

Marked as reviewed by iklam (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Feb  1 07:08:43 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 07:08:43 GMT
Subject: RFR: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused [v2]
In-Reply-To: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
References: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
Message-ID: <p4VaC7reNcV34DE5FXXFMjL4t-uF4Jxxh7Jar1LRbnk=.b0fcb1d3-f889-43fb-947b-3e5d4ed3a2ca@github.com>

> Please review this change to avoid attempts to refine dirty cards by Java
> threads when there is an active STS yield request, as the attempt will just
> end up being paused.  When going into a safepoint this avoids wasted work and
> transfer of buffers into the paused list.  More importantly, when coming out
> of a pause this avoids deferring buffers to after the next safepoint, due to
> the yield request being cleared after Java threads are restarted.
> 
> Testing:
> mach5 tier1
> 
> Lots of testing as part of investigation of JDK-8273383.

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

  fix typo

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7148/files
  - new: https://git.openjdk.java.net/jdk/pull/7148/files/ebadd0aa..4ef92931

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

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

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


From kbarrett at openjdk.java.net  Tue Feb  1 07:12:36 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 07:12:36 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v2]
In-Reply-To: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
Message-ID: <tnNhY7ceFB2k19wXtxY9YODMusnQFjaP6x_OMnRWdI4=.f81e9f8b-9d9a-4cf5-be86-dfe8a122c32e@github.com>

> Please review this change to to G1ConcurrentRefineThreads to simplify the
> activation mechanism.
> 
> We split the class into two subclasses, one for the "primary" refinement
> thread and another class for the remaining refinement threads.
> 
> The secondary threads are changed to use Monitor-based waits and notifications
> with a supporting request flag.
> 
> The primary thread uses an atomic activation threshold that also serves as "is
> running" state.  This activation threshold is used by the write barrier
> support to determine whether the thread's semaphore needs to be signaled.
> That threshold is now in the primary refinement thread rather than in the
> dirty card queue set to simplify threshold management and somewhat reduce
> coupling.
> 
> Testing:
> mach5 tier1-3
> 
> Manual tests with refinement thread logging enabled to verify expected
> activations occur.

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

  update copyrights

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7282/files
  - new: https://git.openjdk.java.net/jdk/pull/7282/files/b72cf4fd..ba3f9a46

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

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

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


From iwalulya at openjdk.java.net  Tue Feb  1 08:40:09 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 1 Feb 2022 08:40:09 GMT
Subject: RFR: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused [v2]
In-Reply-To: <p4VaC7reNcV34DE5FXXFMjL4t-uF4Jxxh7Jar1LRbnk=.b0fcb1d3-f889-43fb-947b-3e5d4ed3a2ca@github.com>
References: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
 <p4VaC7reNcV34DE5FXXFMjL4t-uF4Jxxh7Jar1LRbnk=.b0fcb1d3-f889-43fb-947b-3e5d4ed3a2ca@github.com>
Message-ID: <ThmJf2KQ6oEms45RUKgwvQPq2QF-auD8PgtAja74du8=.7bd87ce9-706c-42b1-8869-a93ec0ba2d99@github.com>

On Tue, 1 Feb 2022 07:08:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to avoid attempts to refine dirty cards by Java
>> threads when there is an active STS yield request, as the attempt will just
>> end up being paused.  When going into a safepoint this avoids wasted work and
>> transfer of buffers into the paused list.  More importantly, when coming out
>> of a pause this avoids deferring buffers to after the next safepoint, due to
>> the yield request being cleared after Java threads are restarted.
>> 
>> Testing:
>> mach5 tier1
>> 
>> Lots of testing as part of investigation of JDK-8273383.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From ayang at openjdk.java.net  Tue Feb  1 08:51:14 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 08:51:14 GMT
Subject: Integrated: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects
In-Reply-To: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
Message-ID: <XdFBxooamUt-kTZFFbNSKN5WHWvW6Me0VnWrEnEiK0Q=.529d7d0c-e50b-4e1d-a9fb-d014076295d0@github.com>

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

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

This pull request has now been integrated.

Changeset: 16ec47d5
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/16ec47d5e5bf129fc0910358464ab62bf6ce7ed8
Stats:     24 lines in 5 files changed: 12 ins; 8 del; 4 mod

8279856: Parallel: Use PreservedMarks to record promotion-failed objects

Reviewed-by: sjohanss, tschatzl

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

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


From sjohanss at openjdk.java.net  Tue Feb  1 08:52:11 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 1 Feb 2022 08:52:11 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
 [v2]
In-Reply-To: <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
 <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>
Message-ID: <Jza_J_EMIBmgK5GbSpXQK4PicgKZC48tRZqiOOPcZZI=.d64e01bd-63da-430d-ade6-806b11700605@github.com>

On Fri, 28 Jan 2022 11:08:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

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

Marked as reviewed by sjohanss (Reviewer).

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


From iwalulya at openjdk.java.net  Tue Feb  1 08:51:11 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 1 Feb 2022 08:51:11 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
In-Reply-To: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
Message-ID: <X2TP3_14XsG-JGYM7rqKsEIa8flvjpEhvZT4TBY6Io4=.5d1a3d5f-5569-4205-96e2-d48671d92d3a@github.com>

On Mon, 31 Jan 2022 09:31:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes of renaming some methods/comments.
> 
> Test: build

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From ayang at openjdk.java.net  Tue Feb  1 08:51:13 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 08:51:13 GMT
Subject: RFR: 8279856: Parallel: Use PreservedMarks to record
 promotion-failed objects [v2]
In-Reply-To: <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>
References: <h3u65u627jWg6Cvi64nqOUdmeTCKQppqYrd2RiUQW2E=.bd8702aa-35c4-43ad-9d9f-df249ef8eb35@github.com>
 <H5fDBrdW0xyqEdXVYS8qQMfhrrCeJVFqHxhKuv8rEdQ=.090e61fa-206a-433f-b151-539554a5da44@github.com>
Message-ID: <Yo45tYptVbJtRI2f6pkapnDeqO-F0OeTGeCCmDrSQvs=.ac5a18af-6195-4f89-bd6c-ba991b42b99f@github.com>

On Tue, 25 Jan 2022 15:40:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of using `PreservedMarks` to skip young-gen walking in finding promotion-failed objs.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review
>  - review

Thanks for the review.

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

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


From tschatzl at openjdk.java.net  Tue Feb  1 09:10:15 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 09:10:15 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
In-Reply-To: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
Message-ID: <NX4unw345raMvo1C-CitzUFHC-G4CZZbOg0eSxl8Bl4=.01b4a4c7-0cda-47c7-9a82-ec86317b48c1@github.com>

On Mon, 31 Jan 2022 09:31:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes of renaming some methods/comments.
> 
> Test: build

See the earlier comment from me.

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

Changes requested by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Feb  1 09:38:11 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 09:38:11 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
Message-ID: <_9AMhEZyAuj7yV5nRpLC2k642WmAywtIiY4p1ZIgXOM=.6d557a3f-5e17-439b-8b55-39d7c67f75bc@github.com>

On Mon, 31 Jan 2022 23:57:57 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
>> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
>> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
>> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
>> 
>> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
>> 
>> Preliminary HelloWorld startup perf. improvement:
>> 
>> instr delta =    -68813432    -49.7140%
>> time  delta =      -14.720 ms -20.3599%
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   code cleanup and added a test case

GC changes look good to me.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Tue Feb  1 09:50:40 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 09:50:40 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
 [v2]
In-Reply-To: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
Message-ID: <pily3jfS97Xl8zCE-LStEtP84bcamrTINwq-YFp8bAI=.adf9db0e-12bd-4793-b465-8a33e6a339bc@github.com>

> Mostly mechanical changes of renaming some methods/comments.
> 
> Test: build

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7285/files
  - new: https://git.openjdk.java.net/jdk/pull/7285/files/6a226cda..7473ca9b

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

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

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


From tschatzl at openjdk.java.net  Tue Feb  1 10:01:11 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 10:01:11 GMT
Subject: RFR: 8280458: G1: Remove
 G1BlockOffsetTablePart::_next_offset_threshold
In-Reply-To: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
References: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
Message-ID: <EArmcecq4vm34-UR6HgKvXPT_KGLQwehia6QA9BA-x0=.2e94a7e9-fd97-4fef-8811-1d05081ef562@github.com>

On Fri, 21 Jan 2022 14:51:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. the real change of removing the field and updating surrounding code.
> 2. refactoring only (rename, comment updates, method inline, etc).
> 
> PS: `oop.inline.hpp` is needed for `klass_or_null`; it worked before by accident. Changes to `G1FullGCCompactionPoint` is kept to minimal to avoid conflicts with #7106.
> 
> Test: tier1-6

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Feb  1 10:19:09 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 10:19:09 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
 [v2]
In-Reply-To: <pily3jfS97Xl8zCE-LStEtP84bcamrTINwq-YFp8bAI=.adf9db0e-12bd-4793-b465-8a33e6a339bc@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
 <pily3jfS97Xl8zCE-LStEtP84bcamrTINwq-YFp8bAI=.adf9db0e-12bd-4793-b465-8a33e6a339bc@github.com>
Message-ID: <2oXqFraLIR_kLmduRomhKqzesH98LojRD-cNZoQPflo=.6aae75ea-6f4c-4258-9a1c-758e8e910103@github.com>

On Tue, 1 Feb 2022 09:50:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Mostly mechanical changes of renaming some methods/comments.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Lgtm. Thanks.

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

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


From ayang at openjdk.java.net  Tue Feb  1 11:00:21 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 11:00:21 GMT
Subject: Integrated: 8280870: Parallel: Simplify CLD roots claim in Full GC
 cycle
In-Reply-To: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
Message-ID: <uQ5yw7W1EmcB7vaOa5yyA4PwWHxy9VraM9RbqQ4c47c=.d9b5575b-b671-47e6-8e9c-64913c2336d5@github.com>

On Fri, 28 Jan 2022 10:18:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: d37fb1df
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d37fb1df460ec980bd8d3029b1ce7896c3249a99
Stats:     46 lines in 1 file changed: 7 ins; 35 del; 4 mod

8280870: Parallel: Simplify CLD roots claim in Full GC cycle

Reviewed-by: stefank, sjohanss

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

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


From ayang at openjdk.java.net  Tue Feb  1 11:00:20 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 11:00:20 GMT
Subject: RFR: 8280870: Parallel: Simplify CLD roots claim in Full GC cycle
 [v2]
In-Reply-To: <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>
References: <mguo0DoxrCPNfKAknK7HdFvxOTBje6esbpqQK2H7pvw=.d2b2f6a5-92c2-4ce9-bf67-b8d84f5e8bab@github.com>
 <rk8tUgZF3b_FkZ-Nuv9ZyddLxhkSj0iWyYmfqCBAW4E=.06760055-1fb2-477e-a433-ebf63219b4a8@github.com>
Message-ID: <PN5maSaddmY1KMRTij6iZyr_MPGmrpXb-t40bYJOx6U=.d8de4b43-8200-4744-8b49-8b740e1bab92@github.com>

On Fri, 28 Jan 2022 11:08:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change around CLD roots claim logic in `MarkFromRootsTask`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Feb  1 11:08:14 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 11:08:14 GMT
Subject: Integrated: 8280932: G1: Rename HeapRegionRemSet::_code_roots
 accessors
In-Reply-To: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
Message-ID: <XAe7EpPPVVW04f2Iw0TuvSLEe8jvXq-cZexaUB9OKYU=.dc747448-a109-4469-a4e9-77b4278097c0@github.com>

On Mon, 31 Jan 2022 09:31:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Mostly mechanical changes of renaming some methods/comments.
> 
> Test: build

This pull request has now been integrated.

Changeset: 86debf42
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/86debf42f545a1aec0a065ebd5b016339a1ae09f
Stats:     106 lines in 15 files changed: 0 ins; 1 del; 105 mod

8280932: G1: Rename HeapRegionRemSet::_code_roots accessors

Reviewed-by: iwalulya

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

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


From ayang at openjdk.java.net  Tue Feb  1 11:08:14 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 11:08:14 GMT
Subject: RFR: 8280932: G1: Rename HeapRegionRemSet::_code_roots accessors
 [v2]
In-Reply-To: <pily3jfS97Xl8zCE-LStEtP84bcamrTINwq-YFp8bAI=.adf9db0e-12bd-4793-b465-8a33e6a339bc@github.com>
References: <Y9q6jk504luRdaM8zKu89wLt1HcQWT_IUIO7BQCW-M0=.77261f09-2056-4b78-a557-632311da427a@github.com>
 <pily3jfS97Xl8zCE-LStEtP84bcamrTINwq-YFp8bAI=.adf9db0e-12bd-4793-b465-8a33e6a339bc@github.com>
Message-ID: <PNOd8K0lHIPgiedIIdeN6h65un7Wv4aIydDLGPhVqEg=.997b2ab3-0cc1-4493-8af7-5576540bd082@github.com>

On Tue, 1 Feb 2022 09:50:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Mostly mechanical changes of renaming some methods/comments.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Feb  1 11:09:41 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 11:09:41 GMT
Subject: RFR: 8281035: Serial: Move RemoveForwardedPointerClosure to local
 scope
Message-ID: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>

Simple change of moving `RemoveForwardedPointerClosure` from shared code to Serial code.

Test: hotspot_gc

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

Commit messages:
 - serial-promotion-failure

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

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


From iwalulya at openjdk.java.net  Tue Feb  1 11:36:12 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 1 Feb 2022 11:36:12 GMT
Subject: RFR: 8280458: G1: Remove
 G1BlockOffsetTablePart::_next_offset_threshold
In-Reply-To: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
References: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
Message-ID: <ND2vRxOti8kLXpwC4iLVOq1RG2Wu1nyQpOKTdF_bpOo=.47626cc0-c22f-48f1-b7f1-57c35b2999dd@github.com>

On Fri, 21 Jan 2022 14:51:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. the real change of removing the field and updating surrounding code.
> 2. refactoring only (rename, comment updates, method inline, etc).
> 
> PS: `oop.inline.hpp` is needed for `klass_or_null`; it worked before by accident. Changes to `G1FullGCCompactionPoint` is kept to minimal to avoid conflicts with #7106.
> 
> Test: tier1-6

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Feb  1 12:21:14 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 1 Feb 2022 12:21:14 GMT
Subject: RFR: 8280458: G1: Remove
 G1BlockOffsetTablePart::_next_offset_threshold
In-Reply-To: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
References: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
Message-ID: <5d35G-dXO92r3asj3A5l2mkI89KdCrkfGaNMtXIUtiI=.f59b69b0-b6b6-4233-89a0-9eec5e11c04b@github.com>

On Fri, 21 Jan 2022 14:51:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. the real change of removing the field and updating surrounding code.
> 2. refactoring only (rename, comment updates, method inline, etc).
> 
> PS: `oop.inline.hpp` is needed for `klass_or_null`; it worked before by accident. Changes to `G1FullGCCompactionPoint` is kept to minimal to avoid conflicts with #7106.
> 
> Test: tier1-6

Marked as reviewed by sjohanss (Reviewer).

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

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


From ayang at openjdk.java.net  Tue Feb  1 12:27:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 12:27:09 GMT
Subject: RFR: 8280458: G1: Remove
 G1BlockOffsetTablePart::_next_offset_threshold
In-Reply-To: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
References: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
Message-ID: <FTl6b_kPIy8G_IuBsiyXC8W6CkVup3VPNFcFkrsoWms=.6926586c-7a6d-4196-8579-e3d59bc1a31e@github.com>

On Fri, 21 Jan 2022 14:51:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. the real change of removing the field and updating surrounding code.
> 2. refactoring only (rename, comment updates, method inline, etc).
> 
> PS: `oop.inline.hpp` is needed for `klass_or_null`; it worked before by accident. Changes to `G1FullGCCompactionPoint` is kept to minimal to avoid conflicts with #7106.
> 
> Test: tier1-6

Thanks for the review.

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

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


From ayang at openjdk.java.net  Tue Feb  1 12:27:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 12:27:09 GMT
Subject: Integrated: 8280458: G1: Remove
 G1BlockOffsetTablePart::_next_offset_threshold
In-Reply-To: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
References: <2NFB-9X9wW_ahMxHa8EAvpBH5rrUlwmxtqpVFzqk0Yo=.f8e2c40e-a960-4bf5-a009-75dd82932416@github.com>
Message-ID: <nREqPbOcIhZvoACSZvy-4NZpp0ZGJslolhiSMy3_5fk=.732eb539-9e37-4d7f-8a42-a29290b3beb0@github.com>

On Fri, 21 Jan 2022 14:51:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of two commits:
> 
> 1. the real change of removing the field and updating surrounding code.
> 2. refactoring only (rename, comment updates, method inline, etc).
> 
> PS: `oop.inline.hpp` is needed for `klass_or_null`; it worked before by accident. Changes to `G1FullGCCompactionPoint` is kept to minimal to avoid conflicts with #7106.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: c5a86120
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5a86120df7105cf612d513b5bd394501c00efed
Stats:     145 lines in 10 files changed: 14 ins; 95 del; 36 mod

8280458: G1: Remove G1BlockOffsetTablePart::_next_offset_threshold

Reviewed-by: tschatzl, iwalulya, sjohanss

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

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


From ayang at openjdk.java.net  Tue Feb  1 13:15:51 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 13:15:51 GMT
Subject: RFR: 8281042: G1: Remove unused init_threshold in
 G1FullGCCompactionPoint
Message-ID: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>

Simple change of removing unused method arg.

Test: build

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

Commit messages:
 - remove-full-init-threshold

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

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


From iwalulya at openjdk.java.net  Tue Feb  1 13:25:15 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 1 Feb 2022 13:25:15 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
Message-ID: <z5g34su3_V1KH2D5f7sxJ__iYcM4QRDZKrKcfxr7xjY=.dcbdd12d-bf28-4949-bef2-5e0262889e4e@github.com>

On Tue, 18 Jan 2022 04:31:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

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

Is there a plan to use the Configuration parameter beyond getting the number of object types as in `static constexpr uint NUM = Configuration::num_mem_object_types();`?

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

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


From tschatzl at openjdk.java.net  Tue Feb  1 14:58:12 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 14:58:12 GMT
Subject: RFR: 8281042: G1: Remove unused init_threshold in
 G1FullGCCompactionPoint
In-Reply-To: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
References: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
Message-ID: <IIS9YijrUBx2yoPCSWDQgCgKtIJQ7sUp0_QoO1wdHhA=.605047d3-73a7-4103-8bff-e1f11347d190@github.com>

On Tue, 1 Feb 2022 13:08:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unused method arg.
> 
> Test: build

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Feb  1 15:31:17 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 15:31:17 GMT
Subject: RFR: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused [v2]
In-Reply-To: <ThmJf2KQ6oEms45RUKgwvQPq2QF-auD8PgtAja74du8=.7bd87ce9-706c-42b1-8869-a93ec0ba2d99@github.com>
References: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
 <p4VaC7reNcV34DE5FXXFMjL4t-uF4Jxxh7Jar1LRbnk=.b0fcb1d3-f889-43fb-947b-3e5d4ed3a2ca@github.com>
 <ThmJf2KQ6oEms45RUKgwvQPq2QF-auD8PgtAja74du8=.7bd87ce9-706c-42b1-8869-a93ec0ba2d99@github.com>
Message-ID: <o3dXBUMQICZf2jnknPISnq2cSPZqRYmIImvtwVbuTf8=.552df8c4-b81c-4327-99cb-12f9b6cbe393@github.com>

On Tue, 1 Feb 2022 08:37:17 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo
>
> Lgtm!

Thanks @walulyai and @tschatzl for reviews.

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

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


From kbarrett at openjdk.java.net  Tue Feb  1 15:44:06 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 15:44:06 GMT
Subject: RFR: 8281035: Serial: Move RemoveForwardedPointerClosure to local
 scope
In-Reply-To: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
References: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
Message-ID: <BVCSFVVuuywR13HJroCKOKW-I0wWhNdjtjpqPveVar4=.6a18d082-b1cd-459b-aa5a-cfbbc12c2552@github.com>

On Tue, 1 Feb 2022 11:01:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `RemoveForwardedPointerClosure` from shared code to Serial code.
> 
> Test: hotspot_gc

Marked as reviewed by kbarrett (Reviewer).

src/hotspot/share/gc/serial/defNewGeneration.cpp line 684:

> 682:     }
> 683:   };
> 684:   ResetForwardedMarkWord cl;

`cl` could be declared as part of the struct declaration, rather than separately, thereby eliminating the additional occurrence of `ResetForwardedMarkWord`.  Your call...

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

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


From kbarrett at openjdk.java.net  Tue Feb  1 15:47:56 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 15:47:56 GMT
Subject: RFR: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused [v3]
In-Reply-To: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
References: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
Message-ID: <YC8YdZvnM2BjsLzCVRCZJl8zpvsITBPFNOMtzloaTLc=.d6e15a3f-2dd7-4f53-aaf1-d98276cdd65d@github.com>

> Please review this change to avoid attempts to refine dirty cards by Java
> threads when there is an active STS yield request, as the attempt will just
> end up being paused.  When going into a safepoint this avoids wasted work and
> transfer of buffers into the paused list.  More importantly, when coming out
> of a pause this avoids deferring buffers to after the next safepoint, due to
> the yield request being cleared after Java threads are restarted.
> 
> Testing:
> mach5 tier1
> 
> Lots of testing as part of investigation of JDK-8273383.

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

 - Merge branch 'master' into no-dequeue-when-should-yield
 - fix typo
 - fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7148/files
  - new: https://git.openjdk.java.net/jdk/pull/7148/files/4ef92931..3b902a9a

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

  Stats: 12767 lines in 685 files changed: 7399 ins; 2938 del; 2430 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7148.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7148/head:pull/7148

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


From kbarrett at openjdk.java.net  Tue Feb  1 15:47:56 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 15:47:56 GMT
Subject: Integrated: 8278475: G1 dirty card refinement by Java threads may get
 unnecessarily paused
In-Reply-To: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
References: <4vsHBJXYM_mYm7VXgAT5r5nTDNIkrSSX0DrJFA-R8LE=.3bbbc5b5-89ee-402a-b458-fde1fd465427@github.com>
Message-ID: <RSiK4oYR87JTtrCRbC--cglGinla3IujmzIX_SKVLV4=.dd887b1c-b3a1-4ca7-a34e-7167860fdf57@github.com>

On Wed, 19 Jan 2022 22:31:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to avoid attempts to refine dirty cards by Java
> threads when there is an active STS yield request, as the attempt will just
> end up being paused.  When going into a safepoint this avoids wasted work and
> transfer of buffers into the paused list.  More importantly, when coming out
> of a pause this avoids deferring buffers to after the next safepoint, due to
> the yield request being cleared after Java threads are restarted.
> 
> Testing:
> mach5 tier1
> 
> Lots of testing as part of investigation of JDK-8273383.

This pull request has now been integrated.

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

8278475: G1 dirty card refinement by Java threads may get unnecessarily paused

Reviewed-by: tschatzl, iwalulya

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

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


From kbarrett at openjdk.java.net  Tue Feb  1 15:48:11 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 1 Feb 2022 15:48:11 GMT
Subject: RFR: 8281042: G1: Remove unused init_threshold in
 G1FullGCCompactionPoint
In-Reply-To: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
References: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
Message-ID: <Ba-8tznwc_J_tWN2xqND7h9hy5P7aGybkJe403peBAE=.281c2361-34c1-46dd-919c-28250c200f44@github.com>

On Tue, 1 Feb 2022 13:08:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unused method arg.
> 
> Test: build

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Tue Feb  1 15:59:49 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 1 Feb 2022 15:59:49 GMT
Subject: RFR: 8281035: Serial: Move RemoveForwardedPointerClosure to local
 scope [v2]
In-Reply-To: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
References: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
Message-ID: <uFPbmCTvFHQ_ZTfkjMlGyWISQe1hUwyIZ_rIQb88otY=.43729e50-2453-4f7c-8cd6-7509131eec7f@github.com>

> Simple change of moving `RemoveForwardedPointerClosure` from shared code to Serial code.
> 
> Test: hotspot_gc

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7301/files
  - new: https://git.openjdk.java.net/jdk/pull/7301/files/9297a6fc..4cc8c5f0

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

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

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


From tschatzl at openjdk.java.net  Tue Feb  1 16:49:07 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 1 Feb 2022 16:49:07 GMT
Subject: RFR: 8281035: Serial: Move RemoveForwardedPointerClosure to local
 scope [v2]
In-Reply-To: <uFPbmCTvFHQ_ZTfkjMlGyWISQe1hUwyIZ_rIQb88otY=.43729e50-2453-4f7c-8cd6-7509131eec7f@github.com>
References: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
 <uFPbmCTvFHQ_ZTfkjMlGyWISQe1hUwyIZ_rIQb88otY=.43729e50-2453-4f7c-8cd6-7509131eec7f@github.com>
Message-ID: <EqKISzsSNzMEex2FqKjUWN3ECdtK2UPPahN_O40lMok=.e2cc8f8f-630b-427e-b20e-fe72996b3992@github.com>

On Tue, 1 Feb 2022 15:59:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving `RemoveForwardedPointerClosure` from shared code to Serial code.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Lgtm with that minor nit.

src/hotspot/share/gc/serial/defNewGeneration.cpp line 680:

> 678:     void do_object(oop obj) override {
> 679:       if (obj->is_forwarded()) {
> 680:         obj->init_mark();

Since it is available, probably use `PreservedMarks::init_forwarded_mark` here.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ccheung at openjdk.java.net  Tue Feb  1 19:37:17 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 1 Feb 2022 19:37:17 GMT
Subject: RFR: 8255495: Support CDS Archived Heap for uncompressed oops [v3]
In-Reply-To: <_7ho-2xCD3tAv6mIdlebA2bbhLupmVY8ofDGV0sIJx8=.4492cdcb-e646-43c0-8ed4-576db5a06797@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
 <7pMv9_DfownLC6dkoE2P2MPk6KhA7MFV-x1csoCvKhI=.75b03b33-b6ce-4655-abb2-8c917748c28f@github.com>
 <_7ho-2xCD3tAv6mIdlebA2bbhLupmVY8ofDGV0sIJx8=.4492cdcb-e646-43c0-8ed4-576db5a06797@github.com>
Message-ID: <RCYPhKreApMTUOWt6bFmStNO6VKx8jty3A9IR5MZFVc=.94fcdd4b-25a6-4e41-ae66-a5b8faf22d2b@github.com>

On Tue, 1 Feb 2022 00:57:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   code cleanup and added a test case
>
> LGTM. The start-up performance improvement is good! Thanks.

@iklam, @tschatzl, @mseledts Thanks for the review.

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

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


From ccheung at openjdk.java.net  Tue Feb  1 19:37:18 2022
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 1 Feb 2022 19:37:18 GMT
Subject: Integrated: 8255495: Support CDS Archived Heap for uncompressed oops
In-Reply-To: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
References: <8EYWQmles_dtmFOkXegSa6nYxbYA92x49puWb3P_BdI=.2e35b097-5173-4588-8ea0-f35afd179a50@github.com>
Message-ID: <hvDZUTfhuIx7cAT1uqhEPImzgUkK_okepQ6mxwMOgPI=.9b7259d0-cdfa-427e-b3a9-2d05908fb075@github.com>

On Wed, 26 Jan 2022 02:48:05 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> This proposed change adds support for uncompressed oops for CDS archived heap. It is needed
> for supporting archived heap for ZGC in the future. For now, only G1GC is supported with this change.
> During dump time with compressed oops disabled, the MaxHeapSize is set to 4GB. This is to ensure
> the offset of any object in the heap from the bottom of the heap is always a 32-bit integer.
> 
> Passed CI tiers 1 - 4 and hs-tier7-rt tests.
> 
> Preliminary HelloWorld startup perf. improvement:
> 
> instr delta =    -68813432    -49.7140%
> time  delta =      -14.720 ms -20.3599%

This pull request has now been integrated.

Changeset: d95de5c7
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d95de5c7fea4b224d6cd073a6d6921d7108bb7e1
Stats:     374 lines in 14 files changed: 312 ins; 7 del; 55 mod

8255495: Support CDS Archived Heap for uncompressed oops

Reviewed-by: iklam, tschatzl

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

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


From mark.reinhold at oracle.com  Tue Feb  1 23:55:51 2022
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue,  1 Feb 2022 15:55:51 -0800 (PST)
Subject: New candidate JEP: 423: Region Pinning for G1
Message-ID: <20220201235551.919BF4D17E8@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/423

  Summary: Reduce latency by implementing region pinning to G1, so that
  garbage collection need not be disabled during Java Native Interface
  (JNI) critical regions.

- Mark


From kbarrett at openjdk.java.net  Wed Feb  2 00:27:40 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 2 Feb 2022 00:27:40 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v3]
In-Reply-To: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
Message-ID: <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>

> Please review this change to to G1ConcurrentRefineThreads to simplify the
> activation mechanism.
> 
> We split the class into two subclasses, one for the "primary" refinement
> thread and another class for the remaining refinement threads.
> 
> The secondary threads are changed to use Monitor-based waits and notifications
> with a supporting request flag.
> 
> The primary thread uses an atomic activation threshold that also serves as "is
> running" state.  This activation threshold is used by the write barrier
> support to determine whether the thread's semaphore needs to be signaled.
> That threshold is now in the primary refinement thread rather than in the
> dirty card queue set to simplify threshold management and somewhat reduce
> coupling.
> 
> Testing:
> mach5 tier1-3
> 
> Manual tests with refinement thread logging enabled to verify expected
> activations occur.

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

  fix primary thread notification safepoint check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7282/files
  - new: https://git.openjdk.java.net/jdk/pull/7282/files/ba3f9a46..070e92a7

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

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

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


From kbarrett at openjdk.java.net  Wed Feb  2 00:27:42 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 2 Feb 2022 00:27:42 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v2]
In-Reply-To: <tnNhY7ceFB2k19wXtxY9YODMusnQFjaP6x_OMnRWdI4=.f81e9f8b-9d9a-4cf5-be86-dfe8a122c32e@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
 <tnNhY7ceFB2k19wXtxY9YODMusnQFjaP6x_OMnRWdI4=.f81e9f8b-9d9a-4cf5-be86-dfe8a122c32e@github.com>
Message-ID: <grhuTkPL-yEPqw9Odz7hE_n_yyidnpDN1uEQ5pNTXVY=.dbb21a97-f9fd-450d-ab01-003daf302771@github.com>

On Tue, 1 Feb 2022 07:12:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to to G1ConcurrentRefineThreads to simplify the
>> activation mechanism.
>> 
>> We split the class into two subclasses, one for the "primary" refinement
>> thread and another class for the remaining refinement threads.
>> 
>> The secondary threads are changed to use Monitor-based waits and notifications
>> with a supporting request flag.
>> 
>> The primary thread uses an atomic activation threshold that also serves as "is
>> running" state.  This activation threshold is used by the write barrier
>> support to determine whether the thread's semaphore needs to be signaled.
>> That threshold is now in the primary refinement thread rather than in the
>> dirty card queue set to simplify threshold management and somewhat reduce
>> coupling.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Manual tests with refinement thread logging enabled to verify expected
>> activations occur.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update copyrights

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 188:

> 186:     // rarely (if ever) dirty cards, so defer activation to a post-safepoint
> 187:     // notification.
> 188:     if (SafepointSynchronize::is_at_safepoint()) {

@walulyai noticed that this test was backward.  Difference in testing is often surprisingly subtle, I suspect because there's enough other wonkiness in the refinement thread control to often mask the effect.  This change as a whole is intended as a step toward fixing that.  I'm sure glad Ivan spotted this now though.

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

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


From mli at openjdk.java.net  Wed Feb  2 01:38:06 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 2 Feb 2022 01:38:06 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
Message-ID: <oIEx_9urpqIHOIzbDNz31vKoQ_aHrIF78r3w5yHfidc=.bf8e0e25-5676-4a6e-9ae9-d8d25526e5c6@github.com>

On Tue, 18 Jan 2022 04:31:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

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

Hi Ivan,

Thanks for having a look at this patch. I'm on vacation this week, how about I get back to you next week?

Thanks
-Hamlin

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

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


From ayang at openjdk.java.net  Wed Feb  2 10:47:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 10:47:09 GMT
Subject: RFR: 8281035: Serial: Move RemoveForwardedPointerClosure to local
 scope [v2]
In-Reply-To: <uFPbmCTvFHQ_ZTfkjMlGyWISQe1hUwyIZ_rIQb88otY=.43729e50-2453-4f7c-8cd6-7509131eec7f@github.com>
References: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
 <uFPbmCTvFHQ_ZTfkjMlGyWISQe1hUwyIZ_rIQb88otY=.43729e50-2453-4f7c-8cd6-7509131eec7f@github.com>
Message-ID: <fYlqJJOkcgb77j53RGb6uJmH2mEIz1VGMU0tHHzG3zk=.4db44794-c605-4a32-b3bf-8b47e406dc33@github.com>

On Tue, 1 Feb 2022 15:59:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of moving `RemoveForwardedPointerClosure` from shared code to Serial code.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Feb  2 10:47:10 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 10:47:10 GMT
Subject: RFR: 8281035: Serial: Move RemoveForwardedPointerClosure to local
 scope [v2]
In-Reply-To: <EqKISzsSNzMEex2FqKjUWN3ECdtK2UPPahN_O40lMok=.e2cc8f8f-630b-427e-b20e-fe72996b3992@github.com>
References: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
 <uFPbmCTvFHQ_ZTfkjMlGyWISQe1hUwyIZ_rIQb88otY=.43729e50-2453-4f7c-8cd6-7509131eec7f@github.com>
 <EqKISzsSNzMEex2FqKjUWN3ECdtK2UPPahN_O40lMok=.e2cc8f8f-630b-427e-b20e-fe72996b3992@github.com>
Message-ID: <gxvGMJhkKzUvxR7WXDUBTVDCMGAyoXh_zg60g7UmJKM=.5f5a0d90-1199-4aa9-b668-fdc3786b1508@github.com>

On Tue, 1 Feb 2022 16:45:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/serial/defNewGeneration.cpp line 680:
> 
>> 678:     void do_object(oop obj) override {
>> 679:       if (obj->is_forwarded()) {
>> 680:         obj->init_mark();
> 
> Since it is available, probably use `PreservedMarks::init_forwarded_mark` here.

This closure is not really for "preserved marks", so calling `PreservedMarks::XXX` can be confusing. I will keep the current code and investigate the possibility of removing `PreservedMarks::init_forwarded_mark` in another PR --- its caller should not know anything about "preserved marks" either.

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

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


From ayang at openjdk.java.net  Wed Feb  2 10:47:10 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 10:47:10 GMT
Subject: Integrated: 8281035: Serial: Move RemoveForwardedPointerClosure to
 local scope
In-Reply-To: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
References: <5n5U1ndriV9OZ5E2aIfTUHI9kakiY7Ply05QrYvTUjI=.29b1f5fb-5c99-463c-9323-490f93061f31@github.com>
Message-ID: <JiS-p_hyRMXXC53Hl1cGr3JwLuOQdXF1NT6GXSIGD_o=.a7198e67-2573-44ab-a067-51dac148ddbe@github.com>

On Tue, 1 Feb 2022 11:01:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of moving `RemoveForwardedPointerClosure` from shared code to Serial code.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8281035: Serial: Move RemoveForwardedPointerClosure to local scope

Reviewed-by: kbarrett, tschatzl

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

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


From ayang at openjdk.java.net  Wed Feb  2 11:30:20 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 11:30:20 GMT
Subject: RFR: 8281114: G1: Remove PreservedMarks::init_forwarded_mark
Message-ID: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>

Simple change of inlining `PreservedMarks::init_forwarded_mark` and removing it. This decouples G1 self-forwarded obj handling from preserved marks.

Test: build

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

Commit messages:
 - remove-init_forwarded_mark

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

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


From tschatzl at openjdk.java.net  Wed Feb  2 11:36:02 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 2 Feb 2022 11:36:02 GMT
Subject: RFR: 8281114: G1: Remove PreservedMarks::init_forwarded_mark
In-Reply-To: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
References: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
Message-ID: <E-Zrk6LUFzfQfD-dhGWFe6fW2Hix3Yf2XzOgl-c8HCU=.81910272-92d5-4038-84e3-b98ad307c8fc@github.com>

On Wed, 2 Feb 2022 11:24:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of inlining `PreservedMarks::init_forwarded_mark` and removing it. This decouples G1 self-forwarded obj handling from preserved marks.
> 
> Test: build

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Wed Feb  2 15:19:38 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 15:19:38 GMT
Subject: RFR: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to
 update_for_block
Message-ID: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>

Simple change of renaming certain methods.

Test: build

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

Commit messages:
 - g1-bot-block-rename

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

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


From ayang at openjdk.java.net  Wed Feb  2 15:21:11 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 15:21:11 GMT
Subject: RFR: 8281042: G1: Remove unused init_threshold in
 G1FullGCCompactionPoint
In-Reply-To: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
References: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
Message-ID: <gNnvmHiTn71j8b9tXyAsvQts2AgW48qZnGs3vjz8YrI=.f86c845a-a38c-49bf-b840-cbd327241879@github.com>

On Tue, 1 Feb 2022 13:08:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unused method arg.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Wed Feb  2 15:21:11 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 2 Feb 2022 15:21:11 GMT
Subject: Integrated: 8281042: G1: Remove unused init_threshold in
 G1FullGCCompactionPoint
In-Reply-To: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
References: <0KYSmtwHopcapBn02E5U60PO0KRmXmT4llya80fyeoc=.1f54b091-39d3-48f8-ba84-7460a6688ae3@github.com>
Message-ID: <i1xdjj4JJ0XpuGpLUUCQU2qZclzJsK4eBmrslifiB7s=.1e7ea3ea-0361-4184-b899-aa5afe3b66b0@github.com>

On Tue, 1 Feb 2022 13:08:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unused method arg.
> 
> Test: build

This pull request has now been integrated.

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

8281042: G1: Remove unused init_threshold in G1FullGCCompactionPoint

Reviewed-by: tschatzl, kbarrett

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

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


From duke at openjdk.java.net  Wed Feb  2 22:08:44 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Wed, 2 Feb 2022 22:08:44 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available
Message-ID: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@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

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

Commit messages:
 - 8271195: Resolving jcheck failure.
 - 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available

Changes: https://git.openjdk.java.net/jdk/pull/7326/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7326&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271195
  Stats: 352 lines in 5 files changed: 323 ins; 21 del; 8 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 iwalulya at openjdk.java.net  Thu Feb  3 09:45:07 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 3 Feb 2022 09:45:07 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v3]
In-Reply-To: <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
 <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>
Message-ID: <3ceDnEdEe2SlqTGgK4tPBzHGteRkDK6qlEpZnM10dMw=.5f6f36f7-b88a-41de-a3b7-9acb852fc6fe@github.com>

On Wed, 2 Feb 2022 00:27:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to to G1ConcurrentRefineThreads to simplify the
>> activation mechanism.
>> 
>> We split the class into two subclasses, one for the "primary" refinement
>> thread and another class for the remaining refinement threads.
>> 
>> The secondary threads are changed to use Monitor-based waits and notifications
>> with a supporting request flag.
>> 
>> The primary thread uses an atomic activation threshold that also serves as "is
>> running" state.  This activation threshold is used by the write barrier
>> support to determine whether the thread's semaphore needs to be signaled.
>> That threshold is now in the primary refinement thread rather than in the
>> dirty card queue set to simplify threshold management and somewhat reduce
>> coupling.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Manual tests with refinement thread logging enabled to verify expected
>> activations occur.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix primary thread notification safepoint check

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From ayang at openjdk.java.net  Thu Feb  3 16:56:13 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 3 Feb 2022 16:56:13 GMT
Subject: RFR: 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: <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@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

Changes requested by ayang (Reviewer).

src/hotspot/os/linux/os_linux.cpp line 3782:

> 3780:       os::Linux::setup_large_page(page_size)) {
> 3781:       _large_page_size = page_size;
> 3782:       large_page_found = true;

I don't think this is at the right level: here we don't yet know which kind of large page to use, which is decided in `os::Linux::setup_large_page_type` (the original name).

Instead, the fix should be inside `hugetlbfs_sanity_check`, sth like:


for (local_page_size = page_size; page_size_ != (size_t)os::vm_page_size(); local_page_size = _page_sizes.next_smaller(local_page_size) {
  if (try_commit_using_large_page(local_page_size)) {
    _large_page_size = local_page_size;
    return true;
  }
}

return false;

src/hotspot/os/linux/os_linux.cpp line 4038:

> 4036:   if (!large_committed) {
> 4037:     // Failed to commit large pages, so we need to unmap the whole reservation.
> 4038:     ::munmap(aligned_start, bytes);

I don't understand why this change is related to this ticket/PR, or needed at all.

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

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


From duke at openjdk.java.net  Thu Feb  3 22:28:37 2022
From: duke at openjdk.java.net (Stephanie Crater)
Date: Thu, 3 Feb 2022 22:28:37 GMT
Subject: RFR: 8268387: Rename maximum compaction to maximal compaction in G1
Message-ID: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>

Please review this small change to address Issue [JDK-8268387]( https://bugs.openjdk.java.net/browse/JDK-8268387)

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

Commit messages:
 - Rename maximum compaction to maximal compaction

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

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


From ayang at openjdk.java.net  Fri Feb  4 08:04:11 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 08:04:11 GMT
Subject: RFR: 8268387: Rename maximum compaction to maximal compaction in
 G1
In-Reply-To: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
References: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
Message-ID: <0as5TCPwPY7LMtjh3DZBV9rM6cj_f_0IVTLmtK-hGUs=.7db24451-4ce4-47fe-a88b-a7d93dfa78f5@github.com>

On Thu, 6 Jan 2022 19:21:56 GMT, Stephanie Crater <duke at openjdk.java.net> wrote:

> Please review this small change to address Issue [JDK-8268387]( https://bugs.openjdk.java.net/browse/JDK-8268387)

Marked as reviewed by ayang (Reviewer).

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

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


From shade at openjdk.java.net  Fri Feb  4 09:10:30 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 4 Feb 2022 09:10:30 GMT
Subject: RFR: 8281254: GCs with survivor spaces report Init > Max through
 MXBeans
Message-ID: <zNb-yl2UB34eO3zORuUqw2eYfW0Jg-LS5LPSmMQ70LY=.1898dfb2-0e35-483e-930a-5f38696d3ca5@github.com>

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`

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

Commit messages:
 - Revert extensive changes
 - Fix Parallel too
 - Better fix
 - Fix

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

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


From tschatzl at openjdk.java.net  Fri Feb  4 10:09:10 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 4 Feb 2022 10:09:10 GMT
Subject: RFR: 8268387: Rename maximum compaction to maximal compaction in
 G1
In-Reply-To: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
References: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
Message-ID: <W_LfehlIuaMY7OX0CzxjmaHGY_ilCCUFX6DS1XBgOR0=.1e2c3939-e3ee-440b-8e77-cf89990e2f33@github.com>

On Thu, 6 Jan 2022 19:21:56 GMT, Stephanie Crater <duke at openjdk.java.net> wrote:

> Please review this small change to address Issue [JDK-8268387]( https://bugs.openjdk.java.net/browse/JDK-8268387)

Lgtm.

@calderast: please check the warning provided by the bot and verify everything is okay about attribution before typing `/integrate`:

> the full name on your profile does not match the author name in this pull requests' [HEAD](https://git.openjdk.java.net/jdk/pull/6982/commits/f67c89b8f16c6f682de95c62d7ba11ad7ca44ecb) commit. If this pull request gets integrated then the author name from this pull requests' [HEAD](https://git.openjdk.java.net/jdk/pull/6982/commits/f67c89b8f16c6f682de95c62d7ba11ad7ca44ecb) commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork: [...]

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

Marked as reviewed by tschatzl (Reviewer).

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


From duke at openjdk.java.net  Fri Feb  4 11:35:55 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 11:35:55 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
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: <5ouvmH_2BZBIe4WAs-lZs5iYCBZdJZ3EEb373ZLWvyE=.9eda05f7-f588-40e2-9daa-e962c75cf3fb@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/cb29b832..91ab8255

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

  Stats: 26 lines in 3 files changed: 2 ins; 11 del; 13 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 Feb  4 11:39:11 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 11:39:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
Message-ID: <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>

On Thu, 3 Feb 2022 16:48:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271195: Review comments resolved.
>
> src/hotspot/os/linux/os_linux.cpp line 4038:
> 
>> 4036:   if (!large_committed) {
>> 4037:     // Failed to commit large pages, so we need to unmap the whole reservation.
>> 4038:     ::munmap(aligned_start, bytes);
> 
> I don't understand why this change is related to this ticket/PR, or needed at all.

As mentioned above in case of large page commit failure we were partially un reserving the memory which left holes in the virtual address space , we thought of fixing this along with this patch if you suggest we can fix it under another bug id.

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

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


From ayang at openjdk.java.net  Fri Feb  4 12:10:06 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 12:10:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
Message-ID: <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>

On Fri, 4 Feb 2022 11:35:56 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> which left holes in the virtual address space

That sounds like virtual address leaking; should be dealt with in its own ticket/PR.

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

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


From ayang at openjdk.java.net  Fri Feb  4 12:10:06 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 12:10:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <5ouvmH_2BZBIe4WAs-lZs5iYCBZdJZ3EEb373ZLWvyE=.9eda05f7-f588-40e2-9daa-e962c75cf3fb@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <5ouvmH_2BZBIe4WAs-lZs5iYCBZdJZ3EEb373ZLWvyE=.9eda05f7-f588-40e2-9daa-e962c75cf3fb@github.com>
Message-ID: <9h0_vx3Mn_PMX-SuFHD1wG6NgSt__O1Le6wbD26IloU=.99255c43-c294-4eb1-af5e-b935cf6425aa@github.com>

On Fri, 4 Feb 2022 11:35:55 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: Review comments resolved.

Thank you for the revision; some further comments/suggestions.

src/hotspot/os/linux/os_linux.cpp line 3497:

> 3495: bool os::Linux::hugetlbfs_sanity_check(bool warn, size_t page_size) {
> 3496:    bool large_page_found = false;
> 3497:   // Include the page size flag to ensure we sanity check the correct page size.

This comment should be moved.

src/hotspot/os/linux/os_linux.cpp line 3501:

> 3499:     if (os::Linux::try_commit_using_large_page(local_page_size) && !large_page_found) {
> 3500:       _large_page_size = local_page_size;
> 3501:       large_page_found = true;

I think one can use early-return here, which removes `large_page_found` and the `if (warn)` below is skipped automatically.

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

Changes requested by ayang (Reviewer).

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


From jbhateja at openjdk.java.net  Fri Feb  4 12:23:12 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 4 Feb 2022 12:23:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v2]
In-Reply-To: <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
Message-ID: <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>

On Fri, 4 Feb 2022 11:57:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> As mentioned above in case of large page commit failure we were partially un reserving the memory which left holes in the virtual address space , we thought of fixing this along with this patch if you suggest we can fix it under another bug id.
>
>> which left holes in the virtual address space
> 
> That sounds like virtual address leaking; should be dealt with in its own ticket/PR.

New ticket created:
https://bugs.openjdk.java.net/browse/JDK-8281263

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

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


From duke at openjdk.java.net  Fri Feb  4 12:50:49 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Fri, 4 Feb 2022 12:50:49 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
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: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@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/91ab8255..fadcb5b9

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

  Stats: 12 lines in 1 file changed: 3 ins; 1 del; 8 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 ayang at openjdk.java.net  Fri Feb  4 13:33:11 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 13:33:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <0gWuDe6CyHrJonoeEgLjWAh_QfjZBn15zH4-vhfMzTA=.cc325724-239f-4a84-a43f-17df843bb7b9@github.com>

On Fri, 4 Feb 2022 12:50:49 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: Review comments resolved.

Two small and subjective suggestions:

1. `try_commit_using_large_page` can be dropped from the header (API), (i.e. change to a file-local function, `static bool try_commit_using_large_page(...) {...}`.
2. Placing `log_info` inside `hugetlbfs_sanity_check` feels cleaner (the assignment is next to the msg), sth like:


if (try_commit_using_large_page...) {
  _large_page_size = ...
  log_info(... success ...);
  return true;
}
log_info(... fail ...);


I don't see much benefit of adding `MicroLargePages.java`. Would be nice if someone more experience on this can share their opinions.

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

Marked as reviewed by ayang (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Feb  4 13:42:10 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 4 Feb 2022 13:42:10 GMT
Subject: RFR: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to
 update_for_block
In-Reply-To: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
References: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
Message-ID: <bEac9BOa8BY-Crl8huj-NDIDlx603TWwfh3JCP6KGiA=.5273618e-0022-4e16-bc5c-8d8588b00d4b@github.com>

On Wed, 2 Feb 2022 15:07:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of renaming certain methods.
> 
> Test: build

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Fri Feb  4 14:33:15 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 4 Feb 2022 14:33:15 GMT
Subject: RFR: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to
 update_for_block
In-Reply-To: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
References: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
Message-ID: <_m8_Z1vrraF9WTtyhxRrim8PaO14Eub-JJ5am_SXyXs=.7f5eb3cd-4a2c-4cb5-aa43-99d058931d04@github.com>

On Wed, 2 Feb 2022 15:07:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of renaming certain methods.
> 
> Test: build

Marked as reviewed by iwalulya (Reviewer).

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

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


From sjohanss at openjdk.java.net  Fri Feb  4 14:40:08 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 4 Feb 2022 14:40:08 GMT
Subject: RFR: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to
 update_for_block
In-Reply-To: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
References: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
Message-ID: <iIty_yuI-sO57aO55Otdv0erkvNJSAKO_jn5GIuoMek=.69b7cf41-1f09-40d1-b7e1-1ae171b2d9b3@github.com>

On Wed, 2 Feb 2022 15:07:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of renaming certain methods.
> 
> Test: build

Nice cleanup!

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Fri Feb  4 15:11:12 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 4 Feb 2022 15:11:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
Message-ID: <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>

On Fri, 4 Feb 2022 12:20:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> which left holes in the virtual address space
>> 
>> That sounds like virtual address leaking; should be dealt with in its own ticket/PR.
>
> New ticket created:
> https://bugs.openjdk.java.net/browse/JDK-8281263

The documentation around `mmap` with MAP_FIXED is not crystal clear on failure. In the case we return false from `commit_memory_special(...)` the commit over the reserved range failed and I'm pretty sure that when it does the virtual memory range reserved becomes available to the system again and might be reused by some other thread. So unmapping that range would break any such reservation. @stefank isn't this what we've had problems with in the past?

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

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


From stuefe at openjdk.java.net  Fri Feb  4 15:28:07 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:28:07 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>

On Fri, 4 Feb 2022 12:50:49 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: Review comments resolved.

Hi @swati-sha,

What tests have you run, and on what hardware?

It would be nice if @kstefanj could take a look at this.

> 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.

This text (and the description in the associated JBS issue) are a bit confusing. What should be the desired behavior of LargePageSizeInBytes wrt to heap allocation?

Currently, the behavior is different between code cache and heap: 
1) For code cache `LargePageSizeInBytes` means the largest possible page size to use, with the explicit permission to use smaller ones where available. 
2) For the heap, `LargePageSizeInBytes` means "use that or no large pages at all".
Both behaviors could make sense. (2) could make sense if the administrator set up a 2M pool for some other program and now it gets gnawed at by the JVM. Though admittedly that seems contrived. "Use that or fail" would make more sense.

Unfortunately, the java man page is no help:


LargePageSizeInBytes
Sets the maximum large page size (in bytes) used by the JVM.


... could mean either 1 or 2.

The code cache side we had extensively discussed when reviewing https://bugs.openjdk.java.net/browse/JDK-8256155. 

> 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.

This part of the PR text is confusing. I do not find this in the patch. Does the text match the code? Note that it would make sense in a separate bug fix.

Cheers, Thomas

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

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


From stefank at openjdk.java.net  Fri Feb  4 15:28:08 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 4 Feb 2022 15:28:08 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
Message-ID: <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>

On Fri, 4 Feb 2022 15:07:54 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> New ticket created:
>> https://bugs.openjdk.java.net/browse/JDK-8281263
>
> The documentation around `mmap` with MAP_FIXED is not crystal clear on failure. In the case we return false from `commit_memory_special(...)` the commit over the reserved range failed and I'm pretty sure that when it does the virtual memory range reserved becomes available to the system again and might be reused by some other thread. So unmapping that range would break any such reservation. @stefank isn't this what we've had problems with in the past?

Yes, that is my understanding.

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

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


From stuefe at openjdk.java.net  Fri Feb  4 15:37:23 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:37:23 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <QyrvbOGAcOvJnAQIColOCMsNTRx86MlYoaK-uVjCOcs=.ef595e77-5380-44d2-a06b-e43e7786509d@github.com>

On Fri, 4 Feb 2022 12:50:49 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: Review comments resolved.

BTW, if we want to implement a fluid fallback to smaller large page sizes, I am not sure we want to rely on a test done during VM initialization. The VM could wish to reserve+commit large pages at any point later, and the state of the huge page pool may be different then from when the VM started.

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

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


From ayang at openjdk.java.net  Fri Feb  4 15:41:08 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 15:41:08 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
Message-ID: <E1JfaIjErYy3Mn5igm-cta4E7N_H32BCT2EdMS4omrQ=.b3ff7b89-5cec-4a66-8737-08e9d951777c@github.com>

On Fri, 4 Feb 2022 15:24:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> For the heap, LargePageSizeInBytes means "use that or no large pages at all".

@tstuefe, with https://bugs.openjdk.java.net/browse/JDK-8265517, such flag has the same semantic for code cache and heap.

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

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


From stuefe at openjdk.java.net  Fri Feb  4 15:45:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:45:15 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
Message-ID: <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>

On Fri, 4 Feb 2022 15:22:18 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The documentation around `mmap` with MAP_FIXED is not crystal clear on failure. In the case we return false from `commit_memory_special(...)` the commit over the reserved range failed and I'm pretty sure that when it does the virtual memory range reserved becomes available to the system again and might be reused by some other thread. So unmapping that range would break any such reservation. @stefank isn't this what we've had problems with in the past?
>
> Yes, that is my understanding.

I believe it was https://bugs.openjdk.java.net/browse/JDK-8007074. Wasn't that the reason that large page memory on Linux gets committed right away when reserving?

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

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


From stuefe at openjdk.java.net  Fri Feb  4 15:51:10 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:51:10 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <E1JfaIjErYy3Mn5igm-cta4E7N_H32BCT2EdMS4omrQ=.b3ff7b89-5cec-4a66-8737-08e9d951777c@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
 <E1JfaIjErYy3Mn5igm-cta4E7N_H32BCT2EdMS4omrQ=.b3ff7b89-5cec-4a66-8737-08e9d951777c@github.com>
Message-ID: <-GSxZS2hPzJPshDBM_q4ut0ArzIUVDLJZb5hZc1G-nE=.93a4e6d8-16dd-4509-b1ea-d02aaad683ec@github.com>

On Fri, 4 Feb 2022 15:37:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > For the heap, LargePageSizeInBytes means "use that or no large pages at all".
> 
> @tstuefe, with https://bugs.openjdk.java.net/browse/JDK-8265517, such flag has the same semantic for code cache and heap.

Thank you @albertnetymk! I now remember this again. So the rule is the JVM is free to use whatever large pages it finds, up to and including LargePageSizeInBytes. Okay, then this patch makes sense.

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

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


From stuefe at openjdk.java.net  Fri Feb  4 15:51:11 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 4 Feb 2022 15:51:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
 <4MYFmc_guIJUYgrvOZLXmXYPvfu6HsJQMD4Ch04425w=.3b879fb2-1f78-4742-8d94-2833f075a1a8@github.com>
Message-ID: <l5CA6f_vm5xos_4BWSVC_yO3sE5zhZMTe460TwM3bog=.b394e5a7-3603-42a9-8916-63d638202e65@github.com>

On Fri, 4 Feb 2022 15:24:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This part of the PR text is confusing. I do not find this in the patch. Does the text match the code? Note that it would make sense in a separate bug fix.

My fault, I see from the PR discussion that this part moved to https://bugs.openjdk.java.net/browse/JDK-8281263. Could you please update the PR text?

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

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


From stefank at openjdk.java.net  Fri Feb  4 15:51:11 2022
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Fri, 4 Feb 2022 15:51:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
Message-ID: <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>

On Fri, 4 Feb 2022 15:41:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Yes, that is my understanding.
>
> I believe it was https://bugs.openjdk.java.net/browse/JDK-8007074. Wasn't that the reason that large page memory on Linux gets committed right away when reserving?

Yes, it was.

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

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


From ayang at openjdk.java.net  Fri Feb  4 16:07:12 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 16:07:12 GMT
Subject: RFR: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to
 update_for_block
In-Reply-To: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
References: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
Message-ID: <lk1pYO5W249rOfiF57xjV9ywZKOqZ64CCMEnCdM_sYc=.924a6b2d-8dbf-4924-b695-c7edeb7a62b4@github.com>

On Wed, 2 Feb 2022 15:07:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of renaming certain methods.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Fri Feb  4 16:07:12 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 4 Feb 2022 16:07:12 GMT
Subject: Integrated: 8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to
 update_for_block
In-Reply-To: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
References: <veJoM13oAGnB3hrUM9p0WvVNSv0kyn4KkMCwbb2z5OI=.8b6b8565-51c8-4878-a4c3-278251016a53@github.com>
Message-ID: <YjDZ72EJ2uPCD0gICu47LQJBaUx4al2JUntLPI6D55I=.4a88a039-bd7b-461c-91a4-38d96acae65a@github.com>

On Wed, 2 Feb 2022 15:07:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of renaming certain methods.
> 
> Test: build

This pull request has now been integrated.

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

8281120: G1: Rename G1BlockOffsetTablePart::alloc_block to update_for_block

Reviewed-by: tschatzl, iwalulya, sjohanss

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

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


From sjohanss at openjdk.java.net  Fri Feb  4 16:17:16 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 4 Feb 2022 16:17:16 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <6fgGHJm8ALeo5Wy8QKBibga_sHcCWnON9FHT2n6wAZA=.22a84a1e-cbad-46ff-af04-4c145af7bd9d@github.com>

On Fri, 4 Feb 2022 12:50:49 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: Review comments resolved.

Hi @swati-sha and @tstuefe,

I was thinking the same thing, that you should see this PR :)

As mentioned this was discussed a lot in the review for [JDK-8256155](https://bugs.openjdk.java.net/browse/JDK-8256155). That said, I think there is room for improvement. What we settled on back then was that if any large page size passed the sanity check we consider large pages enabled. It can then of course look strange in some cases, but often when things are not working as expected it is because of some configuration "issue". 

I suspect that the problem you are running into is that the default large page size is 1G, but you only have 2M pages configured. The simple work-around for this issue would be to specify `-XX:LargePageSizeInBytes=2m` but it would of course be good if it worked out of the box. 

I did play around a bit trying to solve this, but it got shelved. I did try to solve it in the `ReservedSpace` layer instead. This would satisfy Thomas comment about not relying to much on checks at startup. I did something like: 


    diff --git a/src/hotspot/share/memory/virtualspace.cpp b/src/hotspot/share/memory/virtualspace.cpp
index c5f682bb31f..80d0910f150 100644
--- a/src/hotspot/share/memory/virtualspace.cpp
+++ b/src/hotspot/share/memory/virtualspace.cpp
@@ -235,11 +235,20 @@ void ReservedSpace::reserve(size_t size,
     // the caller requested large pages. To satisfy this request we use
     // explicit large pages and these have to be committed up front to ensure
     // no reservations are lost.
+    size_t used_page_size = page_size;
+    char* base = NULL;
+
+    do {
+      base = reserve_memory_special(requested_address, size, alignment, used_page_size, executable);
+      if (base != NULL) {
+        break;
+      }
+      used_page_size = os::page_sizes().next_smaller(used_page_size);
+    } while (used_page_size > (size_t) os::vm_page_size());
 
-    char* base = reserve_memory_special(requested_address, size, alignment, page_size, executable);
     if (base != NULL) {
       // Successful reservation using large pages.
-      initialize_members(base, size, alignment, page_size, true, executable);
+      initialize_members(base, size, alignment, used_page_size, true, executable);
       return;
     }
     // Failed to reserve explicit large pages, fall back to normal reservation.

This is completely untested, and there might be some other tweaks needed to make it work. What do you think about this kind of approach?

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

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


From jbhateja at openjdk.java.net  Fri Feb  4 18:24:12 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 4 Feb 2022 18:24:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
 <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
Message-ID: <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>

On Fri, 4 Feb 2022 15:47:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I believe it was https://bugs.openjdk.java.net/browse/JDK-8007074. Wasn't that the reason that large page memory on Linux gets committed right away when reserving?
>
> Yes, it was.

MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.

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

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


From duke at openjdk.java.net  Fri Feb  4 21:56:50 2022
From: duke at openjdk.java.net (Stephanie Crater)
Date: Fri, 4 Feb 2022 21:56:50 GMT
Subject: RFR: 8268387: Rename maximum compaction to maximal compaction in
 G1 [v2]
In-Reply-To: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
References: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
Message-ID: <bIzeUh2_NZ6OWqvsqtSr7y4czZTVURsBbBmLAR5KwCU=.8a476dec-8224-4997-94ae-a43bd845cc27@github.com>

> Please review this small change to address Issue [JDK-8268387]( https://bugs.openjdk.java.net/browse/JDK-8268387)

Stephanie Crater has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Rename maximum compaction to maximal compaction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6982/files
  - new: https://git.openjdk.java.net/jdk/pull/6982/files/f67c89b8..dac8c148

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

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

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


From kbarrett at openjdk.java.net  Sat Feb  5 07:51:02 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 5 Feb 2022 07:51:02 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v2]
In-Reply-To: <grhuTkPL-yEPqw9Odz7hE_n_yyidnpDN1uEQ5pNTXVY=.dbb21a97-f9fd-450d-ab01-003daf302771@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
 <tnNhY7ceFB2k19wXtxY9YODMusnQFjaP6x_OMnRWdI4=.f81e9f8b-9d9a-4cf5-be86-dfe8a122c32e@github.com>
 <grhuTkPL-yEPqw9Odz7hE_n_yyidnpDN1uEQ5pNTXVY=.dbb21a97-f9fd-450d-ab01-003daf302771@github.com>
Message-ID: <4vntn5cB5-1GjFm0elD6x2jmxvAtTmYg9NzgLwLdo7o=.f3d50842-c7cc-47a7-9871-dfafe0b47bce@github.com>

On Wed, 2 Feb 2022 00:22:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update copyrights
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 188:
> 
>> 186:     // rarely (if ever) dirty cards, so defer activation to a post-safepoint
>> 187:     // notification.
>> 188:     if (SafepointSynchronize::is_at_safepoint()) {
> 
> @walulyai noticed that this test was backward.  Difference in testing is often surprisingly subtle, I suspect because there's enough other wonkiness in the refinement thread control to often mask the effect.  This change as a whole is intended as a step toward fixing that.  I'm sure glad Ivan spotted this now though.

I re-ran tests and ran some additional with this mistake fixed.  No problems encountered.  I also did some better performance testing.  specjbb2015 with options that will trigger the need for more concurrent refinement was unchanged between baseline and with the above fixed.  Having the test backward produced a 6-7% regression.  Thanks again Ivan.

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

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


From shade at openjdk.java.net  Mon Feb  7 06:39:10 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 7 Feb 2022 06:39:10 GMT
Subject: RFR: 8281254: GCs with survivor spaces report Init > Max through
 MXBeans
In-Reply-To: <4blvxuU-uHUbJr2_uJO90RoNTesaMv7CkE-ky7kwlQs=.40ed4857-0a42-4447-8a4a-f2c9626a1642@github.com>
References: <zNb-yl2UB34eO3zORuUqw2eYfW0Jg-LS5LPSmMQ70LY=.1898dfb2-0e35-483e-930a-5f38696d3ca5@github.com>
 <ujpO8ECtfJhyKB2-yDIh5DGUL9knak2BTfAyj-dxy2E=.62d61238-6b55-434d-bdfd-b22cc87bcba2@github.com>
 <4blvxuU-uHUbJr2_uJO90RoNTesaMv7CkE-ky7kwlQs=.40ed4857-0a42-4447-8a4a-f2c9626a1642@github.com>
Message-ID: <uxLPPAwGZCH-411VLOYSKhqvfwltyuYJZOcEJcKSl0g=.9347d536-0649-405d-a6c2-2624acacd731@github.com>

On Fri, 4 Feb 2022 10:11:39 GMT, Artem Zinnatullin :slowpoke: <duke at openjdk.java.net> wrote:

>> test/hotspot/jtreg/gc/TestInitMaxMemoryMXBeans.java line 87:
>> 
>>> 85:         long heapMax = memoryMXBean.getHeapMemoryUsage().getMax();
>>> 86: 
>>> 87:         if (heapInit != heapMax) {
>> 
>> nice
>
> do you want to also check the actual value to verify there is no future regression or will it differ depending on GC engine?

Unfortunately, it would differ by GC. Serial and Parallel would subtract survivor space, so they would report lower values. Matching those values directly would mean duplicating the GC-specific logic in the test.

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

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


From duke at openjdk.java.net  Mon Feb  7 08:36:12 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 7 Feb 2022 08:36:12 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@github.com>

On Fri, 4 Feb 2022 12:50:49 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: Review comments resolved.

> Hi @swati-sha and @tstuefe,
> 
> I was thinking the same thing, that you should see this PR :)
> 
> As mentioned this was discussed a lot in the review for [JDK-8256155](https://bugs.openjdk.java.net/browse/JDK-8256155). That said, I think there is room for improvement. What we settled on back then was that if any large page size passed the sanity check we consider large pages enabled. It can then of course look strange in some cases, but often when things are not working as expected it is because of some configuration "issue".
> 
> I suspect that the problem you are running into is that the default large page size is 1G, but you only have 2M pages configured. The simple work-around for this issue would be to specify `-XX:LargePageSizeInBytes=2m` but it would of course be good if it worked out of the box.
> 
> I did play around a bit trying to solve this, but it got shelved. I did try to solve it in the `ReservedSpace` layer instead. This would satisfy Thomas comment about not relying to much on checks at startup. I did something like:
> 
> ```diff
>     diff --git a/src/hotspot/share/memory/virtualspace.cpp b/src/hotspot/share/memory/virtualspace.cpp
> index c5f682bb31f..80d0910f150 100644
> --- a/src/hotspot/share/memory/virtualspace.cpp
> +++ b/src/hotspot/share/memory/virtualspace.cpp
> @@ -235,11 +235,20 @@ void ReservedSpace::reserve(size_t size,
>      // the caller requested large pages. To satisfy this request we use
>      // explicit large pages and these have to be committed up front to ensure
>      // no reservations are lost.
> +    size_t used_page_size = page_size;
> +    char* base = NULL;
> +
> +    do {
> +      base = reserve_memory_special(requested_address, size, alignment, used_page_size, executable);
> +      if (base != NULL) {
> +        break;
> +      }
> +      used_page_size = os::page_sizes().next_smaller(used_page_size);
> +    } while (used_page_size > (size_t) os::vm_page_size());
>  
> -    char* base = reserve_memory_special(requested_address, size, alignment, page_size, executable);
>      if (base != NULL) {
>        // Successful reservation using large pages.
> -      initialize_members(base, size, alignment, page_size, true, executable);
> +      initialize_members(base, size, alignment, used_page_size, true, executable);
>        return;
>      }
>      // Failed to reserve explicit large pages, fall back to normal reservation.
> ```
> 
> This is completely untested, and there might be some other tweaks needed to make it work. What do you think about this kind of approach?

Hi @kstefanj ,

Your proposed fix is not going to fix the alignment which will be incorrect wrt. the page_size and it may result 
into internal fragmentation within virtual address space which by the way is not a constraint but is a minor functional issue.
Also we are leaving incorrect value in _large_page_size(global variable) which is being used at several places.

Seek your opinion if above issues will not impact the functionality in any manner.

Thanks and Regards, 
Swati Sharma

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

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


From sjohanss at openjdk.java.net  Mon Feb  7 09:37:06 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 09:37:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <QsOdS-_44iMRK10b6HD54DDfi1FyttrObKUViaZGFZc=.09f95019-e91c-414f-9acd-9859e4df3d29@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>
Message-ID: <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@github.com>

On Mon, 7 Feb 2022 08:32:53 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Your proposed fix is not going to fix the alignment which will be incorrect wrt. the page_size and it may result into internal fragmentation within virtual address space which by the way is not a constraint but is a minor functional issue. Also we are leaving incorrect value in _large_page_size(global variable) which is being used at several places.
> 
Correct, the alignment will be that of the initial requested/configured large page size, but any smaller large page size will still be aligned wrt to this alignment. I don't see any real problem with this. Sure we will require the reservation to be aligned to something larger that finally needed, but given that the number of such reservations won't be very many I think using this kind of fallback mechanism is ok.
 
Regarding the value left in `_large_page_size`, yes at startup this value was not usable but it is the configured value for the JVM (either by being the default for the system or by passing LargePageSizeInBytes). The discussions in the passed have lead to not changing this since that might lead to more confusing behavior. 

> Seek your opinion if above issues will not impact the functionality in any manner.

One problem, that is kind of related to this (and also was on my backlog to investigate), is that we are using `os::large_page_size()` as the alignment for the heap. This means that if you request a 128m heap with a 512m large page size the heap will be aligned up to 512m. This happens regardless if 512m pages are available or not, so it is kind of a different issue. The heap alignment should probably do something similar as other reservations and use ?os::page_size_for_region(...)?. There might also be additional things related to this, where the use of `os::large_page_size()` should be looked at because we allow multiple large page sizes to be used.

Another thing that has been discussed in the passed is how to handle the logging around this. Currently you need to enable logging with `pagesize` (`-Xlog:pagesize`) to get feedback on the configuration, it might make sense to move parts of this to a level that is always shown: 

[0.001s][info][pagesize] Using the default large page size: 512M
[0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
[0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
[0.001s][info][pagesize] Large page size (2M) passed sanity check

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

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


From sjohanss at openjdk.java.net  Mon Feb  7 10:30:14 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 10:30:14 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
 <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
 <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>
Message-ID: <vfbTMG8rQ-LaPfQMFFg5ADGb_nlkpGelT6-Xu4HMcJw=.3d9edb45-7b9b-40b7-bea6-ce36b2e00635@github.com>

On Fri, 4 Feb 2022 18:20:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes, it was.
>
> MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.

I'm sorry, I don't fully follow your reasoning. Are you agreeing that this is not a problem?

To re-iterate what we have seen in the past: a reservation passing a NULL argument as the requested address is mapped on an address where a failed large page commit occurred (for this to happen, the previous reservation must have been release by the failure). This has lead us to require that the complete reservation is committed up front when using large pages, because we cannot risk loosing part of a reservation later in the execution. 

You can read more about this in the bug linked by @tstuefe and I think [this comments](https://bugs.openjdk.java.net/browse/JDK-8007074?focusedCommentId=13306490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13306490) and the ones below explain the problem very well.

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

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


From sjohanss at openjdk.java.net  Mon Feb  7 11:12:04 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 11:12:04 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v3]
In-Reply-To: <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
 <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>
Message-ID: <9pGv3gbIZWAYMSac0Zb9fFrAv5KhNbNGKQ_LBjB6RDE=.6d99ecaa-aa10-4c58-800e-b264ba48e788@github.com>

On Wed, 2 Feb 2022 00:27:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to to G1ConcurrentRefineThreads to simplify the
>> activation mechanism.
>> 
>> We split the class into two subclasses, one for the "primary" refinement
>> thread and another class for the remaining refinement threads.
>> 
>> The secondary threads are changed to use Monitor-based waits and notifications
>> with a supporting request flag.
>> 
>> The primary thread uses an atomic activation threshold that also serves as "is
>> running" state.  This activation threshold is used by the write barrier
>> support to determine whether the thread's semaphore needs to be signaled.
>> That threshold is now in the primary refinement thread rather than in the
>> dirty card queue set to simplify threshold management and somewhat reduce
>> coupling.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Manual tests with refinement thread logging enabled to verify expected
>> activations occur.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix primary thread notification safepoint check

Looks good, just a couple of small comments.

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 64:

> 62:   // Returns true if should deactivate.
> 63:   // precondition: this is the current thread.
> 64:   virtual bool maybe_deactivate() = 0;

I know the name is pre-existing, but I've always found the naming it a bit odd. Or we usually call thing like this `should_deactivate()`. If you prefer keeping the old name I'm fine with it, just wanted to mention it since we are changing the code.

src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 94:

> 92:   Semaphore _notifier;
> 93:   DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, 0);
> 94:   volatile size_t _threshold;

Might make sense to add some additional comment for the threshold, similar to the description you have in the PR summary: 

The primary thread uses an atomic activation threshold that also serves as "is
running" state. This activation threshold is used by the write barrier
support to determine whether the thread's semaphore needs to be signaled.

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

Marked as reviewed by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Feb  7 11:16:07 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 11:16:07 GMT
Subject: RFR: 8281114: G1: Remove PreservedMarks::init_forwarded_mark
In-Reply-To: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
References: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
Message-ID: <ryzfkv13DkQjfUsgZqkvz6c0Ljn2N3nJKFpf2bPTfXU=.82b0475f-1ff0-4c71-8f49-b341ca122240@github.com>

On Wed, 2 Feb 2022 11:24:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of inlining `PreservedMarks::init_forwarded_mark` and removing it. This decouples G1 self-forwarded obj handling from preserved marks.
> 
> Test: build

Looks good!

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

Marked as reviewed by sjohanss (Reviewer).

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


From jbhateja at openjdk.java.net  Mon Feb  7 11:51:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 7 Feb 2022 11:51:09 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <vfbTMG8rQ-LaPfQMFFg5ADGb_nlkpGelT6-Xu4HMcJw=.3d9edb45-7b9b-40b7-bea6-ce36b2e00635@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <X5R39cp8w7RisGZyNd1iaRfiQ1TWuLoK7ckKGx39ASE=.45f27f09-9119-4bf9-a67d-13b3d4ccf804@github.com>
 <r_GCLMgB1QjLcbN_fVbv0BnGrVHDJeJnORq_6b3_420=.d186e338-cd32-459b-9e85-ec52fe710fe2@github.com>
 <p07qtucUKWTxZOYBHJS6M88zt3t_rE1V9EutKp_KNt8=.73dcffe6-ee82-4a3d-8be0-4f05704b2b8b@github.com>
 <gvgJr8aEz95RE8YUGeejHUJyoUqrLtLEBxCFE8-3DEE=.61b2d9cc-c797-4c6b-bf69-176bb1819911@github.com>
 <qqZ7HSwqT6jpTAymYa-MThM1fIuVPbEtssVASICNYvQ=.401551a9-5b91-4c4f-973b-28de7a5c1350@github.com>
 <v9HortLu16-YQ-XH5AlJM9dmIslIVCnjL8rxjRX-mIE=.ac194d00-375d-4232-879c-fef224c43b03@github.com>
 <jNH3w9dufuuBBCWkVmbAE-chgUKq8M8PH6XtZDI3_KE=.71051a7a-a120-4510-b7ab-c2209b4218ba@github.com>
 <c5ls2caYem1tsZi2dFWEh6qiLUCBsjEP3nB9dUZvYAg=.bc47d641-3202-49a7-96d1-3869f5fc9a42@github.com>
 <27k3oROE0euIIuvPQUavgo-xCybjqoksNx5PYyO6MJU=.b46bcf6c-c772-4284-b8b7-a9e2188e6632@github.com>
 <vfbTMG8rQ-LaPfQMFFg5ADGb_nlkpGelT6-
 Xu4HMcJw=.3d9edb45-7b9b-40b7-bea6-ce36b2e00635@github.com>
Message-ID: <NXkBm0IcuOoTkswSGiHrGZgn_vak2T3lraSK3XNKEPs=.c9b4329f-4a48-4d14-9d3b-f14f5bc89201@github.com>

On Mon, 7 Feb 2022 10:27:00 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> MAP_FIXED semantics are clear here, any existing reserved mapping will get overridden if a new commit happens over it, but only if new commit happens over the existing reserved address space, reservation takes a NULL address argument and returns the block of virtual memory which can be committed by binding it to large pages, since we are not bookkeeping the reserved memory space for any subsequent commit hence won't any unreserved virtual memory from a previous commit failure cause a leak in the virtual address space.
>
> I'm sorry, I don't fully follow your reasoning. Are you agreeing that this is not a problem?
> 
> To re-iterate what we have seen in the past: a reservation passing a NULL argument as the requested address is mapped on an address where a failed large page commit occurred (for this to happen, the previous reservation must have been release by the failure). This has lead us to require that the complete reservation is committed up front when using large pages, because we cannot risk loosing part of a reservation later in the execution. 
> 
> You can read more about this in the bug linked by @tstuefe and I think [this comments](https://bugs.openjdk.java.net/browse/JDK-8007074?focusedCommentId=13306490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13306490) and the ones below explain the problem very well.

Yes, it seem this may turn to be not-a-bug.

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

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


From duke at openjdk.java.net  Mon Feb  7 12:18:08 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 7 Feb 2022 12:18:08 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <l7h6uf81qZ7uTsduSnlXkwMumgjeOrB0q-NXTi9ZT-s=.bbaf0b57-2513-4e3c-808b-6ace94da04da@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>
Message-ID: <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@github.com>

On Mon, 7 Feb 2022 09:33:34 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > Your proposed fix is not going to fix the alignment which will be incorrect wrt. the page_size and it may result into internal fragmentation within virtual address space which by the way is not a constraint but is a minor functional issue. Also we are leaving incorrect value in _large_page_size(global variable) which is being used at several places.
> 
> Correct, the alignment will be that of the initial requested/configured large page size, but any smaller large page size will still be aligned wrt to this alignment. I don't see any real problem with this. Sure we will require the reservation to be aligned to something larger that finally needed, but given that the number of such reservations won't be very many I think using this kind of fallback mechanism is ok.
> 
> Regarding the value left in `_large_page_size`, yes at startup this value was not usable but it is the configured value for the JVM (either by being the default for the system or by passing LargePageSizeInBytes). The discussions in the passed have lead to not changing this since that might lead to more confusing behavior.
> 
> > Seek your opinion if above issues will not impact the functionality in any manner.
> 
> One problem, that is kind of related to this (and also was on my backlog to investigate), is that we are using `os::large_page_size()` as the alignment for the heap. This means that if you request a 128m heap with a 512m large page size the heap will be aligned up to 512m. This happens regardless if 512m pages are available or not, so it is kind of a different issue. The heap alignment should probably do something similar as other reservations and use ?os::page_size_for_region(...)?. There might also be additional things related to this, where the use of `os::large_page_size()` should be looked at because we allow multiple large page sizes to be used.
> 
> Another thing that has been discussed in the passed is how to handle the logging around this. Currently you need to enable logging with `pagesize` (`-Xlog:pagesize`) to get feedback on the configuration, it might make sense to move parts of this to a level that is always shown:
> 
> ```
> [0.001s][info][pagesize] Using the default large page size: 512M
> [0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
> [0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][info][pagesize] Large page size (2M) passed sanity check
> ```

Hi @kstefanj ,

Are you suggesting that its ok not to honor the alignment which is based on the original large page size?

Thanks and Regards,
Swati Sharma

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

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


From ayang at openjdk.java.net  Mon Feb  7 12:30:07 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Feb 2022 12:30:07 GMT
Subject: RFR: 8281114: G1: Remove PreservedMarks::init_forwarded_mark
In-Reply-To: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
References: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
Message-ID: <EA8xPPKPnUNsZIXvZHpOsURg1KVDxW720pYZjpFe-So=.f3c32853-cb18-408f-969e-c79edb4525e1@github.com>

On Wed, 2 Feb 2022 11:24:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of inlining `PreservedMarks::init_forwarded_mark` and removing it. This decouples G1 self-forwarded obj handling from preserved marks.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Feb  7 12:30:07 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 7 Feb 2022 12:30:07 GMT
Subject: Integrated: 8281114: G1: Remove PreservedMarks::init_forwarded_mark
In-Reply-To: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
References: <7loahNApuDvgiLox5zjUiDizfO8uiqEjqKAveUmHQ1k=.25876e3f-ec3a-46a1-8e2b-2d1c3eea5866@github.com>
Message-ID: <Bx0wRujaOSed1LASJZ7KxVz83nPtP0-EusdEfgntukc=.96c821c2-8312-4beb-9cbd-4925338892c9@github.com>

On Wed, 2 Feb 2022 11:24:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of inlining `PreservedMarks::init_forwarded_mark` and removing it. This decouples G1 self-forwarded obj handling from preserved marks.
> 
> Test: build

This pull request has now been integrated.

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

8281114: G1: Remove PreservedMarks::init_forwarded_mark

Reviewed-by: tschatzl, sjohanss

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

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


From duke at openjdk.java.net  Mon Feb  7 12:47:06 2022
From: duke at openjdk.java.net (Stephanie Crater)
Date: Mon, 7 Feb 2022 12:47:06 GMT
Subject: Integrated: 8268387: Rename maximum compaction to maximal compaction
 in G1
In-Reply-To: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
References: <_Modz1qaofd3VpGoNVv6x7zjGZOmNVug176y08hCGuA=.9e434168-fc51-42d9-9440-b2e6f7ef1528@github.com>
Message-ID: <v3V7MY74azSKVQPiN7GE7eoGcSNIkh0EnTxwR1dNXNo=.66d68206-2954-44df-a2ef-aab50ca9578a@github.com>

On Thu, 6 Jan 2022 19:21:56 GMT, Stephanie Crater <duke at openjdk.java.net> wrote:

> Please review this small change to address Issue [JDK-8268387]( https://bugs.openjdk.java.net/browse/JDK-8268387)

This pull request has now been integrated.

Changeset: 22a1a32c
Author:    Stephanie Crater <scrater at microsoft.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/22a1a32c7e5ceb7be6725f5369dcfc2a11fecc2f
Stats:     21 lines in 6 files changed: 0 ins; 0 del; 21 mod

8268387: Rename maximum compaction to maximal compaction in G1

Reviewed-by: ayang, tschatzl

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

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


From sjohanss at openjdk.java.net  Mon Feb  7 13:26:05 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 13:26:05 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <2_Wq79NZDOQX2R8guGZhYCKcqw5PJEgweGNaePAwpKs=.be3d7a65-34d7-45ab-bd2d-8add502fcd5d@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>
Message-ID: <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@github.com>

On Mon, 7 Feb 2022 12:15:03 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

> Are you suggesting that its ok not to honor the alignment which is based on the original large page size?

Hi @swati-sha, 

Not really, we need to make sure the alignment is honored wrt the large page size used (using a larger alignment is still fine though). But I think it would be good to investigate if we could do better during startup if multiple large page sizes are available. I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m. Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.

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

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


From stuefe at openjdk.java.net  Mon Feb  7 14:34:03 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 7 Feb 2022 14:34:03 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <oYjcFpwmMU8TNkm7U3Uo6I6aYz7m24CgU73Q3t6JrMo=.0328c243-9f02-4cbb-9d6e-b64b34172e77@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>
Message-ID: <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@github.com>

On Mon, 7 Feb 2022 13:23:20 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m. 

I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475

> Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.

I would actually like the following behavior:
- LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
- when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).

I think this is close to what we do now.

So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
- a single 1G page and 256 2m pages for the heap
- 128 2m pages for the code cache
... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.

Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?

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

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


From sjohanss at openjdk.java.net  Mon Feb  7 15:13:11 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 7 Feb 2022 15:13:11 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <TzZ-ePfnwv0hX-cGEZz5gdNCNXH27LXNkabOeJHfpRI=.00b47ad5-d203-4e47-9eef-cea78d1a0a52@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>
Message-ID: <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@github.com>

On Mon, 7 Feb 2022 14:31:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
> 
> I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
> 
Thanks for digging out the JBS issue for this.

> > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
> 
> I would actually like the following behavior:
> 
>     * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
> 
>     * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
> 
> 
> I think this is close to what we do now.
> 
> So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
> 
>     * a single 1G page and 256 2m pages for the heap
> 

Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated. 

>     * 128 2m pages for the code cache
>       ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
> 
> 
> Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?

This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.

If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes). 

Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?

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

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


From lkorinth at openjdk.java.net  Mon Feb  7 16:00:32 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 7 Feb 2022 16:00:32 GMT
Subject: RFR: 8281379: Assign package declarations to all jtreg test cases
 under gc
Message-ID: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>

Assign package declarations to all jtreg test cases under directory "gc". At the moment a few test cases are using no explicit package which makes it hard editing the testcase in an IDE. 

hotspot_gc passed.

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

Commit messages:
 - 8281379: Assign package declarations to all jtreg test cases under gc

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

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


From kbarrett at openjdk.java.net  Tue Feb  8 08:05:13 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 08:05:13 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v3]
In-Reply-To: <9pGv3gbIZWAYMSac0Zb9fFrAv5KhNbNGKQ_LBjB6RDE=.6d99ecaa-aa10-4c58-800e-b264ba48e788@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
 <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>
 <9pGv3gbIZWAYMSac0Zb9fFrAv5KhNbNGKQ_LBjB6RDE=.6d99ecaa-aa10-4c58-800e-b264ba48e788@github.com>
Message-ID: <xTaavzIaOsyIOSqUcnNKtQC62V_4A0-kvwUqRffHAqQ=.e84a2808-c78a-4e19-8438-d84334f9259c@github.com>

On Mon, 7 Feb 2022 10:40:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix primary thread notification safepoint check
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 64:
> 
>> 62:   // Returns true if should deactivate.
>> 63:   // precondition: this is the current thread.
>> 64:   virtual bool maybe_deactivate() = 0;
> 
> I know the name is pre-existing, but I've always found the naming it a bit odd. Or we usually call thing like this `should_deactivate()`. If you prefer keeping the old name I'm fine with it, just wanted to mention it since we are changing the code.

I'm not especially fond that name, but a `should_` prefix would incorrectly suggest it's "just" a predicate, but it has side effects.  I have some further changes coming that might do things a bit differently.  I'll keep the naming in mind.

> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp line 94:
> 
>> 92:   Semaphore _notifier;
>> 93:   DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, 0);
>> 94:   volatile size_t _threshold;
> 
> Might make sense to add some additional comment for the threshold, similar to the description you have in the PR summary: 
> 
> The primary thread uses an atomic activation threshold that also serves as "is
> running" state. This activation threshold is used by the write barrier
> support to determine whether the thread's semaphore needs to be signaled.

I meant to do that, and then forgot.  Thanks for point it out.  I'll add it before pushing.

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

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


From kbarrett at openjdk.java.net  Tue Feb  8 08:58:55 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 08:58:55 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v4]
In-Reply-To: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
Message-ID: <n6rippowzYe9yAqARXJlU5Ga7NfR7xqT-WlBAwH9kjU=.add38198-deb9-4d68-9d2d-a0288b31687e@github.com>

> Please review this change to to G1ConcurrentRefineThreads to simplify the
> activation mechanism.
> 
> We split the class into two subclasses, one for the "primary" refinement
> thread and another class for the remaining refinement threads.
> 
> The secondary threads are changed to use Monitor-based waits and notifications
> with a supporting request flag.
> 
> The primary thread uses an atomic activation threshold that also serves as "is
> running" state.  This activation threshold is used by the write barrier
> support to determine whether the thread's semaphore needs to be signaled.
> That threshold is now in the primary refinement thread rather than in the
> dirty card queue set to simplify threshold management and somewhat reduce
> coupling.
> 
> Testing:
> mach5 tier1-3
> 
> Manual tests with refinement thread logging enabled to verify expected
> activations occur.

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

 - add some description comments
 - Merge branch 'master' into split-crt
 - fix primary thread notification safepoint check
 - update copyrights
 - refactor refinement threads

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7282/files
  - new: https://git.openjdk.java.net/jdk/pull/7282/files/070e92a7..5192502c

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

  Stats: 3727 lines in 146 files changed: 2263 ins; 875 del; 589 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7282/head:pull/7282

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


From kbarrett at openjdk.java.net  Tue Feb  8 09:06:53 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 09:06:53 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v5]
In-Reply-To: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
Message-ID: <bx451GZS9VeYWCVj1ab2CFjTV0QetrdJAO7Bx1Rt25g=.8b37a8df-5a2c-45d5-9825-4729c3c70a47@github.com>

> Please review this change to to G1ConcurrentRefineThreads to simplify the
> activation mechanism.
> 
> We split the class into two subclasses, one for the "primary" refinement
> thread and another class for the remaining refinement threads.
> 
> The secondary threads are changed to use Monitor-based waits and notifications
> with a supporting request flag.
> 
> The primary thread uses an atomic activation threshold that also serves as "is
> running" state.  This activation threshold is used by the write barrier
> support to determine whether the thread's semaphore needs to be signaled.
> That threshold is now in the primary refinement thread rather than in the
> dirty card queue set to simplify threshold management and somewhat reduce
> coupling.
> 
> Testing:
> mach5 tier1-3
> 
> Manual tests with refinement thread logging enabled to verify expected
> activations occur.

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

 - Merge branch 'master' into split-crt
 - add some description comments
 - Merge branch 'master' into split-crt
 - fix primary thread notification safepoint check
 - update copyrights
 - refactor refinement threads

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7282/files
  - new: https://git.openjdk.java.net/jdk/pull/7282/files/5192502c..4051881e

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

  Stats: 4903 lines in 200 files changed: 3634 ins; 733 del; 536 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7282/head:pull/7282

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


From kbarrett at openjdk.java.net  Tue Feb  8 09:06:55 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 09:06:55 GMT
Subject: RFR: 8280917: Simplify G1ConcurrentRefineThread activation [v3]
In-Reply-To: <3ceDnEdEe2SlqTGgK4tPBzHGteRkDK6qlEpZnM10dMw=.5f6f36f7-b88a-41de-a3b7-9acb852fc6fe@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
 <taxBKuwRGRSOXUAsJFRpRj3gAEg9L3S-pATrRAOysd0=.0c4fa919-ac32-4483-9aa2-6e351ec53cd3@github.com>
 <3ceDnEdEe2SlqTGgK4tPBzHGteRkDK6qlEpZnM10dMw=.5f6f36f7-b88a-41de-a3b7-9acb852fc6fe@github.com>
Message-ID: <zwCZTl-wWo04yHqNditVV0_EzLXz1vdwHkWmqyJ9dTs=.3236f32a-35b0-4b0d-8365-720a24683c74@github.com>

On Thu, 3 Feb 2022 09:41:49 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix primary thread notification safepoint check
>
> Lgtm!

Thanks @walulyai and @kstefanj for reviews.

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

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


From kbarrett at openjdk.java.net  Tue Feb  8 09:06:56 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 09:06:56 GMT
Subject: Integrated: 8280917: Simplify G1ConcurrentRefineThread activation
In-Reply-To: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
References: <UOLytlwv7TwfFJBuP9phB6sHXVIqfMFUZjzGXqKFx18=.77390ebc-493f-4a2c-910b-62460858ffa7@github.com>
Message-ID: <FF2v0hywl-cgKQ5ic8CuIxKoN4T8ThI6itAdK9Q5goE=.fcf62952-3ca3-4f7a-a5f8-85ae943809d2@github.com>

On Mon, 31 Jan 2022 00:08:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to to G1ConcurrentRefineThreads to simplify the
> activation mechanism.
> 
> We split the class into two subclasses, one for the "primary" refinement
> thread and another class for the remaining refinement threads.
> 
> The secondary threads are changed to use Monitor-based waits and notifications
> with a supporting request flag.
> 
> The primary thread uses an atomic activation threshold that also serves as "is
> running" state.  This activation threshold is used by the write barrier
> support to determine whether the thread's semaphore needs to be signaled.
> That threshold is now in the primary refinement thread rather than in the
> dirty card queue set to simplify threshold management and somewhat reduce
> coupling.
> 
> Testing:
> mach5 tier1-3
> 
> Manual tests with refinement thread logging enabled to verify expected
> activations occur.

This pull request has now been integrated.

Changeset: 861f2797
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/861f2797f7d56ab185117f27dae2660af9250f6a
Stats:     396 lines in 7 files changed: 244 ins; 96 del; 56 mod

8280917: Simplify G1ConcurrentRefineThread activation

Reviewed-by: iwalulya, sjohanss

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

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


From kbarrett at openjdk.java.net  Tue Feb  8 13:07:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 8 Feb 2022 13:07:10 GMT
Subject: RFR: 8281379: Assign package declarations to all jtreg test cases
 under gc
In-Reply-To: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
References: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
Message-ID: <k8fHE9SjXk0W4pRyQi6QItATu5EYxdXZUF2X04_8wv8=.66b19db8-f94c-4029-b68c-4415aec9b9bf@github.com>

On Mon, 7 Feb 2022 15:52:35 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Assign package declarations to all jtreg test cases under directory "gc". At the moment a few test cases are using no explicit package which makes it hard editing the testcase in an IDE. 
> 
> hotspot_gc passed.

Looks good.  Just a minor formatting suggestion.

test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java line 36:

> 34:  * @build sun.hotspot.WhiteBox
> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox
> 36:  * @run main/othervm -XX:+UseG1GC -Xbootclasspath/a:. -XX:+UseNUMA -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI gc.g1.numa.TestG1NUMATouchRegions

Since you are touching this overlong line anyway (and making it even longer), could you add a line break or two in there?

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Feb  8 13:14:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 8 Feb 2022 13:14:05 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list [v2]
In-Reply-To: <0ysr7jD8VttN371ZU5aMlolFGelM43faeIh3ht9O_6k=.1fd6daa0-d5aa-4967-9468-7a8b560a3697@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
 <0ysr7jD8VttN371ZU5aMlolFGelM43faeIh3ht9O_6k=.1fd6daa0-d5aa-4967-9468-7a8b560a3697@github.com>
Message-ID: <4qOrtdKdGUA1SJMual-Hd7Dv6Ycej432h9D2R2WtND8=.c5587c46-fcd9-4999-93fc-668a5525b9a0@github.com>

On Mon, 31 Jan 2022 17:17:52 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to BufferNode::Allocator::release to avoid needing
>> to walk the pending list in preparation for transferring it to the free list.
>> We need to have both the head and the tail of the pending list to perform that
>> transfer.
>> 
>> Rather than using a LockFreeStack to accumulate the pending list, we now use a
>> bespoke data structure that only supports concurrent additions, since that's
>> all we need.  This simplifies the code, and also makes it easy to capture the
>> first pushed node as the tail.
>> 
>> To make the transfer from the pending list to the free list, we double-buffer
>> the pending list.  Additions are made to the currently active pending list.  A
>> transfer flips which pending list is active, and transfers from the list that
>> was just deactivated.  Additions are made in a critical section.  The critical
>> section synchronization already performed when transferring now does double
>> duty, also synchronizing the pending list flip.
>> 
>> Testing:
>> mach5 tier1-3
>> 
>> Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
>> occurring as expected.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyrights
>  - change _pending_lists init for compiler bug workaround

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Feb  8 13:19:06 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 8 Feb 2022 13:19:06 GMT
Subject: RFR: 8281379: Assign package declarations to all jtreg test cases
 under gc
In-Reply-To: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
References: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
Message-ID: <7-N-sS7qxe6c_Dl5onD8XY5c9qEc94ZjrLo9V5ORtmY=.f03d804d-4ba9-4f75-94d7-272db5662d1e@github.com>

On Mon, 7 Feb 2022 15:52:35 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Assign package declarations to all jtreg test cases under directory "gc". At the moment a few test cases are using no explicit package which makes it hard editing the testcase in an IDE. 
> 
> hotspot_gc passed.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From duke at openjdk.java.net  Tue Feb  8 20:09:11 2022
From: duke at openjdk.java.net (duke)
Date: Tue, 8 Feb 2022 20:09:11 GMT
Subject: Withdrawn: 8277394: Remove the use of safepoint_workers in reference
 processor
In-Reply-To: <ViGZSkP7H_kIpOtNXZXMdP2O0Wcfh1ghCdWfc4e-R6g=.425fe95b-458d-4c34-8233-b5482717a633@github.com>
References: <ViGZSkP7H_kIpOtNXZXMdP2O0Wcfh1ghCdWfc4e-R6g=.425fe95b-458d-4c34-8233-b5482717a633@github.com>
Message-ID: <R1-d9tlP9AJ1_tH6ByOfZrCq_RTvlgs1N2yXlhJhz7A=.987c78e4-7999-4bca-938d-0e1d67c71e90@github.com>

On Thu, 18 Nov 2021 12:31:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of passing workers to the reference processor constructor.
> 
> Test: hotspot_gc

This pull request has been closed without being integrated.

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

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


From kbarrett at openjdk.java.net  Wed Feb  9 04:42:58 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 04:42:58 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list [v3]
In-Reply-To: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
Message-ID: <CwuzEagh8i7HprOqPpyo-bV-bTjHOaVhDXI3N_ymJKo=.dff569d1-db39-4747-a80c-75362a88e79e@github.com>

> Please review this change to BufferNode::Allocator::release to avoid needing
> to walk the pending list in preparation for transferring it to the free list.
> We need to have both the head and the tail of the pending list to perform that
> transfer.
> 
> Rather than using a LockFreeStack to accumulate the pending list, we now use a
> bespoke data structure that only supports concurrent additions, since that's
> all we need.  This simplifies the code, and also makes it easy to capture the
> first pushed node as the tail.
> 
> To make the transfer from the pending list to the free list, we double-buffer
> the pending list.  Additions are made to the currently active pending list.  A
> transfer flips which pending list is active, and transfers from the list that
> was just deactivated.  Additions are made in a critical section.  The critical
> section synchronization already performed when transferring now does double
> duty, also synchronizing the pending list flip.
> 
> Testing:
> mach5 tier1-3
> 
> Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
> occurring as expected.

Kim Barrett has updated the pull request 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 four additional commits since the last revision:

 - Merge branch 'master' into buffer_release
 - update copyrights
 - change _pending_lists init for compiler bug workaround
 - double-buffer pending list

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7210/files
  - new: https://git.openjdk.java.net/jdk/pull/7210/files/70c52abb..b08a9cf6

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

  Stats: 15843 lines in 685 files changed: 10584 ins; 2771 del; 2488 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7210.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7210/head:pull/7210

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


From kbarrett at openjdk.java.net  Wed Feb  9 04:42:58 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 04:42:58 GMT
Subject: RFR: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list [v3]
In-Reply-To: <cQUOeZURJuttXOVb5LASaQBipvGA4OO_Cy70kGrMRDU=.38d320f1-57d6-4cc2-9ffb-6e721c6d3edd@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
 <cQUOeZURJuttXOVb5LASaQBipvGA4OO_Cy70kGrMRDU=.38d320f1-57d6-4cc2-9ffb-6e721c6d3edd@github.com>
Message-ID: <zn87ML03gO2REOlwqfmWXs6BxEPSFum6Cr0kPS03lUo=.ea70bed6-222b-475c-ad91-dac958327d75@github.com>

On Tue, 25 Jan 2022 10:11:21 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into buffer_release
>>  - update copyrights
>>  - change _pending_lists init for compiler bug workaround
>>  - double-buffer pending list
>
> Nice clean-up!

Thanks @walulyai and @tschatzl for reviews.

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

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


From kbarrett at openjdk.java.net  Wed Feb  9 04:42:58 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 9 Feb 2022 04:42:58 GMT
Subject: Integrated: 8280438: Improve BufferNode::Allocator::release to avoid
 walking pending list
In-Reply-To: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
References: <6M_39LGoKVVbG3_ilxcUFixoFGzHIoZZdBWLWoVWry4=.3765da16-43f4-457b-9f1d-0548cbe68b48@github.com>
Message-ID: <Ndf9yjd-sca8gR-pMwyL84LrUDVNYuxhSZmxWv79gaA=.0d44afbc-214d-44e7-b527-d4219fb0ef0f@github.com>

On Tue, 25 Jan 2022 05:04:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to BufferNode::Allocator::release to avoid needing
> to walk the pending list in preparation for transferring it to the free list.
> We need to have both the head and the tail of the pending list to perform that
> transfer.
> 
> Rather than using a LockFreeStack to accumulate the pending list, we now use a
> bespoke data structure that only supports concurrent additions, since that's
> all we need.  This simplifies the code, and also makes it easy to capture the
> first pushed node as the tail.
> 
> To make the transfer from the pending list to the free list, we double-buffer
> the pending list.  Additions are made to the currently active pending list.  A
> transfer flips which pending list is active, and transfers from the list that
> was just deactivated.  Additions are made in a critical section.  The critical
> section synchronization already performed when transferring now does double
> duty, also synchronizing the pending list flip.
> 
> Testing:
> mach5 tier1-3
> 
> Ran a test with -Xlog:gc,ptrqueue,freelist and verified transfers were
> occurring as expected.

This pull request has now been integrated.

Changeset: bce5dd17
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bce5dd17665d1cdf2901690ca54f84ec200560af
Stats:     96 lines in 2 files changed: 55 ins; 7 del; 34 mod

8280438: Improve BufferNode::Allocator::release to avoid walking pending list

Reviewed-by: iwalulya, tschatzl

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

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


From iwalulya at openjdk.java.net  Wed Feb  9 15:40:16 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 9 Feb 2022 15:40:16 GMT
Subject: RFR: 8280783: Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
References: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
Message-ID: <fRknZPJYX2WYoQauRuuCJBnMH9GlZQGXby_Yz5J0Als=.58865e97-1dd8-4204-ae07-c7e7617c5271@github.com>

On Thu, 27 Jan 2022 08:49:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> A new version of `PSCardTable::scavenge_contents_parallel` with cleaner structure and most of the existing behavior. The deviation is so large that the diff is not very sensible; reading the new code directly is probably easier.
> 
> This PR doesn't take advantage of precise card marking, just like the existing code. IOW, the code assumes all cards are *imprecisely* marked. Optimizations like utilizing precise card marking will be investigated/attempted in another ticket/PR.
> 
> Test: Tier1-6

Lgtm!

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

Marked as reviewed by iwalulya (Reviewer).

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


From lkorinth at openjdk.java.net  Wed Feb  9 18:11:39 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Wed, 9 Feb 2022 18:11:39 GMT
Subject: RFR: 8281379: Assign package declarations to all jtreg test cases
 under gc [v2]
In-Reply-To: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
References: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
Message-ID: <d3Q23PYLSJm88tAJM4l6bpb8aPG_HANwvCgBpXKQOOU=.f03bc2d8-cfe2-4b5a-89f1-6971b7a81547@github.com>

> Assign package declarations to all jtreg test cases under directory "gc". At the moment a few test cases are using no explicit package which makes it hard editing the testcase in an IDE. 
> 
> hotspot_gc passed.

Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:

  breaking long @run line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7370/files
  - new: https://git.openjdk.java.net/jdk/pull/7370/files/63d5bbb7..36e552ff

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

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

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


From lkorinth at openjdk.java.net  Wed Feb  9 18:45:11 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Wed, 9 Feb 2022 18:45:11 GMT
Subject: RFR: 8281379: Assign package declarations to all jtreg test cases
 under gc [v2]
In-Reply-To: <k8fHE9SjXk0W4pRyQi6QItATu5EYxdXZUF2X04_8wv8=.66b19db8-f94c-4029-b68c-4415aec9b9bf@github.com>
References: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
 <k8fHE9SjXk0W4pRyQi6QItATu5EYxdXZUF2X04_8wv8=.66b19db8-f94c-4029-b68c-4415aec9b9bf@github.com>
Message-ID: <A3GID3QeC69wv4QX7FvMyVUBem5_J3fXMBL4P58_Bzo=.241da13f-2ad4-4101-a95c-69dddc37c401@github.com>

On Tue, 8 Feb 2022 13:03:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   breaking long @run line
>
> test/hotspot/jtreg/gc/g1/numa/TestG1NUMATouchRegions.java line 36:
> 
>> 34:  * @build sun.hotspot.WhiteBox
>> 35:  * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox
>> 36:  * @run main/othervm -XX:+UseG1GC -Xbootclasspath/a:. -XX:+UseNUMA -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI gc.g1.numa.TestG1NUMATouchRegions
> 
> Since you are touching this overlong line anyway (and making it even longer), could you add a line break or two in there?

fixed!

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

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


From mli at openjdk.java.net  Thu Feb 10 06:04:07 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 10 Feb 2022 06:04:07 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
Message-ID: <Njgs9FGNLRJOIrTrLyb2rZHMUv8xv8kL_EnEjV8fFOg=.f730f9ce-d8fe-4c9d-b4b4-3d5add6aac4b@github.com>

On Tue, 18 Jan 2022 04:31:47 GMT, Hamlin Li <mli at openjdk.org> wrote:

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

Currently, Configuration is only used to get the number of object types.
Do you suggest to use a const template parameter (e.g. template<MEMFLAGS flag, int NUM> class G1SegmentedArrayFreeMemoryTask) to replace the Configuration parameter? I don't object, but seems a Configuration parameter make it more clear to differentiate between 2 G1SegmentedArrayFreeMemoryTask even if they has the same number of object types.
Please kindly let me know you suggestion.

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

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


From iwalulya at openjdk.java.net  Thu Feb 10 08:18:04 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 10 Feb 2022 08:18:04 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <Njgs9FGNLRJOIrTrLyb2rZHMUv8xv8kL_EnEjV8fFOg=.f730f9ce-d8fe-4c9d-b4b4-3d5add6aac4b@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
 <Njgs9FGNLRJOIrTrLyb2rZHMUv8xv8kL_EnEjV8fFOg=.f730f9ce-d8fe-4c9d-b4b4-3d5add6aac4b@github.com>
Message-ID: <qenWQ_AfHeBSJRvViXC-nnrxLDtwLdjC64E51kuFkdg=.95e1c130-6403-43a4-bef9-57a4ebf2c084@github.com>

On Thu, 10 Feb 2022 06:01:04 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, Configuration is only used to get the number of object types. Do you suggest to use a const template parameter (e.g. template<MEMFLAGS flag, int NUM> class G1SegmentedArrayFreeMemoryTask) to replace the Configuration parameter? I don't object, but seems a Configuration parameter make it more clear to differentiate between 2 G1SegmentedArrayFreeMemoryTask even if they has the same number of object types. Please kindly let me know you suggestion.

Just seemed like overkill to use a template parameter, const template parameter does not solve that. If there is not work around that doesn't involve a new template parameter, then the Configuration is better because we might use it for more in the future. I was just wondering if we can pass the number of object types in constructor rather than template parameter.

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

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


From duke at openjdk.java.net  Thu Feb 10 08:50:20 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 10 Feb 2022 08:50:20 GMT
Subject: RFR: 8281553: Ensure we only require liveness from mach-nodes with
 barriers
Message-ID: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>

Adding NULL check. This also ensures we are not returning a NULL reference.

Ran tests to ensure assert is never triggered.

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

Commit messages:
 - 8281553: Ensure we only require liveness from mach-nodes with barriers

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

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


From duke at openjdk.java.net  Thu Feb 10 09:01:43 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 10 Feb 2022 09:01:43 GMT
Subject: RFR: 8281553: Ensure we only require liveness from mach-nodes with
 barriers [v2]
In-Reply-To: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
References: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
Message-ID: <g7tl0QexuolWG89E6V2YjiU-sSM1PmIoXyFy5ErSuec=.79df7594-1fbf-46a7-9f63-e08b8182d5d2@github.com>

> Adding NULL check. This also ensures we are not returning a NULL reference.
> 
> Ran tests to ensure assert is never triggered.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  fixing whitespaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7407/files
  - new: https://git.openjdk.java.net/jdk/pull/7407/files/1c889678..b005c5b0

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

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

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


From mli at openjdk.java.net  Thu Feb 10 09:27:03 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 10 Feb 2022 09:27:03 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <qenWQ_AfHeBSJRvViXC-nnrxLDtwLdjC64E51kuFkdg=.95e1c130-6403-43a4-bef9-57a4ebf2c084@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
 <Njgs9FGNLRJOIrTrLyb2rZHMUv8xv8kL_EnEjV8fFOg=.f730f9ce-d8fe-4c9d-b4b4-3d5add6aac4b@github.com>
 <qenWQ_AfHeBSJRvViXC-nnrxLDtwLdjC64E51kuFkdg=.95e1c130-6403-43a4-bef9-57a4ebf2c084@github.com>
Message-ID: <hMV8JqkvYpWzu-93Oy7p0HzSOR7I_tTeyesA7xG4DJA=.9304bcfc-1396-40c6-9c9b-837c71ccadb5@github.com>

On Thu, 10 Feb 2022 08:14:41 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> > Currently, Configuration is only used to get the number of object types. Do you suggest to use a const template parameter (e.g. template<MEMFLAGS flag, int NUM> class G1SegmentedArrayFreeMemoryTask) to replace the Configuration parameter? I don't object, but seems a Configuration parameter make it more clear to differentiate between 2 G1SegmentedArrayFreeMemoryTask even if they has the same number of object types. Please kindly let me know you suggestion.
> 
> Just seemed like overkill to use a template parameter, const template parameter does not solve that. If there is not work around that doesn't involve a new template parameter, then the Configuration is better because we might use it for more in the future. I was just wondering if we can pass the number of object types in constructor rather than template parameter.

So, do you agree to go with a Configuration as the template parameter?
( Sorry, I missed another use of Configuration which is Configuration::mem_object_type_name_str(i). )

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

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


From iwalulya at openjdk.java.net  Thu Feb 10 09:41:07 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 10 Feb 2022 09:41:07 GMT
Subject: RFR: 8280106: G1: Make reclaiming memory functionality more
 general in G1SegmentedArrayFreePool and G1SegmentedArrayFreeMemoryTask
In-Reply-To: <hMV8JqkvYpWzu-93Oy7p0HzSOR7I_tTeyesA7xG4DJA=.9304bcfc-1396-40c6-9c9b-837c71ccadb5@github.com>
References: <EBmHfYqKkvSHeB_InvMjQ6_x2Spxo4xbZK2H3nM-DkY=.68f65410-8ca7-44fd-81a9-30e2816f5583@github.com>
 <Njgs9FGNLRJOIrTrLyb2rZHMUv8xv8kL_EnEjV8fFOg=.f730f9ce-d8fe-4c9d-b4b4-3d5add6aac4b@github.com>
 <qenWQ_AfHeBSJRvViXC-nnrxLDtwLdjC64E51kuFkdg=.95e1c130-6403-43a4-bef9-57a4ebf2c084@github.com>
 <hMV8JqkvYpWzu-93Oy7p0HzSOR7I_tTeyesA7xG4DJA=.9304bcfc-1396-40c6-9c9b-837c71ccadb5@github.com>
Message-ID: <TJc4fB1ENJgOKWb9_ij63V9-fpCrDqDdWs029X2CZvk=.779d7ac9-3176-4589-b7a1-4b564aabbbb3@github.com>

On Thu, 10 Feb 2022 09:24:04 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > > Currently, Configuration is only used to get the number of object types. Do you suggest to use a const template parameter (e.g. template<MEMFLAGS flag, int NUM> class G1SegmentedArrayFreeMemoryTask) to replace the Configuration parameter? I don't object, but seems a Configuration parameter make it more clear to differentiate between 2 G1SegmentedArrayFreeMemoryTask even if they has the same number of object types. Please kindly let me know you suggestion.
> > 
> > 
> > Just seemed like overkill to use a template parameter, const template parameter does not solve that. If there is not work around that doesn't involve a new template parameter, then the Configuration is better because we might use it for more in the future. I was just wondering if we can pass the number of object types in constructor rather than template parameter.
> 
> So, do you agree to go with a Configuration as the template parameter? ( Sorry, I missed another use of Configuration which is Configuration::mem_object_type_name_str(i). )

Yes

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

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


From duke at openjdk.java.net  Thu Feb 10 10:12:14 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Thu, 10 Feb 2022 10:12:14 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <xwaUYW0ySj8MdbU74Lw0u0Lnj8XcVSEv8VCe9-otyYw=.e9a4d441-4661-4e09-a298-89dc5873ba2e@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>
Message-ID: <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@github.com>

On Mon, 7 Feb 2022 15:10:19 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
> > 
> > 
> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
> 
> Thanks for digging out the JBS issue for this.
> 
> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
> > 
> > 
> > I would actually like the following behavior:
> > ```
> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
> > 
> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I think this is close to what we do now.
> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
> > ```
> > * a single 1G page and 256 2m pages for the heap
> > ```
> 
> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
> 
> > ```
> > * 128 2m pages for the code cache
> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
> 
> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> 
> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
> 
> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?

Hi @kstefanj , @tstuefe 

Thanks for sharing your views and comments. 
Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.

Best Regards,
Swati

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

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


From neliasso at openjdk.java.net  Thu Feb 10 10:14:10 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 10 Feb 2022 10:14:10 GMT
Subject: RFR: 8281553: Ensure we only require liveness from mach-nodes with
 barriers [v2]
In-Reply-To: <g7tl0QexuolWG89E6V2YjiU-sSM1PmIoXyFy5ErSuec=.79df7594-1fbf-46a7-9f63-e08b8182d5d2@github.com>
References: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
 <g7tl0QexuolWG89E6V2YjiU-sSM1PmIoXyFy5ErSuec=.79df7594-1fbf-46a7-9f63-e08b8182d5d2@github.com>
Message-ID: <vprsPQEO8Tbf_Fc1JHSgJ-afpmIsBjytw_85QuACzbU=.8a29c1f8-6f88-44be-b4d3-bb22da4cc68f@github.com>

On Thu, 10 Feb 2022 09:01:43 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Adding NULL check. This also ensures we are not returning a NULL reference.
>> 
>> Ran tests to ensure assert is never triggered.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing whitespaces

Looks good and trivial!

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

Marked as reviewed by neliasso (Reviewer).

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


From lkorinth at openjdk.java.net  Thu Feb 10 10:38:10 2022
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Thu, 10 Feb 2022 10:38:10 GMT
Subject: Integrated: 8281379: Assign package declarations to all jtreg test
 cases under gc
In-Reply-To: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
References: <FbX1e01Eo-dsXzEICzDrbXNnk8GIhHL2oZDncdMXZ0E=.35322369-8c3f-4390-964e-39dba2771a7a@github.com>
Message-ID: <cbXKSY1sxAinsTwEdb92DYEvblOOLOvx5-_cIfYMDko=.c23819ca-9e26-4e53-9325-a0da9deb1d6b@github.com>

On Mon, 7 Feb 2022 15:52:35 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Assign package declarations to all jtreg test cases under directory "gc". At the moment a few test cases are using no explicit package which makes it hard editing the testcase in an IDE. 
> 
> hotspot_gc passed.

This pull request has now been integrated.

Changeset: c820d1ac
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c820d1acb7c6e600a890e4205eef0be8a4c7a791
Stats:     22 lines in 5 files changed: 10 ins; 0 del; 12 mod

8281379: Assign package declarations to all jtreg test cases under gc

Reviewed-by: kbarrett, tschatzl

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

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


From duke at openjdk.java.net  Thu Feb 10 22:22:41 2022
From: duke at openjdk.java.net (brianjstafford)
Date: Thu, 10 Feb 2022 22:22:41 GMT
Subject: RFR: 8274238: Inconsistent type for young_list_target_length()
Message-ID: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>

This is a cleanup PR that changes the return type for G1Policy::young_list_target_length() to uint in order to be consistent with the underlying variable and all related variables and functions.

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

Commit messages:
 - Changed return type for young_list_target_length() to uint

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

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


From kbarrett at openjdk.java.net  Fri Feb 11 05:10:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 11 Feb 2022 05:10:10 GMT
Subject: RFR: 8274238: Inconsistent type for young_list_target_length()
In-Reply-To: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
References: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
Message-ID: <DL6PMSLHrkPXRE3vIfbLaiPTc_qgsa0iLib9ummxo6M=.4f29fe59-dde4-45fd-8ac2-37546e0b42d3@github.com>

On Sat, 5 Feb 2022 00:59:36 GMT, brianjstafford <duke at openjdk.java.net> wrote:

> This is a cleanup PR that changes the return type for G1Policy::young_list_target_length() to uint in order to be consistent with the underlying variable and all related variables and functions.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Fri Feb 11 07:50:48 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 11 Feb 2022 07:50:48 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v4]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <bgVBy9cENOIfq_ZcNp-6R2i7AYSedt-hVzcD96QdgsI=.405ef02b-04e7-45b0-b705-a47233de2c34@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:

  prepare evacuation failure regions explicitly before post 1; fix remset verification crash

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/1003c77c..b4f8f265

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

  Stats: 75 lines in 7 files changed: 58 ins; 12 del; 5 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 Feb 11 08:02:11 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 11 Feb 2022 08:02:11 GMT
Subject: Withdrawn: 8276618: Pad cacheline for Thread::_rcu_counter
In-Reply-To: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
References: <6kHhrYgTQ2_ST7TG7H0Syf6_QR8OW4qTc1KGIRJMhWE=.e29aee68-ca4e-46b0-a930-fc38e5176ca9@github.com>
Message-ID: <NwpV8ADJfa0LbUBwqdYccP2SQRuV89SUUM1QyY3lmhY=.e1c33065-0031-47ca-82c6-93041d1d047e@github.com>

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

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

This pull request has been closed without being integrated.

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

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


From mli at openjdk.java.net  Fri Feb 11 08:17:40 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 11 Feb 2022 08:17:40 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v5]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <uk4SdDvQHgk5fU5hRnrPyDM-PHxfuabWm2aSdJ8Cu_o=.9007d314-9fdc-4409-870b-10d77fe07147@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:

  Sync marked words to HeapRegion; Fix compilation error on windows

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/b4f8f265..76a26feb

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

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

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


From tschatzl at openjdk.java.net  Fri Feb 11 09:50:03 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 11 Feb 2022 09:50:03 GMT
Subject: RFR: 8274238: Inconsistent type for young_list_target_length()
In-Reply-To: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
References: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
Message-ID: <3RomPxNrvhNAkYaUegriDOWJVKcyxvfV8RFIVMLEla8=.aa6c3b97-a4dc-43b8-a9ac-3bb751befac0@github.com>

On Sat, 5 Feb 2022 00:59:36 GMT, brianjstafford <duke at openjdk.java.net> wrote:

> This is a cleanup PR that changes the return type for G1Policy::young_list_target_length() to uint in order to be consistent with the underlying variable and all related variables and functions.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From duke at openjdk.java.net  Fri Feb 11 10:07:09 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 11 Feb 2022 10:07:09 GMT
Subject: RFR: 8281553: Ensure we only require liveness from mach-nodes with
 barriers [v2]
In-Reply-To: <vprsPQEO8Tbf_Fc1JHSgJ-afpmIsBjytw_85QuACzbU=.8a29c1f8-6f88-44be-b4d3-bb22da4cc68f@github.com>
References: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
 <g7tl0QexuolWG89E6V2YjiU-sSM1PmIoXyFy5ErSuec=.79df7594-1fbf-46a7-9f63-e08b8182d5d2@github.com>
 <vprsPQEO8Tbf_Fc1JHSgJ-afpmIsBjytw_85QuACzbU=.8a29c1f8-6f88-44be-b4d3-bb22da4cc68f@github.com>
Message-ID: <5GZs3lJ_md7JzWd2xdYdDv2O2oQvlQ7O_ZiFrccvekg=.1acede4a-b9ad-4f5b-90c2-c8958e6bddeb@github.com>

On Thu, 10 Feb 2022 10:10:34 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing whitespaces
>
> Looks good and trivial!

@neliasso thanks for the help and the review.

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

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


From sjohanss at openjdk.java.net  Fri Feb 11 11:31:23 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 11 Feb 2022 11:31:23 GMT
Subject: RFR: 8281637: Remove unused VerifyOption_G1UseNextMarking
Message-ID: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>

Please review this change to remove an unused verification option.

**Summary**
In G1 there have been three different `VerifyOption` that can be passed to verification to signal how to determine liveness. One of these options, `VerifyOption_G1UseNextMarking`,  has been unused for quite some time and this change removes it. When removing it the `G1CollectedHeap::is_obj_ill(...)` functions are more or less unused, so I removed those as well and inlined the checks in the only place where it is really used `G1CMIsAliveClosure::do_object_b(...)`

**Testing**

- [x] Mach5
- [x] Local verification testing

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

Commit messages:
 - 8281637: Remove unused VerifyOption_G1UseNextMarking

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

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


From tschatzl at openjdk.java.net  Fri Feb 11 12:02:11 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 11 Feb 2022 12:02:11 GMT
Subject: RFR: 8281637: Remove unused VerifyOption_G1UseNextMarking
In-Reply-To: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
References: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
Message-ID: <_pR5VG46PiAO4L6kXk5miyZob6w9ZFQZKvol9RMRrrw=.05a507a0-543b-4df4-9827-5d2b0a1cd292@github.com>

On Fri, 11 Feb 2022 11:25:56 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove an unused verification option.
> 
> **Summary**
> In G1 there have been three different `VerifyOption` that can be passed to verification to signal how to determine liveness. One of these options, `VerifyOption_G1UseNextMarking`,  has been unused for quite some time and this change removes it. When removing it the `G1CollectedHeap::is_obj_ill(...)` functions are more or less unused, so I removed those as well and inlined the checks in the only place where it is really used `G1CMIsAliveClosure::do_object_b(...)`
> 
> **Testing**
> 
> - [x] Mach5
> - [x] Local verification testing

Lgtm. Suggested two fixes for typos.

src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp line 46:

> 44:   HeapRegion* hr = _g1h->heap_region_containing(cast_from_oop<HeapWord*>(obj));
> 45: 
> 46:   // All objects allocated since the start of marking is considered live.

Suggestion:

  // All objects allocated since the start of marking are considered live.

src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp line 51:

> 49:   }
> 50: 
> 51:   // All object in closed archive regions are live.

Suggestion:

  // All objects in closed archive regions are live.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Fri Feb 11 12:15:12 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 11 Feb 2022 12:15:12 GMT
Subject: RFR: 8281637: Remove unused VerifyOption_G1UseNextMarking
In-Reply-To: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
References: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
Message-ID: <O3qVHEDlnKKm_SxlQCxNsn1CtebXJixbWtD4Z_qVlmg=.0b2c300b-85d5-4288-8994-79ac4f1158d8@github.com>

On Fri, 11 Feb 2022 11:25:56 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove an unused verification option.
> 
> **Summary**
> In G1 there have been three different `VerifyOption` that can be passed to verification to signal how to determine liveness. One of these options, `VerifyOption_G1UseNextMarking`,  has been unused for quite some time and this change removes it. When removing it the `G1CollectedHeap::is_obj_ill(...)` functions are more or less unused, so I removed those as well and inlined the checks in the only place where it is really used `G1CMIsAliveClosure::do_object_b(...)`
> 
> **Testing**
> 
> - [x] Mach5
> - [x] Local verification testing

Marked as reviewed by iwalulya (Reviewer).

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

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


From sjohanss at openjdk.java.net  Fri Feb 11 14:55:06 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 11 Feb 2022 14:55:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <qlxpIasaM-yswscREncCPjgfg4nfXZsI6_fbBT2CZgU=.2025efd6-5178-4d57-8b7b-d1d7e1115922@github.com>
Message-ID: <U4pT9VEgQvzLazRsds9_Jo_CMXLvRzFqz7Y3sVpqoog=.1547aa2e-ef18-48c6-b55e-b273f0d85ea1@github.com>

On Fri, 4 Feb 2022 12:50:49 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: Review comments resolved.

I would actually say this is adding new functionality. We have never had any fallback to smaller large page sizes if the configured one is not working properly. What we do have support for is to use smaller large page sizes for mappings that are smaller than the configured large page size. As we have discussed above, there is room for improvement in this area and I'm starting to think that moving towards something where `os::large_page_size()` is not even used should be the end goal. But as a first step, falling back to use smaller pages sizes is good.

To be more concrete about your patch, as I've said before, I would prefer a solution like the one I proposed above. Sure the heap might be aligned to something larger than what the final large page size require, but I don't think that's a very big issue since there will be quite few of these mappings (and again the user/administrator requested this alignment). Also, going with something like my suggestion above will cover more cases. For example, your proposed solution won't work if there is ONE 1G page available but not TWO. In this case the sanity check will pass, but your heap reservation will fail. 

I did spend some more time on my proposal to improve the logging and warnings a bit. Could probably be improved even further but you can take a look here to see the current state:
https://github.com/openjdk/jdk/compare/master...kstefanj:8271195-lp-fallback

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

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


From duke at openjdk.java.net  Fri Feb 11 16:48:11 2022
From: duke at openjdk.java.net (brianjstafford)
Date: Fri, 11 Feb 2022 16:48:11 GMT
Subject: RFR: 8274238: Inconsistent type for young_list_target_length()
In-Reply-To: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
References: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
Message-ID: <mSskyhSuyjzAu_OmI-BQyhEDcSWbc_ZdFKxpTiWx18Q=.1d9bbe26-fbd7-49ed-bad9-4daa4e548d5b@github.com>

On Sat, 5 Feb 2022 00:59:36 GMT, brianjstafford <duke at openjdk.java.net> wrote:

> This is a cleanup PR that changes the return type for G1Policy::young_list_target_length() to uint in order to be consistent with the underlying variable and all related variables and functions.

Thank you for the reviews. Much appreciated!

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

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


From mli at openjdk.java.net  Mon Feb 14 01:24:35 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 14 Feb 2022 01:24:35 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v6]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <wZzJXdqbq-b6WygO79Lps98HcFq81sgONokr1ELwl0Y=.95f7315a-e67c-4606-b78e-b09cd48d1ce8@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 with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into parallelize-evac-failure-in-bm
 - Sync marked words to HeapRegion; Fix compilation error on windows
 - prepare evacuation failure regions explicitly before post 1; fix remset verification crash
 - Remove Prepare-Region and Wait-For-Ready phases
 - Add logging code from Thomas
 - Collect livewords in chunk closure
 - clean vm options
 - sync region preparation before iterate through chunks in a region
 - use const G1CMBitMap
 - adapt to update_bot_if_crossing_boundary changes
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/eff5dafb...85bb0635

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

Changes: https://git.openjdk.java.net/jdk/pull/7047/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7047&range=05
  Stats: 625 lines in 19 files changed: 551 ins; 35 del; 39 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  Mon Feb 14 08:20:12 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 14 Feb 2022 08:20:12 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v6]
In-Reply-To: <wZzJXdqbq-b6WygO79Lps98HcFq81sgONokr1ELwl0Y=.95f7315a-e67c-4606-b78e-b09cd48d1ce8@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <wZzJXdqbq-b6WygO79Lps98HcFq81sgONokr1ELwl0Y=.95f7315a-e67c-4606-b78e-b09cd48d1ce8@github.com>
Message-ID: <SiEx7o6q8kamq1DKHWRdmmw9sTMD8wveCYAZ8XqwTtk=.f2f901ba-6a78-4b1a-83c1-5dd4d906a704@github.com>

On Mon, 14 Feb 2022 01:24:35 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 with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Merge branch 'master' into parallelize-evac-failure-in-bm
>  - Sync marked words to HeapRegion; Fix compilation error on windows
>  - prepare evacuation failure regions explicitly before post 1; fix remset verification crash
>  - Remove Prepare-Region and Wait-For-Ready phases
>  - Add logging code from Thomas
>  - Collect livewords in chunk closure
>  - clean vm options
>  - sync region preparation before iterate through chunks in a region
>  - use const G1CMBitMap
>  - adapt to update_bot_if_crossing_boundary changes
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/eff5dafb...85bb0635

Hi Thomas,

My test (with the latest implementation) shows that when evacuation failure regions number is less than parallel gc thread number, it bring stable benefit in post 1 phase; but when evacuation failure regions number is more than parallel gc thread number, the benefit is not stable, and can bring some regionssion in post 1 phase.
I think the test result is reasonable. When there are more evaucuation failure regions than parallel gc threads, parallelism at region level should already assign some regions to every gc threads, i.e. it's already fully parallized in some degree; whether parallelism at chunk level could bring more benefit depends on the distribution of evacuation failure objects in regions. Otherwise, when there are less evaucuation failure regions, parallelism at region level can not assign every gc threads a evacuation failure region to process, at this situation parallism at chunk level can bring more benefit, and the benefit is stable.

A simple heuristic is to switch to original implemenation, i.e. parallelize only at region level, when detects that evacuation failure regions number is more than parallel gc thread number. The advantage is that it avoids to consume extra CPU to do unnecessary parallelism at chunk level. The drawback of this solution is that it will bring 2 pieces of code: parallelism in regions, and parallelism in chunks.

How do you think about it?

Thanks

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

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


From sjohanss at openjdk.java.net  Mon Feb 14 09:00:48 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 14 Feb 2022 09:00:48 GMT
Subject: RFR: 8281637: Remove unused VerifyOption_G1UseNextMarking [v2]
In-Reply-To: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
References: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
Message-ID: <N5HtjdBie89xetTceQmB4kK05sb2XDwOKIDnbnjd_t8=.4cd788f0-82df-4c39-8453-352c6b46e51c@github.com>

> Please review this change to remove an unused verification option.
> 
> **Summary**
> In G1 there have been three different `VerifyOption` that can be passed to verification to signal how to determine liveness. One of these options, `VerifyOption_G1UseNextMarking`,  has been unused for quite some time and this change removes it. When removing it the `G1CollectedHeap::is_obj_ill(...)` functions are more or less unused, so I removed those as well and inlined the checks in the only place where it is really used `G1CMIsAliveClosure::do_object_b(...)`
> 
> **Testing**
> 
> - [x] Mach5
> - [x] Local verification testing

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

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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7440/files
  - new: https://git.openjdk.java.net/jdk/pull/7440/files/11e02017..d1439e42

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

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

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


From sjohanss at openjdk.java.net  Mon Feb 14 09:07:11 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 14 Feb 2022 09:07:11 GMT
Subject: RFR: 8281637: Remove unused VerifyOption_G1UseNextMarking [v2]
In-Reply-To: <_pR5VG46PiAO4L6kXk5miyZob6w9ZFQZKvol9RMRrrw=.05a507a0-543b-4df4-9827-5d2b0a1cd292@github.com>
References: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
 <_pR5VG46PiAO4L6kXk5miyZob6w9ZFQZKvol9RMRrrw=.05a507a0-543b-4df4-9827-5d2b0a1cd292@github.com>
Message-ID: <1a_oI67onxONKGpslwWoTkt5NXuakHm4Sc4oUyu1Ksk=.e90fa25a-b702-4cd7-acf5-3aeedb684251@github.com>

On Fri, 11 Feb 2022 11:58:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Stefan Johansson has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
>>    
>>    Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>>  - Update src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
>>    
>>    Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>
>
> Lgtm. Suggested two fixes for typos.

Thanks @tschatzl and @walulyai for the reviews.

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

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


From sjohanss at openjdk.java.net  Mon Feb 14 09:07:11 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 14 Feb 2022 09:07:11 GMT
Subject: Integrated: 8281637: Remove unused VerifyOption_G1UseNextMarking
In-Reply-To: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
References: <1x2KFOJkZ8_A3FNU3oV8ubKudJgfO4yDc952VHp70mg=.716893b0-52f8-47b4-afe5-94812bad052d@github.com>
Message-ID: <aEWupF1zgfjJDkN_fJhMYRJHnDi8MrEeQVvR9RKLZu8=.306df8fe-2f3d-4e99-8789-0ed40bc72c80@github.com>

On Fri, 11 Feb 2022 11:25:56 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this change to remove an unused verification option.
> 
> **Summary**
> In G1 there have been three different `VerifyOption` that can be passed to verification to signal how to determine liveness. One of these options, `VerifyOption_G1UseNextMarking`,  has been unused for quite some time and this change removes it. When removing it the `G1CollectedHeap::is_obj_ill(...)` functions are more or less unused, so I removed those as well and inlined the checks in the only place where it is really used `G1CMIsAliveClosure::do_object_b(...)`
> 
> **Testing**
> 
> - [x] Mach5
> - [x] Local verification testing

This pull request has now been integrated.

Changeset: 2632d40d
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2632d40dfc9f681e53fe04d32b6380ffb4eeb88c
Stats:     66 lines in 9 files changed: 13 ins; 48 del; 5 mod

8281637: Remove unused VerifyOption_G1UseNextMarking

Reviewed-by: tschatzl, iwalulya

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

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


From ayang at openjdk.java.net  Mon Feb 14 09:21:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 14 Feb 2022 09:21:09 GMT
Subject: RFR: 8280783: Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
References: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
Message-ID: <-ogrEG27NG_EqgX40Lg0vWO8kFDt6IUmG9vO5kFT9MA=.e79cc669-c99c-4012-833a-3d359523e5e2@github.com>

On Thu, 27 Jan 2022 08:49:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> A new version of `PSCardTable::scavenge_contents_parallel` with cleaner structure and most of the existing behavior. The deviation is so large that the diff is not very sensible; reading the new code directly is probably easier.
> 
> This PR doesn't take advantage of precise card marking, just like the existing code. IOW, the code assumes all cards are *imprecisely* marked. Optimizations like utilizing precise card marking will be investigated/attempted in another ticket/PR.
> 
> Test: Tier1-6

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Feb 14 09:21:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 14 Feb 2022 09:21:09 GMT
Subject: Integrated: 8280783: Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
References: <7GE5Fj7eoTJDj0MPy7gSfeYZMoPPqhzChh1ryjXXPnA=.4ae5bb10-f44f-400f-9df7-9fa2608fd5a8@github.com>
Message-ID: <VEUw6EKznmMbJXW8DKh_r96oRWO1xe97tcvJEl7DCBE=.2f4fd9ed-a188-42d1-8880-43092a1a22a7@github.com>

On Thu, 27 Jan 2022 08:49:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> A new version of `PSCardTable::scavenge_contents_parallel` with cleaner structure and most of the existing behavior. The deviation is so large that the diff is not very sensible; reading the new code directly is probably easier.
> 
> This PR doesn't take advantage of precise card marking, just like the existing code. IOW, the code assumes all cards are *imprecisely* marked. Optimizations like utilizing precise card marking will be investigated/attempted in another ticket/PR.
> 
> Test: Tier1-6

This pull request has now been integrated.

Changeset: 25972062
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2597206242356d42ca5d08be809cfdff79df924d
Stats:     277 lines in 2 files changed: 103 ins; 102 del; 72 mod

8280783: Parallel: Refactor PSCardTable::scavenge_contents_parallel

Reviewed-by: tschatzl, iwalulya

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

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


From chagedorn at openjdk.java.net  Mon Feb 14 09:56:12 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Feb 2022 09:56:12 GMT
Subject: RFR: 8281553: Ensure we only require liveness from mach-nodes with
 barriers [v2]
In-Reply-To: <g7tl0QexuolWG89E6V2YjiU-sSM1PmIoXyFy5ErSuec=.79df7594-1fbf-46a7-9f63-e08b8182d5d2@github.com>
References: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
 <g7tl0QexuolWG89E6V2YjiU-sSM1PmIoXyFy5ErSuec=.79df7594-1fbf-46a7-9f63-e08b8182d5d2@github.com>
Message-ID: <0ajfnuG0hA6NUtlc6OltAF4g3sSXsCXYiWjTv_G7zSE=.896dbbd9-218c-442e-84d2-6f20acb8d81e@github.com>

On Thu, 10 Feb 2022 09:01:43 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Adding NULL check. This also ensures we are not returning a NULL reference.
>> 
>> Ran tests to ensure assert is never triggered.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing whitespaces

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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


From duke at openjdk.java.net  Mon Feb 14 09:56:13 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 14 Feb 2022 09:56:13 GMT
Subject: Integrated: 8281553: Ensure we only require liveness from mach-nodes
 with barriers
In-Reply-To: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
References: <IUTc1zeSgutwLVlQZK_vtcKoruXDPAeWE3ModnS2K8Q=.3d32549f-e1b0-410d-934d-7bbecd987867@github.com>
Message-ID: <iPAV3l5cM-Hq628i-ebjCRGtwBQbMbSXzIrym3e52sE=.c08fcd35-463a-485a-8345-ca128516d0b5@github.com>

On Wed, 9 Feb 2022 17:42:09 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Adding NULL check. This also ensures we are not returning a NULL reference.
> 
> Ran tests to ensure assert is never triggered.

This pull request has now been integrated.

Changeset: c61d629a
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c61d629add65f9c25f73c335f2a3c5095da5be52
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8281553: Ensure we only require liveness from mach-nodes with barriers

Reviewed-by: neliasso, chagedorn

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

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


From mli at openjdk.java.net  Mon Feb 14 12:10:51 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 14 Feb 2022 12:10:51 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@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:

  Clean code; adapt to new bot implementation; others

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7047/files
  - new: https://git.openjdk.java.net/jdk/pull/7047/files/85bb0635..09f831b0

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

  Stats: 100 lines in 10 files changed: 27 ins; 63 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 duke at openjdk.java.net  Mon Feb 14 12:21:06 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 14 Feb 2022 12:21:06 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v4]
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: <2VBJSCFH2jOBQ0ONVfSS0g4Pe9Wz88SZUBO1D3X4xmQ=.0a59d953-9e71-4811-b013-86dd2fed4dc3@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8271195
 - 8271195: Review comments resolved.
 - 8271195: Review comments resolved.
 - 8271195: Resolving jcheck failure.
 - 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/fadcb5b9..813ce0e3

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

  Stats: 16078 lines in 454 files changed: 11917 ins; 2152 del; 2009 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  Mon Feb 14 12:25:12 2022
From: duke at openjdk.java.net (brianjstafford)
Date: Mon, 14 Feb 2022 12:25:12 GMT
Subject: Integrated: 8274238: Inconsistent type for young_list_target_length()
In-Reply-To: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
References: <tKwg_xTG7VU0-UQlv4AGwyBoI8aBlJQv3lUu2ijEKIU=.43adbf74-909a-484f-8c64-89d0ba2ef4dd@github.com>
Message-ID: <0S_yi0c01iPOvH2IpiJFtwrfwYkeRV8Klpqx8xPjud0=.03585db5-f581-4fab-8958-315dc2940622@github.com>

On Sat, 5 Feb 2022 00:59:36 GMT, brianjstafford <duke at openjdk.java.net> wrote:

> This is a cleanup PR that changes the return type for G1Policy::young_list_target_length() to uint in order to be consistent with the underlying variable and all related variables and functions.

This pull request has now been integrated.

Changeset: 9d0a4c3f
Author:    Brian J. Stafford <brianjstafford at gmail.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d0a4c3f2e347c30ff56ba1416c08cc662f7f23c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8274238: Inconsistent type for young_list_target_length()

Reviewed-by: kbarrett, tschatzl

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

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


From duke at openjdk.java.net  Mon Feb 14 14:24:55 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 14 Feb 2022 14:24:55 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v5]
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: <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@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: Resolved the review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/813ce0e3..4c1d088e

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

  Stats: 77 lines in 4 files changed: 33 ins; 19 del; 25 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 stuefe at openjdk.java.net  Mon Feb 14 14:36:10 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 14 Feb 2022 14:36:10 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v5]
In-Reply-To: <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>
Message-ID: <bNjFiD3IGbkbbkqcY7lk199jxjX0MAeW9lO5c-A83Fg=.4b667caa-f63a-497b-b46e-336db97f02e8@github.com>

On Mon, 14 Feb 2022 14:24:55 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 review comments

Sorry all for dropping out of the discussion.

> 
> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
> > 
> > 
> > I would actually like the following behavior:
> > ```
> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
> > 
> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
> > I think this is close to what we do now.
> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
> > ```
> > * a single 1G page and 256 2m pages for the heap
> > ```
> 
> Currently this would round the heap up to 2G and use 2 1G pages, right?

Right.

> But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages.

Probably the latter, with a warning. I expect in general the admin to be able to allocate enough huge pages, so error handling is rare and can be simple. Just my opinion.

> There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.

I understand this, but I am confused too: I thought large page memory is never uncommitted because we cannot be sure it can be recommitted? When does G1 uncommit large paged heap?

> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
> 
> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> 
> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).

Yes, I think getting rid of default large page makes sense. And instinctively I would say "configured" means we were, at startup, able to allocate at least one page of that size.

> 
> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?

I think the latter. If we have multiple large pages, but no concept of default, the caller needs to specify its wish size.

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

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


From stuefe at openjdk.java.net  Tue Feb 15 10:45:15 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Feb 2022 10:45:15 GMT
Subject: RFR: 8280088: NMT: Make mtGCCardSet the subcategory of mtGC
In-Reply-To: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
References: <j-MaUDYtLcNaZy9LsgwAHwT87P5VwZSIoFB_YmcacZg=.4706f865-9b10-4e9f-8832-98b8e1a548bc@github.com>
Message-ID: <7ODt2SGnHlvpbfDtVNzPStP2e0KCmhnGENsXgQnrjXo=.067bf955-497c-4d90-a1f3-96714f4ccaa3@github.com>

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

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

I created https://bugs.openjdk.java.net/browse/JDK-8281819 to track the proposed NMT category grouping

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

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


From sjohanss at openjdk.java.net  Tue Feb 15 11:51:27 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 11:51:27 GMT
Subject: RFR: 8281748: runtime/logging/RedefineClasses.java failed
 "assert(addr != __null) failed: invariant"
Message-ID: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>

Please review this fix for [JDK-8281748](https://bugs.openjdk.java.net/browse/JDK-8281748).

**Summary**
In a recent [cleanup](https://bugs.openjdk.java.net/browse/JDK-8281637) a NULL-check in `G1CMIsAliveClosure::do_object_b(oop obj)` was forgotten. This was not caught by the initial testing because the only time the check is needed is when a referent is cleared **during** reference discovery, which is quite hard to trigger. 

The fix is fairly simple, but returning `true` when a `NULL` is passed in feels a bit counter-intuitive. This behavior is the same as prior to the cleanup causing the error and reading the code this will lead to not discovering references where the referent is `NULL`. 

**Testing**

- [ ] Re-running mach5 tier1-5

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

Commit messages:
 - 8281748: runtime/logging/RedefineClasses.java failed "assert(addr != __null) failed: invariant"

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

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


From sjohanss at openjdk.java.net  Tue Feb 15 12:14:10 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 12:14:10 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v5]
In-Reply-To: <bNjFiD3IGbkbbkqcY7lk199jxjX0MAeW9lO5c-A83Fg=.4b667caa-f63a-497b-b46e-336db97f02e8@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <u4TXNk0g6fyVVbV0NqaEaX6cjmvNu2Edmcyoyq3DyG0=.1cb3ca7e-8c67-4393-aa1f-f50bae2bd112@github.com>
 <bNjFiD3IGbkbbkqcY7lk199jxjX0MAeW9lO5c-A83Fg=.4b667caa-f63a-497b-b46e-336db97f02e8@github.com>
Message-ID: <pZjeAhkN6g1ci9_3d6N_Vv51Vn8_Mxh_FpVyHKQoGPs=.97fc94df-16e2-4265-9ea9-2aaa79b5706b@github.com>

On Mon, 14 Feb 2022 14:33:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages.
> 
> Probably the latter, with a warning. I expect in general the admin to be able to allocate enough huge pages, so error handling is rare and can be simple. Just my opinion.

Yes, deciding how much to help vs how much to expect from the configuration is not crystal clear. I know we have also discussed that one can query how many pages are in the pool and do decisions from that as well, but I think that might be over the top. 


> > There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
> 
> I understand this, but I am confused too: I thought large page memory is never uncommitted because we cannot be sure it can be recommitted? When does G1 uncommit large paged heap?
> 
As you say we can't uncommit when large pages are used, but we keep track that the range of pages are dirty and need clearing if reused later. (Might be room for some concurrent clearing here)

> > This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> > If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
> 
> Yes, I think getting rid of default large page makes sense. And instinctively I would say "configured" means we were, at startup, able to allocate at least one page of that size.
> 
I think this would be a good way forward, to just allow use of page sizes which pass the sanity check. But I still think there might be a usecase for `LargePageSizeInBytes`, if you want to restrict the maximum used page size for the JVM. Say for example that your 1G-pool is for someother application.

> > Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> I think the latter. If we have multiple large pages, but no concept of default, the caller needs to specify its wish size.

So do I, I'll file some enhancements.

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

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


From ayang at openjdk.java.net  Tue Feb 15 14:10:06 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 15 Feb 2022 14:10:06 GMT
Subject: RFR: 8281748: runtime/logging/RedefineClasses.java failed
 "assert(addr != __null) failed: invariant"
In-Reply-To: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
References: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
Message-ID: <Jp0W1To6YJ6Rq5E8KMstl-kPk9JOl_zV9fDlcrxM4h0=.a379bbfe-66db-418d-99d4-5ebe6df2a521@github.com>

On Tue, 15 Feb 2022 11:45:00 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this fix for [JDK-8281748](https://bugs.openjdk.java.net/browse/JDK-8281748).
> 
> **Summary**
> In a recent [cleanup](https://bugs.openjdk.java.net/browse/JDK-8281637) a NULL-check in `G1CMIsAliveClosure::do_object_b(oop obj)` was forgotten. This was not caught by the initial testing because the only time the check is needed is when a referent is cleared **during** reference discovery, which is quite hard to trigger. 
> 
> The fix is fairly simple, but returning `true` when a `NULL` is passed in feels a bit counter-intuitive. This behavior is the same as prior to the cleanup causing the error and reading the code this will lead to not discovering references where the referent is `NULL`. 
> 
> **Testing**
> 
> - [ ] Re-running mach5 tier1-5

Approved since it fixes CI failure and it's equivalent to what we had on master. However, I believe `G1CMIsAliveClosure::do_object_b` should not accept `null` as its input. Taking `ReferenceProcessor::process_discovered_list_work` as an example, `null` referents are filtered out before asking if a referent is live. Therefore, IMO, the proper fix should be to check `null` before calling this closure.

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

Marked as reviewed by ayang (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Feb 15 14:51:06 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 14:51:06 GMT
Subject: RFR: 8281748: runtime/logging/RedefineClasses.java failed
 "assert(addr != __null) failed: invariant"
In-Reply-To: <Jp0W1To6YJ6Rq5E8KMstl-kPk9JOl_zV9fDlcrxM4h0=.a379bbfe-66db-418d-99d4-5ebe6df2a521@github.com>
References: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
 <Jp0W1To6YJ6Rq5E8KMstl-kPk9JOl_zV9fDlcrxM4h0=.a379bbfe-66db-418d-99d4-5ebe6df2a521@github.com>
Message-ID: <YoJ9roeYk7uABS1HZqN4DUBemedrO-lTAz07Dl9t030=.d2a441c4-c161-47d5-9ae3-41460619911e@github.com>

On Tue, 15 Feb 2022 14:06:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Approved since it fixes CI failure and it's equivalent to what we had on master. However, I believe `G1CMIsAliveClosure::do_object_b` should not accept `null` as its input. Taking `ReferenceProcessor::process_discovered_list_work` as an example, `null` referents are filtered out before asking if a referent is live. Therefore, IMO, the proper fix should be to check `null` before calling this closure.

Thanks for review. I agree, I've filed [JDK-8281823](https://bugs.openjdk.java.net/browse/JDK-8281823) for this. I currently don't have time to properly look into that and wanted a quick fix since I'm not sure how many failures this could generate.

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

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


From kbarrett at openjdk.java.net  Tue Feb 15 15:46:11 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 15 Feb 2022 15:46:11 GMT
Subject: RFR: 8281748: runtime/logging/RedefineClasses.java failed
 "assert(addr != __null) failed: invariant"
In-Reply-To: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
References: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
Message-ID: <ccb4Z4bX21Gdt54cqvjPpYOqVbHJnJdewrlZjkHbT4o=.d0287e79-2342-4467-968e-232bda02080f@github.com>

On Tue, 15 Feb 2022 11:45:00 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this fix for [JDK-8281748](https://bugs.openjdk.java.net/browse/JDK-8281748).
> 
> **Summary**
> In a recent [cleanup](https://bugs.openjdk.java.net/browse/JDK-8281637) a NULL-check in `G1CMIsAliveClosure::do_object_b(oop obj)` was forgotten. This was not caught by the initial testing because the only time the check is needed is when a referent is cleared **during** reference discovery, which is quite hard to trigger. 
> 
> The fix is fairly simple, but returning `true` when a `NULL` is passed in feels a bit counter-intuitive. This behavior is the same as prior to the cleanup causing the error and reading the code this will lead to not discovering references where the referent is `NULL`. 
> 
> **Testing**
> 
> - [ ] Re-running mach5 tier1-5

Looks good.

This matches what was done prior to JDK-8281637.  In the interest of reducing testing noise, consider not waiting for the usual 24h before integrating.

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

Marked as reviewed by kbarrett (Reviewer).

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


From sjohanss at openjdk.java.net  Tue Feb 15 16:20:14 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 16:20:14 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@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>
Message-ID: <1Uayyf2VJQfX2hHgivhQGdjTs0MV8iczBz-WPlOxCmU=.d59f7982-6ad5-4715-898e-0222e3581b83@github.com>

On Thu, 10 Feb 2022 10:09:24 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>>> > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>>> 
>>> I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>>> 
>> Thanks for digging out the JBS issue for this.
>> 
>>> > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>>> 
>>> I would actually like the following behavior:
>>> 
>>>     * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>>> 
>>>     * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>>> 
>>> 
>>> I think this is close to what we do now.
>>> 
>>> So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>>> 
>>>     * a single 1G page and 256 2m pages for the heap
>>> 
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated. 
>> 
>>>     * 128 2m pages for the code cache
>>>       ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>>> 
>>> 
>>> Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes). 
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
>
>> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>> > 
>> > 
>> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>> 
>> Thanks for digging out the JBS issue for this.
>> 
>> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>> > 
>> > 
>> > I would actually like the following behavior:
>> > ```
>> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>> > 
>> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > I think this is close to what we do now.
>> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>> > ```
>> > * a single 1G page and 256 2m pages for the heap
>> > ```
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
>> 
>> > ```
>> > * 128 2m pages for the code cache
>> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> Hi @kstefanj , @tstuefe 
> 
> Thanks for sharing your views and comments. 
> Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.
> 
> Best Regards,
> Swati

@swati-sha, I took a closer look at the test-case and right now it won't work when run on aarch64? On those systems in our test environment the base page size is 64k and the large page sizes are 2m and 512m. I took it for a spin to see what failures we would get and here it is:

[0.001s][info][pagesize] LargePageSizeInBytes is not a valid large page size (1G) using the default large page size: 512M
[0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
[0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
[0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
[0.002s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffec55d0000 page_size=64K size=5760K
[0.002s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffec5b70000 page_size=64K size=120000K
[0.002s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffecd0a0000 page_size=64K size=120000K
[0.002s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
[0.002s][info   ][pagesize] Card Table:  min=4194305B max=4194305B base=0x0000fffee0db0000 page_size=64K size=4160K
[0.003s][info   ][pagesize] Mark Bitmap:  min=64M max=64M base=0x0000fffebc000000 page_size=64K size=64M
[0.003s][info   ][pagesize] Parallel Compact Data:  min=160K max=160K base=0x0000fffee08b0000 page_size=64K size=192K
[0.003s][info   ][pagesize] Parallel Compact Data:  min=4M max=4M base=0x0000fffee04b0000 page_size=64K size=4M
System does not support 1G pages
Number of 2M pages = 0

System does not support 1G pages
Number of reserved 1G pages = -1

Number of reserved 2M pages = 0

TestCase1 skipped

TestCase2 skipped

Exceptionjava.lang.RuntimeException: System property 'test.jdk' not set. This property is normally set by jtreg. When running test separately, set this property using '-Dtest.jdk=/path/to/jdk'.
TestCase4 skipped

----------System.err:(11/560)----------
java.lang.AssertionError: Failed 4K page allocation

	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:81)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:828)


So either we need to make the test more robust to also work without having hard coded page sizes but rather figure them out during the "setup" stage or we need to add a requires to avoid running on aarch64. I would prefer if the test was fixed to get more coverage and testing with different page sizes. Doing the requires could look something like: 

@requires os.arch=="amd64" | os.arch=="x86_64"

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

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


From sjohanss at openjdk.java.net  Tue Feb 15 16:26:06 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 16:26:06 GMT
Subject: RFR: 8281748: runtime/logging/RedefineClasses.java failed
 "assert(addr != __null) failed: invariant"
In-Reply-To: <Jp0W1To6YJ6Rq5E8KMstl-kPk9JOl_zV9fDlcrxM4h0=.a379bbfe-66db-418d-99d4-5ebe6df2a521@github.com>
References: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
 <Jp0W1To6YJ6Rq5E8KMstl-kPk9JOl_zV9fDlcrxM4h0=.a379bbfe-66db-418d-99d4-5ebe6df2a521@github.com>
Message-ID: <Y-IMALz_mRUuZh2kI3azfmDPR0_yZl4XB4C4QKDdgls=.39c06c54-a615-4507-8b9e-180a06c1e742@github.com>

On Tue, 15 Feb 2022 14:06:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review this fix for [JDK-8281748](https://bugs.openjdk.java.net/browse/JDK-8281748).
>> 
>> **Summary**
>> In a recent [cleanup](https://bugs.openjdk.java.net/browse/JDK-8281637) a NULL-check in `G1CMIsAliveClosure::do_object_b(oop obj)` was forgotten. This was not caught by the initial testing because the only time the check is needed is when a referent is cleared **during** reference discovery, which is quite hard to trigger. 
>> 
>> The fix is fairly simple, but returning `true` when a `NULL` is passed in feels a bit counter-intuitive. This behavior is the same as prior to the cleanup causing the error and reading the code this will lead to not discovering references where the referent is `NULL`. 
>> 
>> **Testing**
>> 
>> - [ ] Re-running mach5 tier1-5
>
> Approved since it fixes CI failure and it's equivalent to what we had on master. However, I believe `G1CMIsAliveClosure::do_object_b` should not accept `null` as its input. Taking `ReferenceProcessor::process_discovered_list_work` as an example, `null` referents are filtered out before asking if a referent is live. Therefore, IMO, the proper fix should be to check `null` before calling this closure.

Thanks @albertnetymk and @kimbarrett for the reviews.

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

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


From sjohanss at openjdk.java.net  Tue Feb 15 16:26:07 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 15 Feb 2022 16:26:07 GMT
Subject: Integrated: 8281748: runtime/logging/RedefineClasses.java failed
 "assert(addr != __null) failed: invariant"
In-Reply-To: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
References: <PkirNyx-Uhx6GjrxRuSBXLYqoiXgNZrrWbBV1nkN2lQ=.fd706b58-0d00-433c-9c0c-58b3eadbc1c7@github.com>
Message-ID: <w32cY9by7TrKdPKwJIJLiN_SGTZFx8q9hys4ujUDI-8=.824d3a78-8d29-4009-aa1f-3dcc6a776e7f@github.com>

On Tue, 15 Feb 2022 11:45:00 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> Please review this fix for [JDK-8281748](https://bugs.openjdk.java.net/browse/JDK-8281748).
> 
> **Summary**
> In a recent [cleanup](https://bugs.openjdk.java.net/browse/JDK-8281637) a NULL-check in `G1CMIsAliveClosure::do_object_b(oop obj)` was forgotten. This was not caught by the initial testing because the only time the check is needed is when a referent is cleared **during** reference discovery, which is quite hard to trigger. 
> 
> The fix is fairly simple, but returning `true` when a `NULL` is passed in feels a bit counter-intuitive. This behavior is the same as prior to the cleanup causing the error and reading the code this will lead to not discovering references where the referent is `NULL`. 
> 
> **Testing**
> 
> - [ ] Re-running mach5 tier1-5

This pull request has now been integrated.

Changeset: 2fe0bf66
Author:    Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2fe0bf66b7cbbae3dc65249be4b04f4075a98efa
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8281748: runtime/logging/RedefineClasses.java failed "assert(addr != __null) failed: invariant"

Reviewed-by: ayang, kbarrett

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

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


From ayang at openjdk.java.net  Tue Feb 15 20:28:28 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 15 Feb 2022 20:28:28 GMT
Subject: RFR: 8281879: Serial: Merge CardGeneration into TenuredGeneration
Message-ID: <SsMjuUB1xM6qIalsQ8PBUmnOu6nbUWkyGyyhGc4N4DE=.36a1e219-1bc1-4517-ad45-c5ecb9a79352@github.com>

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

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

Commit messages:
 - flatten-cardgen

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

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


From jiefu at openjdk.java.net  Wed Feb 16 23:17:17 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Feb 2022 23:17:17 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is assumed to
 be unique after JDK-8281732
Message-ID: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>

Hi all,

The following tests fail after JDK-8281732.

compiler/gcbarriers/UnsafeIntrinsicsTest.java
gc/metaspace/TestMetaspacePerfCounters.java
gc/shenandoah/TestEvilSyncBug.java
gc/stringdedup/TestStringDeduplicationFullGC.java
gc/stringdedup/TestStringDeduplicationTableResize.java
gc/stringdedup/TestStringDeduplicationYoungGC.java
serviceability/dcmd/gc/HeapDumpCompressedTest.java
jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
jdk/jfr/event/oldobject/TestShenandoah.java
sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
sun/tools/jmap/BasicJMapTest.java
``` 

The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.

Testing:
 - All failing tests passed after this patch

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732

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

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


From kvn at openjdk.java.net  Wed Feb 16 23:26:04 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 16 Feb 2022 23:26:04 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <Mo41yYEMxSLQvLlgNaKQ24v8qKaZdOIVBB-DxNpqkwI=.74364577-e684-4936-adf2-5dd7242d5383@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Good.

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

Marked as reviewed by kvn (Reviewer).

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


From thartmann at openjdk.java.net  Thu Feb 17 07:35:13 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 17 Feb 2022 07:35:13 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <b-lB7PP0iFWpWhmIdglFuT3XbB0QVSCXxZohcgWdTJw=.743071de-8886-41cf-b299-1e3052552d0d@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

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


From chagedorn at openjdk.java.net  Thu Feb 17 07:51:12 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 17 Feb 2022 07:51:12 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <0wCWILIHTgSlt6XRlmnB17FA8kikE_CT8lkRe-YaFOQ=.0c69c785-588e-466f-84d4-5024a24f13d5@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Looks good!

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

Marked as reviewed by chagedorn (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Feb 17 08:59:06 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 17 Feb 2022 08:59:06 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
Message-ID: <eesv-Zj9jgSB85BhFS9aH_I-ZCzYr9hnKV4Hua3dnUo=.bb48193b-c585-422b-ba49-9b06baf28a4d@github.com>

On Mon, 14 Feb 2022 12:10: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:
> 
>   Clean code; adapt to new bot implementation; others

Let me have a look; sorry for the spotty attention recently to this fairly large and complex change. That might last for a bit due to other tasks I need to put my attention on.

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

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


From mli at openjdk.java.net  Thu Feb 17 09:17:05 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 17 Feb 2022 09:17:05 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <eesv-Zj9jgSB85BhFS9aH_I-ZCzYr9hnKV4Hua3dnUo=.bb48193b-c585-422b-ba49-9b06baf28a4d@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
 <eesv-Zj9jgSB85BhFS9aH_I-ZCzYr9hnKV4Hua3dnUo=.bb48193b-c585-422b-ba49-9b06baf28a4d@github.com>
Message-ID: <Bnaw2pkmRDta4c74uKhi12r7ecu2VR5EDPvCGOJmxRU=.498e32c7-d3b9-4468-a287-329bfec0abbf@github.com>

On Thu, 17 Feb 2022 08:56:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Let me have a look; sorry for the spotty attention recently to this fairly large and complex change. That might last for a bit due to other tasks I need to put my attention on.

Sure, please take your time. Thanks for updating.

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

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


From duke at openjdk.java.net  Thu Feb 17 15:52:52 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Thu, 17 Feb 2022 15:52:52 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
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: <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@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/4c1d088e..1db31903

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

  Stats: 175 lines in 1 file changed: 43 ins; 67 del; 65 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  Thu Feb 17 15:52:53 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Thu, 17 Feb 2022 15:52:53 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <uSF72WPap2h5Uz9kpRWJEnBa6grUtlj7kCvDg4H1oBo=.7ff3dba6-cb0f-4051-a9f4-89b2211108f8@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>
Message-ID: <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@github.com>

On Thu, 10 Feb 2022 10:09:24 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>>> > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>>> 
>>> I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>>> 
>> Thanks for digging out the JBS issue for this.
>> 
>>> > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>>> 
>>> I would actually like the following behavior:
>>> 
>>>     * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>>> 
>>>     * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>>> 
>>> 
>>> I think this is close to what we do now.
>>> 
>>> So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>>> 
>>>     * a single 1G page and 256 2m pages for the heap
>>> 
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated. 
>> 
>>>     * 128 2m pages for the code cache
>>>       ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>>> 
>>> 
>>> Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes). 
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
>
>> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>> > 
>> > 
>> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>> 
>> Thanks for digging out the JBS issue for this.
>> 
>> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>> > 
>> > 
>> > I would actually like the following behavior:
>> > ```
>> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>> > 
>> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > I think this is close to what we do now.
>> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>> > ```
>> > * a single 1G page and 256 2m pages for the heap
>> > ```
>> 
>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
>> 
>> > ```
>> > * 128 2m pages for the code cache
>> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>> > ```
>> > 
>> > 
>> >     
>> >       
>> >     
>> > 
>> >       
>> >     
>> > 
>> >     
>> >   
>> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>> 
>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>> 
>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
>> 
>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> Hi @kstefanj , @tstuefe 
> 
> Thanks for sharing your views and comments. 
> Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.
> 
> Best Regards,
> Swati

> @swati-sha, I took a closer look at the test-case and right now it won't work when run on aarch64? On those systems in our test environment the base page size is 64k and the large page sizes are 2m and 512m. I took it for a spin to see what failures we would get and here it is:
> 
> ```
> [0.001s][info][pagesize] LargePageSizeInBytes is not a valid large page size (1G) using the default large page size: 512M
> [0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
> [0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
> [0.002s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffec55d0000 page_size=64K size=5760K
> [0.002s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffec5b70000 page_size=64K size=120000K
> [0.002s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffecd0a0000 page_size=64K size=120000K
> [0.002s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
> [0.002s][info   ][pagesize] Card Table:  min=4194305B max=4194305B base=0x0000fffee0db0000 page_size=64K size=4160K
> [0.003s][info   ][pagesize] Mark Bitmap:  min=64M max=64M base=0x0000fffebc000000 page_size=64K size=64M
> [0.003s][info   ][pagesize] Parallel Compact Data:  min=160K max=160K base=0x0000fffee08b0000 page_size=64K size=192K
> [0.003s][info   ][pagesize] Parallel Compact Data:  min=4M max=4M base=0x0000fffee04b0000 page_size=64K size=4M
> System does not support 1G pages
> Number of 2M pages = 0
> 
> System does not support 1G pages
> Number of reserved 1G pages = -1
> 
> Number of reserved 2M pages = 0
> 
> TestCase1 skipped
> 
> TestCase2 skipped
> 
> Exceptionjava.lang.RuntimeException: System property 'test.jdk' not set. This property is normally set by jtreg. When running test separately, set this property using '-Dtest.jdk=/path/to/jdk'.
> TestCase4 skipped
> 
> ----------System.err:(11/560)----------
> java.lang.AssertionError: Failed 4K page allocation
> 
> 	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:81)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
> 	at java.base/java.lang.Thread.run(Thread.java:828)
> ```
> 
> So either we need to make the test more robust to also work without having hard coded page sizes but rather figure them out during the "setup" stage or we need to add a requires to avoid running on aarch64. I would prefer if the test was fixed to get more coverage and testing with different page sizes. Doing the requires could look something like:
> 
> ```
> @requires os.arch=="amd64" | os.arch=="x86_64"
> ```

Hi @kstefanj,

Added the generalized version of testcase. Please review and let me know.

Thanks,
Swati

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

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


From tschatzl at openjdk.java.net  Thu Feb 17 16:11:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 17 Feb 2022 16:11:05 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
Message-ID: <8OKi8-o3NWT7YqAvg2dMOe_Khn-YTLlIm40d_rHeoSI=.9fd3929d-5987-459e-8be0-00a06ae6fe1b@github.com>

On Mon, 14 Feb 2022 12:10: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:
> 
>   Clean code; adapt to new bot implementation; others

Hi,

> My test (with the latest implementation) shows that when evacuation failure regions number is less than parallel gc thread number, it bring stable benefit in post 1 phase; but when evacuation failure regions number is more than parallel gc thread number, the benefit is not stable, and can bring some regionssion in post 1 phase. I think the test result is reasonable. When there are more evaucuation failure regions than parallel gc threads, parallelism at region level should already assign some regions to every gc threads, i.e. it's already fully parallized in some degree; whether parallelism at chunk level could bring more benefit depends on the distribution of evacuation failure objects in regions. Otherwise, when there are less evaucuation failure regions, parallelism at region level can not assign every gc threads a evacuation failure region to process, at this situation parallism at chunk level can bring more benefit, and the benefit is stable.
> 
> A simple heuristic is to switch to original implemenation, i.e. parallelize only at region level, when detects that evacuation failure regions number is more than parallel gc thread number. The advantage is that it avoids to consume extra CPU to do unnecessary parallelism at chunk level. The drawback of this solution is that it will bring 2 pieces of code: parallelism in regions, and parallelism in chunks.
> 
> How do you think about it?

I agree it is unnecessary to slice up the work into too many work units. One option is to determine the number of chunks per region depending on the number of failed regions and the number of threads. E.g. so that the target number of chunks in total is some (small) multiple of the number of threads.

Something like `ChunksPerRegion = next_log_2(#threads-actually-launched * 10 / #regions-retained)` maybe?

That `10` is just some random value (I also hope I got the formula right) but I think you get the idea.

Note that this is a bit of a circular calculation, as the #threads is sort-of determined by the number of regions... :D Maybe set the number of threads started at most (`worker_cost()`) at most to some small multiple of the number of regions retained (which is already done, but I'd probably bump that a bit, but idk).

Thomas

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

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


From tschatzl at openjdk.java.net  Thu Feb 17 16:39:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 17 Feb 2022 16:39:05 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
Message-ID: <tdWSTy4qvZPFNpx72k5-JxdQX2O4BfPiC1ZOQJLfWfw=.f1a01ea6-4372-4452-ae43-6cba2f8b1825@github.com>

On Mon, 14 Feb 2022 12:10: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:
> 
>   Clean code; adapt to new bot implementation; others

Doesn't look too bad. :).

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

> 201:   uint max_regions = _evac_failure_regions->max_regions();
> 202:   size_t* marked_words_in_regions = NEW_C_HEAP_ARRAY(size_t, max_regions, mtGC);
> 203:   memset(marked_words_in_regions, 0, sizeof(size_t) * max_regions);

Given that the chunks are handed out region after region, or at least a given thread after switching the region for a given chunk never (or at most very rarely) gets a chunk of the same region again, it would be much more memory conscious to just cache this value for the current region, and flush only if it changes.
Similar to the flushing of the marking statistics.

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

> 215:       region->note_self_forwarding_removal_end_par(marked_words_in_regions[idx] * BytesPerWord);
> 216:     }
> 217:   }

At least put this code into a helper method if not implementing above suggestion.

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

> 218:   phase_times->record_or_add_time_secs(G1GCPhaseTimes::SyncMarkedWordInRetainedRegions, worker_id, (Ticks::now() - start).seconds());
> 219: 
> 220:   FREE_C_HEAP_ARRAY(size_t, marked_words_in_regions);

Indentation, but may be superfluous.

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

> 505:     debug_phase(_gc_par_phases[RecalculateUsed], 1);
> 506:     debug_phase(_gc_par_phases[RestorePreservedMarks], 1);
> 507:     debug_phase(_gc_par_phases[VerifyAfterSelfForwardingPtrRemoval], 1);

That should probably only be printed when the respective verification is enabled, i.e. when this task is actually run.

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

> 72: 
> 73: bool G1ScanChunksInHeapRegionClosure::do_heap_region(HeapRegion* r) {
> 74:   G1GCPhaseTimes* phase_times = G1CollectedHeap::heap()->phase_times();

Maybe rename `phase_times` to `p` to make the calls shorter. Other code does that too.

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

> 81:   while (true) {
> 82:     if (claimer->claim_chunk(chunk_idx)) {
> 83:       Ticks start2 = Ticks::now();

Please rename this to something better than `start2` - yes, I was lazy... Maybe `Ticks chunk_prepare_start = Ticks::now()`.
Unfortunately since the code does that much in the constructor, and we use `chunk` later, we can't just put it into a new scope (to reuse `start`).

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

> 60:   }
> 61: 
> 62:   HeapWord* first_obj_in_chunk() const {

I would prefer if these trivial getters would be trimmed down by doing the `return` in the same line. E.g.

`HeapRegion* heap_region() const { return _region; }`

src/hotspot/share/gc/g1/g1HeapRegionChunk.inline.hpp line 49:

> 47:   }
> 48: 
> 49:   // assert(next_addr == _limit, "Should stop the scan at the limit.");

Remove.

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

> 112:   double worker_cost() const override {
> 113:     assert(_evac_failure_regions->evacuation_failed(), "Should not call this if not executed");
> 114:     return _evac_failure_regions->num_regions_failed_evacuation() * G1YoungGCEvacFailureInjector::evacuation_failure_worker_cost();

This should not depend on anything in the evacuation failure injector. That seems to be the wrong type of dependency. Why not just use the global here?

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp line 71:

> 69: #endif
> 70: 
> 71:   class VerifyAfterSelfForwardingPtrRemovalTask;

The list above in the comments needs to be updated.

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

> 81:           "injection will be applied.")                                     \
> 82:           range(1, 100)                                                     \
> 83:   product(uint, G1EvacuationFailureALotWorkerCost, 2,                       \

This has nothing to do with the `EvacuationFailureALot` functionality, but is primarily a weight for the forward pointer removal. This ought to be renamed and moved to the regular flag section.

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

> 87:   product(uint, G1EvacuationFailureHeapRegionChunkNum, 256,                 \
> 88:           "Chunks num per G1 region when process evacuation failure "       \
> 89:           "regions in parallel.")                                           \

Number of chunks per G1 region when processing evacuation failed regions in parallel.

I also believe this should be moved to the regular section for the same reasons as the other flag. Also, if we determine the number of chunks dynamically as suggested in the answer to your question about that, this flag is not required.

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

Changes requested by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Feb 17 16:55:04 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 17 Feb 2022 16:55:04 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: <uvDJpu5rwK4LHJ8m-cK9JSZUgEREWpvt4MLKcwvNZmQ=.68c1a947-9c17-4ef3-a3b6-3fe5505c4a05@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

Looks good. That comment about `git diff --color-moved=zebra` really helped.

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

Marked as reviewed by tschatzl (Reviewer).

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


From jiefu at openjdk.java.net  Thu Feb 17 22:55:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 22:55:06 GMT
Subject: RFR: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <c1yE7XU9inJfcYqG5Wny5QR7py5KdQ32IIxufH0Se-I=.f6b52576-3dac-4661-9703-504ee5a6152d@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

Thank you all for the review.

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

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


From jiefu at openjdk.java.net  Thu Feb 17 23:00:02 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Feb 2022 23:00:02 GMT
Subject: Integrated: 8282025: assert(ctrl != __null) failed: control out is
 assumed to be unique after JDK-8281732
In-Reply-To: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
References: <qcvkqj4AMgQ5Uepmwpz7mNfHwRoeG4RgJ5SLomD_ay8=.c9defaea-c300-413d-9455-63663a088522@github.com>
Message-ID: <OJIk7dxbKtf_LXPdqkciNhgNE7H6JrARxofxi1a1pdw=.eed26895-3d1b-4cea-bda9-373090947673@github.com>

On Wed, 16 Feb 2022 23:08:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> The following tests fail after JDK-8281732.
> 
> compiler/gcbarriers/UnsafeIntrinsicsTest.java
> gc/metaspace/TestMetaspacePerfCounters.java
> gc/shenandoah/TestEvilSyncBug.java
> gc/stringdedup/TestStringDeduplicationFullGC.java
> gc/stringdedup/TestStringDeduplicationTableResize.java
> gc/stringdedup/TestStringDeduplicationYoungGC.java
> serviceability/dcmd/gc/HeapDumpCompressedTest.java
> jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionStateChangeEvent.java
> jdk/jfr/event/gc/detailed/TestShenandoahHeapRegionInformationEvent.java
> jdk/jfr/event/oldobject/TestShenandoah.java
> sun/net/www/protocol/https/HttpsURLConnection/B6216082.java
> sun/tools/jmap/BasicJMapTest.java
> ``` 
> 
> The fix just replaces `unique_ctrl_out()` with `unique_ctrl_out_or_null()`.
> 
> Testing:
>  - All failing tests passed after this patch
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: fdce35f3
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fdce35f3a1c12a64238d0c76c02451a25b0b4abb
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8282025: assert(ctrl != __null) failed: control out is assumed to be unique after JDK-8281732

Reviewed-by: kvn, thartmann, chagedorn

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

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


From ayang at openjdk.java.net  Fri Feb 18 09:58:16 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 18 Feb 2022 09:58:16 GMT
Subject: Integrated: 8282089: [BACKOUT] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
Message-ID: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>

Revert a commit to reduce tier1 noise while investigation.

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

Commit messages:
 - Revert "8280783: Parallel: Refactor PSCardTable::scavenge_contents_parallel"

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

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


From tschatzl at openjdk.java.net  Fri Feb 18 09:58:17 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Feb 2022 09:58:17 GMT
Subject: Integrated: 8282089: [BACKOUT] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>
References: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>
Message-ID: <aBIyEgEeM1ZrTkusbRyuKBcPPc611GZoV-wwVfqZkP8=.db8752a3-c8bb-49d4-8986-9b7e535b90e2@github.com>

On Fri, 18 Feb 2022 09:46:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Revert a commit to reduce tier1 noise while investigation.

Lgtm. Please go ahead and push.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Fri Feb 18 09:58:18 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 18 Feb 2022 09:58:18 GMT
Subject: Integrated: 8282089: [BACKOUT] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>
References: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>
Message-ID: <x-NnnZLKhV6lWSBfYR7y7O9E_VtgaJv44KEsUx6yMU4=.0734bad7-8971-4aa6-bbeb-e96f28fbc42d@github.com>

On Fri, 18 Feb 2022 09:46:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Revert a commit to reduce tier1 noise while investigation.

Thanks for the review.

Pushing right away since it's a clean revert and resolve tier1 failures.

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

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


From ayang at openjdk.java.net  Fri Feb 18 09:58:19 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 18 Feb 2022 09:58:19 GMT
Subject: Integrated: 8282089: [BACKOUT] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
In-Reply-To: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>
References: <WlxABLFUuZ3LFeFgR_lG86t_-AkAyQOlCRsk0CKOjpE=.944583a3-e192-4b30-9402-f17e1ebbf5c1@github.com>
Message-ID: <9FaML35Hp6iyQ7jV5XTiFqYBBIFd6Rku7gEHHDVBVVI=.8ce5a660-a7c1-4c48-8ee0-d956b2db5d22@github.com>

On Fri, 18 Feb 2022 09:46:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Revert a commit to reduce tier1 noise while investigation.

This pull request has now been integrated.

Changeset: e8224f7d
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e8224f7de9e4649105cfb0dd9e6a588505be4211
Stats:     277 lines in 2 files changed: 102 ins; 103 del; 72 mod

8282089: [BACKOUT] Parallel: Refactor PSCardTable::scavenge_contents_parallel

Reviewed-by: tschatzl

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

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


From sjohanss at openjdk.java.net  Fri Feb 18 11:43:54 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Fri, 18 Feb 2022 11:43:54 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
Message-ID: <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>

On Thu, 17 Feb 2022 15:52:52 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: Review comments resolved

Thanks for updating the test. Here is a first set of comments. 

I also just realized that even though the test doesn't show as a failure on aarch64 now it is still not working correctly and I think my suggestion to not use arrays to store the page sizes would help. What I see is that we parse the 16G page size and get an AIOOBE: 

Number of available 16777216kB pages = 0
Exceptionjava.lang.ArrayIndexOutOfBoundsException: Index 32 out of bounds for length 32

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

> 52: class MyClass {
> 53:     public static void main(String args[]) {
> 54:     System.out.println("Inside MyClass");

Indent correctly or just remove. I would also prefer if the class had a name that make it belong more to the test. Something like: `ExplicitPageAllocation`. Another alternative would be to even skip this class and just run the test with `-version`.

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

> 69:     private static String errorMessage = null;
> 70: 
> 71:     private static final int SIZE=32;

Maybe a more descriptive name, like `MAX_NUMBER_OF_PAGESIZES` or something like that.

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

> 153:                     System.out.println("System does not support"+pageSize+"kB pages");
> 154:                     continue;
> 155:                 }

I find these calculations and logic a bit confusing. Some comments would help. I think what you are doing here is to verify that no-one else on the system is using the large pages which is good, but the output "System does not support" feels wrong if the case actually is that all huge pages are used. 

>From what I can tell, in the case when no pages are configured, both free and resv will be 0, thus available will be 0 and the page size will be considered "available", but with a 0 page count.

A simpler approach would just be to check `nr_hugepages` or `free_hugepages` and use their value as available. If it is 0 it is zero we could output something like: 
"No pages configured for page size X"

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

> 162:         // OS vm page size
> 163:         ProcessBuilder processBuilder = new ProcessBuilder();
> 164:         processBuilder.command("getconf", "PAGE_SIZE");

You could use the WhiteBox API to get the default page size to avoid having to start the extra process. You can search the code for `getVMPageSize()` to see other uses.

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

> 186: 
> 187:         for (int i = index;i >= vmPageSizeIndex;i--) {
> 188:             if(pageSizes[i]) {

An alternative to this would be to have something like `ArrayList<PageSizeConfig>` to which we only add the configured page sizes. And `PageSizeConfig` would hold both the page size and the number of pages configured for this size. I think that would be slightly easier to follow.

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

Changes requested by sjohanss (Reviewer).

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


From mli at openjdk.java.net  Fri Feb 18 12:00:29 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Feb 2022 12:00:29 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v8]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@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/09f831b0..75df9398

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

  Stats: 112 lines in 11 files changed: 32 ins; 56 del; 24 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 Feb 18 12:08:51 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 18 Feb 2022 12:08:51 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <8OKi8-o3NWT7YqAvg2dMOe_Khn-YTLlIm40d_rHeoSI=.9fd3929d-5987-459e-8be0-00a06ae6fe1b@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
 <8OKi8-o3NWT7YqAvg2dMOe_Khn-YTLlIm40d_rHeoSI=.9fd3929d-5987-459e-8be0-00a06ae6fe1b@github.com>
Message-ID: <Tx8MOPzL1-4Tz7JikE4UaIQgfICo7jOTvg_dvAh-S-8=.3e1205a6-dc24-4a78-a977-ecebc3a99d6a@github.com>

On Thu, 17 Feb 2022 16:08:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I agree it is unnecessary to slice up the work into too many work units. One option is to determine the number of chunks per region depending on the number of failed regions and the number of threads. E.g. so that the target number of chunks in total is some (small) multiple of the number of threads.
> 
> Something like `ChunksPerRegion = next_log_2(#threads-actually-launched * 10 / #regions-retained)` maybe?
> 
> That `10` is just some random value (I also hope I got the formula right) but I think you get the idea.
> 
> Note that this is a bit of a circular calculation, as the #threads is sort-of determined by the number of regions... :D Maybe set the number of threads started at most (`worker_cost()`) at most to some small multiple of the number of regions retained (which is already done, but I'd probably bump that a bit, but idk).

Thanks Thomas for the detailed review. :)
I've updated the patch with most of your comments, except how to calculate the chunk num. I think the way you suggested is great, I will do some test, and push it in another commit, or maybe in another PR? I can do it in either way. In either way, I think G1EvacuationFailureHeapRegionChunkNum will be removed before push this PR, it's here just for development convenience.

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

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


From ayang at openjdk.java.net  Fri Feb 18 13:03:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 18 Feb 2022 13:03:09 GMT
Subject: RFR: 8282096: G1: Remove redundant checks in
 G1CardSet::free_mem_object
Message-ID: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>

Simple change of removing unnecessary checks.

Test: hotspot_gc

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

Commit messages:
 - g1-cardset

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

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


From tschatzl at openjdk.java.net  Fri Feb 18 15:04:54 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Feb 2022 15:04:54 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <Tx8MOPzL1-4Tz7JikE4UaIQgfICo7jOTvg_dvAh-S-8=.3e1205a6-dc24-4a78-a977-ecebc3a99d6a@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
 <8OKi8-o3NWT7YqAvg2dMOe_Khn-YTLlIm40d_rHeoSI=.9fd3929d-5987-459e-8be0-00a06ae6fe1b@github.com>
 <Tx8MOPzL1-4Tz7JikE4UaIQgfICo7jOTvg_dvAh-S-8=.3e1205a6-dc24-4a78-a977-ecebc3a99d6a@github.com>
Message-ID: <0mpBaUje6TXl5tIicc1R6t9eofBTUe-AbNLtnP2SiM4=.7ad11132-638f-47be-be11-fdb5a5a6bf9e@github.com>

On Fri, 18 Feb 2022 12:06:08 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > I agree it is unnecessary to slice up the work into too many work units. One option is to determine the number of chunks per region depending on the number of failed regions and the number of threads. E.g. so that the target number of chunks in total is some (small) multiple of the number of threads.
> > Something like `ChunksPerRegion = next_log_2(#threads-actually-launched * 10 / #regions-retained)` maybe?
> > That `10` is just some random value (I also hope I got the formula right) but I think you get the idea.
> > Note that this is a bit of a circular calculation, as the #threads is sort-of determined by the number of regions... :D Maybe set the number of threads started at most (`worker_cost()`) at most to some small multiple of the number of regions retained (which is already done, but I'd probably bump that a bit, but idk).
> 
> Thanks Thomas for the detailed review. :) I've updated the patch with most of your comments, except how to calculate the chunk num. I think the way you suggested is great, I will do some test, and push it in another commit, or maybe in another PR? I can do it in either way. In either way, I think G1EvacuationFailureHeapRegionChunkNum will be removed before push this PR, it's here just for development convenience.

I would prefer including this chunk sizing heuristic in this PR.

Thanks,
  Thomas

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

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


From tschatzl at openjdk.java.net  Fri Feb 18 15:56:52 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Feb 2022 15:56:52 GMT
Subject: RFR: 8282096: G1: Remove redundant checks in
 G1CardSet::free_mem_object
In-Reply-To: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
References: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
Message-ID: <1-Vi_G_-rpqm29ZuJL38kJWKVOeuJEx2gU-PWyeBRYs=.b41968f2-9ec3-4b73-94de-b95d483d8f01@github.com>

On Fri, 18 Feb 2022 12:56:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unnecessary checks.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Feb 18 16:25:54 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 18 Feb 2022 16:25:54 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v8]
In-Reply-To: <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@github.com>
Message-ID: <FKj3vHdqaR0Grq05t5B5_s7Lc01hEqH7CLefyzAixyE=.05cc73bf-3876-4fd9-8134-6a9ba7aeb8b1@github.com>

On Fri, 18 Feb 2022 12:00:29 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:
> 
>   Thomas review

Changes requested by tschatzl (Reviewer).

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

> 178:       _region_idx = current_region_idx;
> 179:       _marked_words = rspc.marked_words();
> 180:     }

It would be nice to move all that into a private method or a small inner class so that the code here is more readable.

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

> 193:     _g1h(G1CollectedHeap::heap()),
> 194:     _worker_id(worker_id),
> 195:     _region_idx(),

region_idx should be initialized to `_g1h->max_regions()` here, at least I can't find an initialization.

src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.hpp line 60:

> 58: // - Reset Hot Card Cache (s)
> 59: // - Update Derived Pointers (s)
> 60: // - Verify Retained Regions

should add an `(on evacuation failure)` comment, and probably moved close to the comment on "Restore Preserved Marks"

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

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


From iwalulya at openjdk.java.net  Fri Feb 18 17:02:47 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 18 Feb 2022 17:02:47 GMT
Subject: RFR: 8282096: G1: Remove redundant checks in
 G1CardSet::free_mem_object
In-Reply-To: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
References: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
Message-ID: <Zm3j2Vd28kQsNgyoaeZh38u0L6IsWNVr1HvNI7eEv7k=.b74670e6-f442-419a-ba3a-0324981a8e05@github.com>

On Fri, 18 Feb 2022 12:56:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unnecessary checks.
> 
> Test: hotspot_gc

Marked as reviewed by iwalulya (Reviewer).

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

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


From ayang at openjdk.java.net  Fri Feb 18 22:05:53 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 18 Feb 2022 22:05:53 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v8]
In-Reply-To: <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@github.com>
Message-ID: <l02A5mNjWsjHYTaIzdQAlEhIqX8ndsInv1VSLcoLDXA=.2346d113-9f3a-4fd0-9844-5e4e8c3ebd98@github.com>

On Fri, 18 Feb 2022 12:00:29 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:
> 
>   Thomas review

`_evac_failure_regions->par_iterate_chunks_in_regions(&chunk_closure, worker_id);` is essentially:


for (r : evac_fail_regions) {
  for (chunk : r->chunks) {
    if (chunk.try_claim()) {
      chunk_closure(chunk);
    }
  }
}


However, I don't see a compelling reason for a two-level iteration, first on all regions and second on chunks inside one region.

I wonder if sth like the following works. IMO, it expresses the intent more clearly and gets rid of the def/use of closures.


auto start_chunk_id = worker_id * total_chunks / n_workers;

for (auto i = 0; i < total_chunks; ++i) {
  auto chunk_id = (start_chunk_id + i) % total_chunks;
  G1HeapRegionChunk chunk(chunk_id, ...); // I think the constructor does too much currently
  if (!chunk.try_claim())
    continue;
  // claimed
  process_chunk(chunk);
}


(This gist is just to show the structure; probably contains bugs.)

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

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


From ayang at openjdk.java.net  Mon Feb 21 08:18:55 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Feb 2022 08:18:55 GMT
Subject: RFR: 8282096: G1: Remove redundant checks in
 G1CardSet::free_mem_object
In-Reply-To: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
References: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
Message-ID: <OoxQaAD59p6FcYCb9f_t1d4jO27uaZHubr2_2dpBp9g=.48a272f3-f54a-4f65-bc1d-103254dbdcdc@github.com>

On Fri, 18 Feb 2022 12:56:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unnecessary checks.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Feb 21 08:18:55 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Feb 2022 08:18:55 GMT
Subject: Integrated: 8282096: G1: Remove redundant checks in
 G1CardSet::free_mem_object
In-Reply-To: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
References: <wled8duADV3svs5XOSLLXcm5HkX0m6A2byRRn3ozBzI=.df48709c-7c78-46a0-853e-97e2c86969de@github.com>
Message-ID: <yCEZ2K4-v_FkqyTK7g5G6TDP38spyHjvAbYfZH5o_FI=.24a84fbf-53b0-4a33-b17c-fd1f141d6d48@github.com>

On Fri, 18 Feb 2022 12:56:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing unnecessary checks.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8282096: G1: Remove redundant checks in G1CardSet::free_mem_object

Reviewed-by: tschatzl, iwalulya

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

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


From duke at openjdk.java.net  Mon Feb 21 11:30:38 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 21 Feb 2022 11:30:38 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v7]
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: <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@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 are resolved

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/1db31903..069cca92

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

  Stats: 55 lines in 1 file changed: 13 ins; 28 del; 14 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  Mon Feb 21 11:36:54 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 21 Feb 2022 11:36:54 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
 <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>
Message-ID: <6_KP0bELJ48XX83QbiNF4uFY7wVvM9voRXGyyFnu3CY=.44d78fe3-843b-4ab7-bce0-3bc7ffd7c374@github.com>

On Fri, 18 Feb 2022 11:28:06 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Swati Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271195: Review comments resolved
>
> test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 188:
> 
>> 186: 
>> 187:         for (int i = index;i >= vmPageSizeIndex;i--) {
>> 188:             if(pageSizes[i]) {
> 
> An alternative to this would be to have something like `ArrayList<PageSizeConfig>` to which we only add the configured page sizes. And `PageSizeConfig` would hold both the page size and the number of pages configured for this size. I think that would be slightly easier to follow.

Page Count array size increased to 64 this will fix the reported issue and should be sufficient to handle all the page sizes for 64 bit platforms.

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

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


From sjohanss at openjdk.java.net  Mon Feb 21 12:11:02 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 12:11:02 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v7]
In-Reply-To: <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
Message-ID: <2hNQeAECiO0A6N4jCPBpVgPtK2cMXkK-THnYz2ArEkU=.f89c3cb9-5e0f-41ba-be4a-f360c7130355@github.com>

On Mon, 21 Feb 2022 11:30:38 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: Review comments are resolved

I'm currently running the latest test through our testing to make sure everything is fine.

Sorry for the many suggestions, I didn't expect it to be so many. Please take another look through the code as well, I might have missed some additional places where spaces should be added to use the same format as the rest of the file and other tests.

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

> 59: 
> 60:     private static final String DIR_HUGE_PAGES = "/sys/kernel/mm/hugepages/";
> 61:     private static final int HEAP_SIZE_IN_KB = 1 * 1024 *1024;

Suggestion:

    private static final int HEAP_SIZE_IN_KB = 1 * 1024 * 1024;

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

> 69:     private static String errorMessage = null;
> 70: 
> 71:     private static final int MAX_NUMBER_OF_PAGESIZE=64;

Suggestion:

    private static final int MAX_NUMBER_OF_PAGESIZE = 64;

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

> 78:         try {
> 79:             doSetup();
> 80:             for (int i = MAX_NUMBER_OF_PAGESIZE-1;i > vmPageSizeIndex;i--) {

Suggestion:

            for (int i = MAX_NUMBER_OF_PAGESIZE - 1; i > vmPageSizeIndex; i--) {

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

> 85:             }
> 86:         } catch(Exception e) {
> 87:            System.out.println("Exception"+e);

Suggestion:

           System.out.println("Exception" + e);

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

> 107:         else
> 108:            return Integer.toString(sizeInBytes/g)+"G";
> 109:     }

Suggestion:

    private static int requiredPageCount(int index) {
        int pageSizeInKB = 1 << (index - 10);
        return HEAP_SIZE_IN_KB / pageSizeInKB;
    }

    private static String sizeFromIndex(int index) {
        int k = 1024;
        int m = 1024 * 1024;
        int g = 1024 * 1024 * 1024;
        int sizeInBytes = 1 << index;
        if (sizeInBytes < m)
           return Integer.toString(sizeInBytes / k) + "K";
        if(sizeInBytes < g)
           return Integer.toString(sizeInBytes / m) + "M";
        else
           return Integer.toString(sizeInBytes / g) + "G";
    }

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

> 148:                 System.out.println("No Pages configured for "+pageSize+"kB");
> 149:             }
> 150:             int index = Integer.numberOfTrailingZeros(Integer.parseInt(pageSize)*1024);

Suggestion:

            int availablePages = checkAndReadFile(DIR_HUGE_PAGES + pageSizeFileName + "/free_hugepages", pageSize);
            if (availablePages == 0) {
                System.out.println("No Pages configured for " + pageSize + "kB");
            }
            int index = Integer.numberOfTrailingZeros(Integer.parseInt(pageSize) * 1024);

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

> 169:         OutputAnalyzer output = new OutputAnalyzer(pb.start());
> 170:         output.shouldHaveExitValue(0);
> 171:         for (int i = index;i >= vmPageSizeIndex;i--) {

Suggestion:

        for (int i = index; i >= vmPageSizeIndex; i--) {

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

> 177:                        continue;
> 178:                     }
> 179:                     errorMessage += "TestCase Failed for "+size+" page allocation\n";

Suggestion:

                    errorMessage += "TestCase Failed for " + size + " page allocation\n";

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

> 179:                     errorMessage += "TestCase Failed for "+size+" page allocation\n";
> 180:                 } else {
> 181:                     System.out.println("TestCase Passed for pagesize: "+pageSize+", allocated pagesize:"+size);

Suggestion:

                    System.out.println("TestCase Passed for pagesize: " + pageSize + ", allocated pagesize:" + size);

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

> 186:         }
> 187: 
> 188:         if (errorMessage!=null) {

Suggestion:

        if (errorMessage != null) {

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

Changes requested by sjohanss (Reviewer).

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


From sjohanss at openjdk.java.net  Mon Feb 21 12:11:03 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 12:11:03 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v6]
In-Reply-To: <6_KP0bELJ48XX83QbiNF4uFY7wVvM9voRXGyyFnu3CY=.44d78fe3-843b-4ab7-bce0-3bc7ffd7c374@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <s0Wxu_HblIPv3800CrnsdFmNF2Y2wwDd9muv7WeEDL4=.32d47fa1-519c-40eb-8afe-6032e478f1de@github.com>
 <_mEgJViDAowqFXelPzq0JkfA6CSbq_r2gHo1brRzWgo=.e6527f3c-21f8-4bd6-84f2-f7ec553ec62b@github.com>
 <6_KP0bELJ48XX83QbiNF4uFY7wVvM9voRXGyyFnu3CY=.44d78fe3-843b-4ab7-bce0-3bc7ffd7c374@github.com>
Message-ID: <6IhfJFLWDkTtm0tqDEj68Cj2Fjx6DbsXZcf-ekWmr6E=.94b9270c-a41a-4087-b628-71d192d473e7@github.com>

On Mon, 21 Feb 2022 11:33:24 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>> test/hotspot/jtreg/runtime/os/TestExplicitPageAllocation.java line 188:
>> 
>>> 186: 
>>> 187:         for (int i = index;i >= vmPageSizeIndex;i--) {
>>> 188:             if(pageSizes[i]) {
>> 
>> An alternative to this would be to have something like `ArrayList<PageSizeConfig>` to which we only add the configured page sizes. And `PageSizeConfig` would hold both the page size and the number of pages configured for this size. I think that would be slightly easier to follow.
>
> Page Count array size increased to 64 this will fix the reported issue and should be sufficient to handle all the page sizes for 64 bit platforms.

Yes, I saw the fix and it will work. I still think a solution like the one I proposed would be both more robust and easier to maintain, but I you prefer this approach I won't block it.

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

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


From sjohanss at openjdk.java.net  Mon Feb 21 12:34:53 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 12:34:53 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v7]
In-Reply-To: <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <LCOfszaWNi51y1A5m6XJABNk5DbZecKODvAIeV6S4Io=.425d064c-6e82-45a9-a16a-f5ce4f188765@github.com>
Message-ID: <tiKQscnhO69F3cJviY2kEpWThzQic0AjU1Q30B7lxFA=.14a52e9e-c639-4331-b20e-ef21cec8fef0@github.com>

On Mon, 21 Feb 2022 11:30:38 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: Review comments are resolved

Missing `;` made test compilation fail, so re-starting test again.

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

> 128:     public static int checkAndReadFile(String filename, String pageSize) throws Exception {
> 129:         fis = new FileInputStream(filename);
> 130:         dis = new DataInputStream(fis)

Suggestion:

        dis = new DataInputStream(fis);

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

Changes requested by sjohanss (Reviewer).

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


From duke at openjdk.java.net  Mon Feb 21 13:11:39 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 21 Feb 2022 13:11:39 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v8]
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: <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@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/069cca92..f0e9d901

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

  Stats: 29 lines in 3 files changed: 0 ins; 3 del; 26 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 sjohanss at openjdk.java.net  Mon Feb 21 14:09:53 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 14:09:53 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v8]
In-Reply-To: <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
Message-ID: <VJRbTlymlQ1OqvN1d0J2HFO1MprnbWxZotdfOKWPpZA=.ce554e61-a9c0-492a-8351-5f1862364a30@github.com>

On Mon, 21 Feb 2022 13:11:39 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: Review comments resolved.

Test is still failing on aarch64. I really encourage you to consider doing a simpler approach like the one I've suggested instead of storing the page sizes as index in an array. I find the current version hard to debug and I don't really see any benefit of the array compared to a list that can be sorted to get decreasing order.

Below is the output from the failure, I've removed a lot. Looks strange to run the test with `LargePageSizeInBytes=0K`, so I expect an unexpected value has been added to the array: 

No Pages configured for 16777216kB
No Pages configured for 2048kB
No Pages configured for 524288kB
Command line: [ ... -Xlog:pagesize -XX:LargePageSizeInBytes=0K -XX:+UseParallelGC -XX:+UseLargePages -Xmx2g -Xms1g -version ]
...
Checking allocation for 64K
[0.001s][info][pagesize] Using the default large page size: 512M
[0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
[0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
[0.002s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
[0.003s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffea55d0000 page_size=64K size=5760K
[0.012s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffea5b70000 page_size=64K size=120000K
[0.022s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffead0a0000 page_size=64K size=120000K
[0.032s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
TestCase Passed for pagesize: 0K, allocated pagesize:64K
----------System.err:(14/802)----------
java.lang.AssertionError: nullTestCase Failed for 0K page allocation

	at runtime.os.TestExplicitPageAllocation.testCase(TestExplicitPageAllocation.java:189)
	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:82)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)

JavaTest Message: Test threw exception: java.lang.AssertionError: nullTestCase Failed for 0K page allocation

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.AssertionError: nullTestCase Failed for 0K page allocation

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

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


From sjohanss at openjdk.java.net  Mon Feb 21 15:07:55 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Mon, 21 Feb 2022 15:07:55 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v8]
In-Reply-To: <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <5j-latlNR-M1FT3LxrSl7En856ryi_ssYhFUbVhz6r0=.e798f791-343e-471b-8e4a-bd20a4ce245b@github.com>
Message-ID: <krBYp8l33TbyH5FTjTV47BvNUvD6V2vn_4wd2zMCWLQ=.dac47dbb-d04b-4bf0-8b77-e8641a31ce87@github.com>

On Mon, 21 Feb 2022 13:11:39 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: Review comments resolved.

Spent some more time on the test-failure and the below overflows are the reasons. 

I think this really shows that we should go with a simpler approach and avoiding the unnecessary bit-fiddling.

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

> 99:         int m = 1024 * 1024;
> 100:         int g = 1024 * 1024 * 1024;
> 101:         int sizeInBytes = 1 << index;

The reason for the failing test is that this shift overflow when the page size is 16G. Because of the other overflow the passed in index here was also incorrect (32), but still to large to work properly.

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

> 147:                 System.out.println("No Pages configured for " + pageSize + "kB");
> 148:             }
> 149:             int index = Integer.numberOfTrailingZeros(Integer.parseInt(pageSize) * 1024);

The calculation inside the call to `numberOfTrailingZeros()` will overflow when the page-size is 16G (above 1G).

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

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


From tschatzl at openjdk.java.net  Mon Feb 21 16:04:09 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Feb 2022 16:04:09 GMT
Subject: RFR: 8280958: G1/Parallel: Unify marking code structure
Message-ID: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>

Hi all,

  can I have reviews for this change that makes G1 and Parallel Full GC marking code structure a bit more similar both terms of structure as well as naming?

This allows easier comparison and unless we are going to really merge them easier to do changes. They are still a bit different for several reasons:
  * G1 Full GC can disable class unloading while Parallel Full GC always unloads classes
  * different code structure in calls: Parallel GC drains the task queues after every kind of root, G1 only does at the end of all roots
  * root processing between the two collectors is very different

All these are potential follow-ups.

Thanks,
  Thomas

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

Commit messages:
 - Initial change

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

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


From ayang at openjdk.java.net  Mon Feb 21 16:25:51 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 21 Feb 2022 16:25:51 GMT
Subject: RFR: 8280958: G1/Parallel: Unify marking code structure
In-Reply-To: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
References: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
Message-ID: <-vcIwn9awE9chufSjyMZtMaMcDfpTojzLHwUns3QQcw=.87590dc1-ca3c-4226-b85c-2395a7a29fe2@github.com>

On Mon, 21 Feb 2022 15:58:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes G1 and Parallel Full GC marking code structure a bit more similar both terms of structure as well as naming?
> 
> This allows easier comparison and unless we are going to really merge them easier to do changes. They are still a bit different for several reasons:
>   * G1 Full GC can disable class unloading while Parallel Full GC always unloads classes
>   * different code structure in calls: Parallel GC drains the task queues after every kind of root, G1 only does at the end of all roots
>   * root processing between the two collectors is very different
> 
> All these are potential follow-ups.
> 
> Thanks,
>   Thomas

I'd prefer `_stack` suffix over `_tasks`, but ofc this is very subjective.

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

Marked as reviewed by ayang (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Feb 21 16:48:56 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Feb 2022 16:48:56 GMT
Subject: RFR: 8280958: G1/Parallel: Unify marking code structure
In-Reply-To: <-vcIwn9awE9chufSjyMZtMaMcDfpTojzLHwUns3QQcw=.87590dc1-ca3c-4226-b85c-2395a7a29fe2@github.com>
References: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
 <-vcIwn9awE9chufSjyMZtMaMcDfpTojzLHwUns3QQcw=.87590dc1-ca3c-4226-b85c-2395a7a29fe2@github.com>
Message-ID: <RUkFQwTo_rkzPbp86DLJyIetHbW-wSY27R-jyQv5S34=.7868ab03-a367-4dc2-8c7e-7aa75c69a218@github.com>

On Mon, 21 Feb 2022 16:22:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I'd prefer `_stack` suffix over `_tasks`, but ofc this is very subjective.

If you refer to the naming of the `publish_and/or*_tasks` methods: I really thought about that as well for quite some time, but what is being published are the tasks (e.g. from the overflow stacks to the shared stack). 

I am open to renaming that if somebody else does prefer one or the other.

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

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


From kbarrett at openjdk.java.net  Mon Feb 21 17:28:54 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 21 Feb 2022 17:28:54 GMT
Subject: RFR: 8280958: G1/Parallel: Unify marking code structure
In-Reply-To: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
References: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
Message-ID: <1r1E4euM1uj7C85iJYDMU_6EL_mJHQSlke-pXr3lmrc=.fb8400c5-b48c-481c-99cf-a79b5f1da0d6@github.com>

On Mon, 21 Feb 2022 15:58:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes G1 and Parallel Full GC marking code structure a bit more similar both terms of structure as well as naming?
> 
> This allows easier comparison and unless we are going to really merge them easier to do changes. They are still a bit different for several reasons:
>   * G1 Full GC can disable class unloading while Parallel Full GC always unloads classes
>   * different code structure in calls: Parallel GC drains the task queues after every kind of root, G1 only does at the end of all roots
>   * root processing between the two collectors is very different
> 
> All these are potential follow-ups.
> 
> Thanks,
>   Thomas

Looks good.  Just a couple whitespace nits.

src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp line 187:

> 185:     ObjArrayTask task;
> 186:     if (publish_or_pop_objarray_tasks(task) ||
> 187:       _objarray_stack.pop_local(task)) {

[pre-existing] The indentation is messed up here.

src/hotspot/share/gc/parallel/psCompactionManager.cpp line 146:

> 144:     ObjArrayTask task;
> 145:     if (publish_or_pop_objarray_tasks(task) ||
> 146:       _objarray_stack.pop_local(task)) {

Indentation is messed up here.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Feb 22 08:28:32 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 22 Feb 2022 08:28:32 GMT
Subject: RFR: 8280958: G1/Parallel: Unify marking code structure [v2]
In-Reply-To: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
References: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
Message-ID: <8VwZcobJyRBZxf6A81ndS7GMI4RAqtlIPb8KJDVOjYg=.ec5a75a2-728d-4559-9f2a-266038a83935@github.com>

> Hi all,
> 
>   can I have reviews for this change that makes G1 and Parallel Full GC marking code structure a bit more similar both terms of structure as well as naming?
> 
> This allows easier comparison and unless we are going to really merge them easier to do changes. They are still a bit different for several reasons:
>   * G1 Full GC can disable class unloading while Parallel Full GC always unloads classes
>   * different code structure in calls: Parallel GC drains the task queues after every kind of root, G1 only does at the end of all roots
>   * root processing between the two collectors is very different
> 
> All these are potential follow-ups.
> 
> Thanks,
>   Thomas

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

  Indentation fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7561/files
  - new: https://git.openjdk.java.net/jdk/pull/7561/files/4708cc6b..87a8c4e7

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

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

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


From ayang at openjdk.java.net  Tue Feb 22 12:06:10 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 22 Feb 2022 12:06:10 GMT
Subject: RFR: 8282089: [REDO] Parallel: Refactor
 PSCardTable::scavenge_contents_parallel
Message-ID: <ifaDwJrnTfOeBeTg0zTmfBz5pEwXBDxZm7_LvOAiYS0=.243c34a8-bbc3-4c88-9e68-11e90d765d94@github.com>

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.

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

Commit messages:
 - 8282089: [REDO] Parallel: Refactor PSCardTable::scavenge_contents_parallel"

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

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


From duke at openjdk.java.net  Tue Feb 22 13:29:23 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Tue, 22 Feb 2022 13:29:23 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v9]
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: <FRnWbfZ942TJSmg4GjQJnqUrYGg2iNlJh3JVG0d5Ie8=.a70966c6-e350-4d78-9995-863708ce650c@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: TestCase issues resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/f0e9d901..7b9069ce

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

  Stats: 41 lines in 1 file changed: 0 ins; 17 del; 24 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 sjohanss at openjdk.java.net  Tue Feb 22 15:23:51 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Tue, 22 Feb 2022 15:23:51 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v9]
In-Reply-To: <FRnWbfZ942TJSmg4GjQJnqUrYGg2iNlJh3JVG0d5Ie8=.a70966c6-e350-4d78-9995-863708ce650c@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <FRnWbfZ942TJSmg4GjQJnqUrYGg2iNlJh3JVG0d5Ie8=.a70966c6-e350-4d78-9995-863708ce650c@github.com>
Message-ID: <TlhQzmirX_7r5fQrXEGp0t6YEkJYu8CQGMSbo4qWLC4=.5b2fe8bf-c762-41eb-8c17-96da31ca8f16@github.com>

On Tue, 22 Feb 2022 13:29:23 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: TestCase issues resolved.

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

> 163:                     System.out.println("TestCase Passed for pagesize: " + pageSize + ", allocated pagesize: " + size);
> 164:                     break;
> 165:                 }

The test is still failing for 16G pages: 

TestCase Passed for pagesize: 16G, allocated pagesize: 64K
----------System.err:(12/796)----------
java.lang.AssertionError: TestCase Failed for 16G page allocation, 
	at runtime.os.TestExplicitPageAllocation.testCase(TestExplicitPageAllocation.java:170)
	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:69)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)


The problem is that `requiredPageCount(i)` will return 0 for 16G pages because the heap is just 1G, so the test will fill in the `errorMessage` and then the test will continue. The test not breking after setting the `errorMessage` also looks a bit wrong. At least it made it a bit harder to spot the error.

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

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


From tschatzl at openjdk.java.net  Tue Feb 22 16:28:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 22 Feb 2022 16:28:50 GMT
Subject: RFR: 8280958: G1/Parallel: Unify marking code structure [v2]
In-Reply-To: <1r1E4euM1uj7C85iJYDMU_6EL_mJHQSlke-pXr3lmrc=.fb8400c5-b48c-481c-99cf-a79b5f1da0d6@github.com>
References: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
 <1r1E4euM1uj7C85iJYDMU_6EL_mJHQSlke-pXr3lmrc=.fb8400c5-b48c-481c-99cf-a79b5f1da0d6@github.com>
Message-ID: <ijhW5INFokrjyqQoAj2CUFwTMJUnv2qldJib_1sE8hQ=.25c68bc7-0d9b-42be-922b-a6097bb8f801@github.com>

On Mon, 21 Feb 2022 17:26:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Indentation fixes
>
> Looks good.  Just a couple whitespace nits.

Thanks @kimbarrett @albertnetymk  for your reviews.

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

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


From tschatzl at openjdk.java.net  Tue Feb 22 16:28:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 22 Feb 2022 16:28:50 GMT
Subject: Integrated: 8280958: G1/Parallel: Unify marking code structure
In-Reply-To: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
References: <AEldBpq_1X-8sedAV9YUFikzqK03W4Mk9ER4tMKPiEA=.59d595f9-82f3-434e-9794-9d71afa5f572@github.com>
Message-ID: <Zp_nbFZUwjLvUJae5yn9YQ06tea8Gh0s6Jrfc8_f1HI=.3884befc-1ea6-49aa-9d73-d3a0a62e1960@github.com>

On Mon, 21 Feb 2022 15:58:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes G1 and Parallel Full GC marking code structure a bit more similar both terms of structure as well as naming?
> 
> This allows easier comparison and unless we are going to really merge them easier to do changes. They are still a bit different for several reasons:
>   * G1 Full GC can disable class unloading while Parallel Full GC always unloads classes
>   * different code structure in calls: Parallel GC drains the task queues after every kind of root, G1 only does at the end of all roots
>   * root processing between the two collectors is very different
> 
> All these are potential follow-ups.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 957dae02
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/957dae02b18b150cab8aec4846bc82086ee1e4da
Stats:     44 lines in 6 files changed: 18 ins; 8 del; 18 mod

8280958: G1/Parallel: Unify marking code structure

Reviewed-by: ayang, kbarrett

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

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


From duke at openjdk.java.net  Wed Feb 23 08:38:28 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Wed, 23 Feb 2022 08:38:28 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
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: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@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: TestCase issue resolved.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7326/files
  - new: https://git.openjdk.java.net/jdk/pull/7326/files/7b9069ce..f10b2d00

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

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 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 redestad at openjdk.java.net  Wed Feb 23 10:14:56 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 23 Feb 2022 10:14:56 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
Message-ID: <zjFXJ-_VYNUcbpxtnf6_FMdmMwXyA6Bwa-KJi6F5Wx8=.7ebc7cd3-5ef1-48f3-85d5-33a3bd552039@github.com>

On Wed, 23 Feb 2022 08:38:28 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: TestCase issue resolved.

@albertnetymk on the question whether a microbenchmark like this makes sense: I think it _can_ be useful to add micros that are diagnostics/verification tools for corner case effects, even if they'd be a bad fit for inclusion in automated regression testing. Still it's important to make sure each such micro has reasonable runtime, provides decent signal to noise and has well-documented external constraints. We do not automatically include newly added microbenchmarks in automated testing so don't worry about this clogging up the CI or weekly perf testing. 

Setting up benchmarks that stress large pages is brittle and depends a lot on the system and things out of control of the JMH micro itself, so I'd ask for a high-level comment in the microbenchmark that gives a quick rundown on what the benchmark is trying to test, how to configure the system, how you verify it's actually testing the right thing and in which configurations you expect to see an effect.

test/micro/org/openjdk/bench/vm/gc/MicroLargePages.java line 34:

> 32: public class MicroLargePages {
> 33: 
> 34:     @Param({"1073741824"})

Exactly 10^30 elements + array header size means the `long[]` will be a couple of bytes above 1GB. Have you tried the experiment on slightly smaller values?

To make the micro more practical in terms of runtime it'd be interesting if the effects can be verified using either smaller `ARRAYSIZE` by default, or by having the loop in `micro_HOP_DIST_4KB` that iterates from `0` to `ARRAYSIZE` only iterate a small fraction of the total size.

test/micro/org/openjdk/bench/vm/gc/MicroLargePages.java line 57:

> 55:     @Benchmark
> 56:     public void micro_HOP_DIST_4KB() {
> 57:         for (int i = 0; i < ITERS ; i++) {

JMH runs as many iterations it can in the allotted runtime. The `ITERS` loop here seem completely unnecessary and just increase the runtime of each 100x. Having a benchmark iteration take an excessively long time like this also throws off the total runtime estimates. 

If you want to make sure the micro runs for at least some number of times to capture some effect you'd be better off doing so by increasing the iteration time.

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

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


From sjohanss at openjdk.java.net  Wed Feb 23 10:23:58 2022
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Wed, 23 Feb 2022 10:23:58 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
Message-ID: <cGlsVMZ9jRfZxoK2Ue0akyNLZ_5OL8yGN0vNlQ3ml3g=.785e5e6f-bbe2-44b9-a425-366d5dd82a0d@github.com>

On Wed, 23 Feb 2022 08:38:28 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: TestCase issue resolved.

Test is now working but I still have some additional comments.

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

> 48: 
> 49:     private static final String DIR_HUGE_PAGES = "/sys/kernel/mm/hugepages/";
> 50:     private static final long HEAP_SIZE_IN_KB = 1 * 1024 * 1024;

This heap size is used to calculate the required number of pages needed but it is not used when creating the process, so the calculation will be incorrect. I suggest you use this value in the process creation as well, to avoid accidentally change one value but not the other.

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

> 68:                 if (pageSizes[i]) {
> 69:                     testCase(i);
> 70:                     break;

Can you please motivate this break? Why do we only want to test the largest page size? And if this is the case why not just record the largest page size during the setup-phase?

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

> 91:            return Long.toString(sizeInBytes / m) + "M";
> 92:         else
> 93:            return Long.toString(sizeInBytes / g) + "G";

Please add { } to the if-statements.

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

> 169:         if (errorMessage != "") {
> 170:             throw new AssertionError(errorMessage);
> 171:         }

So this now works, but I think it is pretty hard to follow the logic with the continues and breaks and I don't see any benefit from not just throwing the `AssertionError()` when a failure occurs. 

What do you think about something like this:

for (int i = index; i >= vmPageSizeIndex; i--) {
    if (pageSizes[i]) {
        String size = sizeFromIndex(i);
        System.out.println("Checking allocation for " + size);
        if (checkOutput(output, size)) {
            System.out.println("TestCase Passed for pagesize: " + pageSize + ", allocated pagesize: " + size);
            // Page allocation succeeded no need to check any more page sizes.
            return;
        } else {
            // Only consider this a test failure if there are enough configured
            // pages to allow this reservation to succeeded.
            if (requiredPageCount(i) <= pageCount[i]) {
                throw new AssertionError("TestCase Failed for " + size + " page allocation. " +
                                         "Required pages: " + requiredPageCount(i) + ", " +
                                         "Configured pages: " + pageCount[i]);
            }
        }
    }
}


I ran this through our testing and it also works.

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

Changes requested by sjohanss (Reviewer).

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


From ayang at openjdk.java.net  Wed Feb 23 12:45:10 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Feb 2022 12:45:10 GMT
Subject: RFR: 8282299: Remove unused PartialArrayScanTask default constructor
Message-ID: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>

Trivial change of removing dead code.

Test: build

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

Commit messages:
 - trivial

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

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


From ayang at openjdk.java.net  Wed Feb 23 14:45:57 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Feb 2022 14:45:57 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v10]
In-Reply-To: <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
References: <8xN8ggw1aNl_gfaOcR4PRi6GRovBoBswi4yv7q4Sp_A=.95505a10-2bfe-427c-9849-4ccfe4340585@github.com>
 <ITtwXm7Pz8N-r-qc4md4-vHhNsooK1Ppz2nqi-X9TnE=.93a59ab2-1337-4f2d-975d-f455a3365c21@github.com>
Message-ID: <VbOAkxyLTn81Pza3mdhmuB5rOMGoOJ9FbhgV79g6jlU=.cabd04f9-c020-428c-8e66-39e1aaa9a8c2@github.com>

On Wed, 23 Feb 2022 08:38:28 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: TestCase issue resolved.

This PR has evolved quite much from what I reviewed/approved. I am dropping my approval now. Will re-review it later this week.

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

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


From ayang at openjdk.java.net  Wed Feb 23 15:04:09 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Feb 2022 15:04:09 GMT
Subject: RFR: 8282307: Parallel: Incorrect discovery mode in
 PCReferenceProcessor
Message-ID: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>

Simple followup of [JDK-8273185](https://bugs.openjdk.java.net/browse/JDK-8273185). This bug should not affect correctness though: treating STW discovery as concurrent discovery.

Test: hotspot_gc

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

Commit messages:
 - ps-concurrent-discovery

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

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


From tschatzl at openjdk.java.net  Wed Feb 23 16:04:50 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 23 Feb 2022 16:04:50 GMT
Subject: RFR: 8282299: Remove unused PartialArrayScanTask default
 constructor
In-Reply-To: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>
References: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>
Message-ID: <wqxTYZezOWV2b64kuM_eDFv5wNUCVChXnBzotkZYM6g=.c265a3b0-d654-4ba6-a810-d8b178b83bd9@github.com>

On Wed, 23 Feb 2022 12:37:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Wed Feb 23 16:06:53 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 23 Feb 2022 16:06:53 GMT
Subject: RFR: 8282307: Parallel: Incorrect discovery mode in
 PCReferenceProcessor
In-Reply-To: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
References: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
Message-ID: <zy0lJHtuyzzi55vkPvsk_yMMmRv6773Xzl-ZipF_IPY=.3fa36bca-7f98-4ab1-ac4a-cb3495561923@github.com>

On Wed, 23 Feb 2022 14:58:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple followup of [JDK-8273185](https://bugs.openjdk.java.net/browse/JDK-8273185). This bug should not affect correctness though: treating STW discovery as concurrent discovery.
> 
> Test: hotspot_gc

Lgtm apart from the pre-existing indentation problem.

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 856:

> 854:       ParallelGCThreads,   // mt processing degree
> 855:       ParallelGCThreads,   // mt discovery degree
> 856:       false,               // concurrent_discovery

It would be nice to improve the indentation of this code, i.e. the parameters of the `ReferenceProcessor` super class constructor call should be indented.

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

Marked as reviewed by tschatzl (Reviewer).

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


From ayang at openjdk.java.net  Wed Feb 23 19:07:27 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 23 Feb 2022 19:07:27 GMT
Subject: RFR: 8282307: Parallel: Incorrect discovery mode in
 PCReferenceProcessor [v2]
In-Reply-To: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
References: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
Message-ID: <gyHbHoWIss2HH2LLF63SiioTjpKUsiyYlNhUBxqKeVw=.5a3e9eb5-2777-4512-97b4-398c2775528a@github.com>

> Simple followup of [JDK-8273185](https://bugs.openjdk.java.net/browse/JDK-8273185). This bug should not affect correctness though: treating STW discovery as concurrent discovery.
> 
> Test: hotspot_gc

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7590/files
  - new: https://git.openjdk.java.net/jdk/pull/7590/files/fdf5b526..7d176a05

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

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

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


From ayang at openjdk.java.net  Thu Feb 24 09:20:05 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 09:20:05 GMT
Subject: Integrated: 8282299: Remove unused PartialArrayScanTask default
 constructor
In-Reply-To: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>
References: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>
Message-ID: <6T8qo0T9OhUglKQBBp7IU36IlUkVxwdjY1qx6OKEGRM=.45de9281-8c6f-459a-b889-95ade542f100@github.com>

On Wed, 23 Feb 2022 12:37:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

This pull request has now been integrated.

Changeset: cd3e59ef
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cd3e59ef88bcc040f9d671c8c15370efaae3ffd8
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8282299: Remove unused PartialArrayScanTask default constructor

Reviewed-by: tschatzl

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

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


From ayang at openjdk.java.net  Thu Feb 24 09:20:05 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 09:20:05 GMT
Subject: RFR: 8282299: Remove unused PartialArrayScanTask default
 constructor
In-Reply-To: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>
References: <55YUe3T7swUh3qf2ip2BVqaxAcXELNYOmEiFHINB4Hs=.80fbdcbb-72bd-44c2-a60b-fe4f7f35b936@github.com>
Message-ID: <URwEXitMWnjzlIx9Y7LDfxOZCETaXFEhWKS-PlkcCKM=.c66e95dc-5c83-4a6a-8fd7-b90b37941b31@github.com>

On Wed, 23 Feb 2022 12:37:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial change of removing dead code.
> 
> Test: build

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Feb 24 13:13:23 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 13:13:23 GMT
Subject: RFR: 8282348: Remove unused CardTable::dirty_card_iterate
Message-ID: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>

Simple change of removing dead code.

Test: hotspot_gc

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

Commit messages:
 - remove-dirty_card_iterate

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

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


From kbarrett at openjdk.java.net  Thu Feb 24 14:09:04 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 24 Feb 2022 14:09:04 GMT
Subject: RFR: 8282348: Remove unused CardTable::dirty_card_iterate
In-Reply-To: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>
References: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>
Message-ID: <LbhLfnmneO6_mgTeFa5-vzPLfQRY3wRfGCNSRHNkEvk=.e37fb480-00be-4873-a14f-16e832258fe3@github.com>

On Thu, 24 Feb 2022 13:06:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Looks good, and trivial.  I think this was used by CMS.

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

Marked as reviewed by kbarrett (Reviewer).

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


From iwalulya at openjdk.java.net  Thu Feb 24 15:40:33 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 24 Feb 2022 15:40:33 GMT
Subject: RFR: 8267834: Refactor G1CardSetAllocator and BufferNode::Allocator to
 use a common base class
Message-ID: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>

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

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

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

Changes: https://git.openjdk.java.net/jdk/pull/7615/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7615&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267834
  Stats: 717 lines in 10 files changed: 390 ins; 281 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7615.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7615/head:pull/7615

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


From iwalulya at openjdk.java.net  Thu Feb 24 16:51:56 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 24 Feb 2022 16:51:56 GMT
Subject: RFR: 8267834: Refactor G1CardSetAllocator and
 BufferNode::Allocator to use a common base class [v2]
In-Reply-To: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
References: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
Message-ID: <HJdOtq1bebrq0lsf18aXUvXS-mmfvBv40LPcitaK0uk=.20d7c285-e6d0-4a8a-ab70-45921fd59ef5@github.com>

> 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:

  cleanup includes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7615/files
  - new: https://git.openjdk.java.net/jdk/pull/7615/files/dee62d67..60d41d36

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

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

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


From kbarrett at openjdk.java.net  Thu Feb 24 17:30:06 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 24 Feb 2022 17:30:06 GMT
Subject: RFR: 8267834: Refactor G1CardSetAllocator and
 BufferNode::Allocator to use a common base class [v2]
In-Reply-To: <HJdOtq1bebrq0lsf18aXUvXS-mmfvBv40LPcitaK0uk=.20d7c285-e6d0-4a8a-ab70-45921fd59ef5@github.com>
References: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
 <HJdOtq1bebrq0lsf18aXUvXS-mmfvBv40LPcitaK0uk=.20d7c285-e6d0-4a8a-ab70-45921fd59ef5@github.com>
Message-ID: <z-ZIvjaOmLja-nvu29rU9ufAFtm9aPS14zbgPVKzsv8=.9887f98d-5c2d-4fe1-8486-03953051e076@github.com>

On Thu, 24 Feb 2022 16:51:56 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:
> 
>   cleanup includes

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/freeListAllocator.cpp line 31:

> 29: 
> 30: FreeListAllocator::NodeList::NodeList() :
> 31:   _head(NULL), _tail(NULL), _entry_count(0) {}

NULL -> nullptr, here and elsewhere.  Some code here is already adopting nullptr, and since this is "new" it should be consistent.

src/hotspot/share/gc/shared/freeListAllocator.cpp line 82:

> 80:   while (list != NULL) {
> 81:     FreeNode* next = list->next();
> 82:     DEBUG_ONLY(list->set_next(NULL);)

Setting next to null isn't needed unless there's a null check in the destructor.  The current destructor is defaulted.  I think some predecessors to this code might have had a debug-only assert that next was null.

src/hotspot/share/gc/shared/freeListAllocator.cpp line 102:

> 100: // method on nodes not managed by an arena will leak the memory by just dropping
> 101: // the nodes to the floor.
> 102: void FreeListAllocator::reset() {

I prefer this kind of API documentation in the header.

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

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


From kbarrett at openjdk.java.net  Thu Feb 24 17:38:10 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 24 Feb 2022 17:38:10 GMT
Subject: RFR: 8282307: Parallel: Incorrect discovery mode in
 PCReferenceProcessor [v2]
In-Reply-To: <gyHbHoWIss2HH2LLF63SiioTjpKUsiyYlNhUBxqKeVw=.5a3e9eb5-2777-4512-97b4-398c2775528a@github.com>
References: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
 <gyHbHoWIss2HH2LLF63SiioTjpKUsiyYlNhUBxqKeVw=.5a3e9eb5-2777-4512-97b4-398c2775528a@github.com>
Message-ID: <vNFf2xuapKx7Sbc1Vd3W5LLN2XFnrjFZSSzgAot8duM=.81729e48-913d-4133-81c3-7b20e1996660@github.com>

On Wed, 23 Feb 2022 19:07:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple followup of [JDK-8273185](https://bugs.openjdk.java.net/browse/JDK-8273185). This bug should not affect correctness though: treating STW discovery as concurrent discovery.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Thu Feb 24 17:49:12 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 17:49:12 GMT
Subject: RFR: 8282307: Parallel: Incorrect discovery mode in
 PCReferenceProcessor [v2]
In-Reply-To: <gyHbHoWIss2HH2LLF63SiioTjpKUsiyYlNhUBxqKeVw=.5a3e9eb5-2777-4512-97b4-398c2775528a@github.com>
References: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
 <gyHbHoWIss2HH2LLF63SiioTjpKUsiyYlNhUBxqKeVw=.5a3e9eb5-2777-4512-97b4-398c2775528a@github.com>
Message-ID: <u5uPL643Z9czIkSrAJpR0TBGXPnlLWBF8nqyghbslX8=.9b2b1ec9-c435-4037-97b0-d0c8fcb5d3e9@github.com>

On Wed, 23 Feb 2022 19:07:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple followup of [JDK-8273185](https://bugs.openjdk.java.net/browse/JDK-8273185). This bug should not affect correctness though: treating STW discovery as concurrent discovery.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Feb 24 17:52:05 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 17:52:05 GMT
Subject: RFR: 8282348: Remove unused CardTable::dirty_card_iterate
In-Reply-To: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>
References: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>
Message-ID: <gMAq2PYbJ8g1NDT3F7gua-onayDIA2OMH5M5fvB_1Bk=.974baa69-511c-4f0a-a023-2b39f2b70b61@github.com>

On Thu, 24 Feb 2022 13:06:29 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/7610


From ayang at openjdk.java.net  Thu Feb 24 17:52:06 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 17:52:06 GMT
Subject: Integrated: 8282348: Remove unused CardTable::dirty_card_iterate
In-Reply-To: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>
References: <En6LAEizhK-fujROEZlBt5XvfE2_RsqI-PEzfcEy7XA=.821fa953-a149-418d-ac8a-16cd4e432798@github.com>
Message-ID: <30RYMf4E9Rl382kWcZo5Hi4C2TJRlVQpLa170lHv2UE=.5a173131-5ef6-46b1-b46a-456b8b7d5e5a@github.com>

On Thu, 24 Feb 2022 13:06:29 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: 0b6862e8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0b6862e803a03cf7f722f4f58b657712e74723fb
Stats:     30 lines in 2 files changed: 0 ins; 30 del; 0 mod

8282348: Remove unused CardTable::dirty_card_iterate

Reviewed-by: kbarrett

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

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


From ayang at openjdk.java.net  Thu Feb 24 17:52:08 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 24 Feb 2022 17:52:08 GMT
Subject: Integrated: 8282307: Parallel: Incorrect discovery mode in
 PCReferenceProcessor
In-Reply-To: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
References: <c4_pFPx81w0dfYHoHVc230DxWQwhTVHJqVEa2qSaI1g=.7cc713ae-aa5b-4066-8f31-46b49f951134@github.com>
Message-ID: <-aD085Lg3nfNuhuY-D4JsYY9yPsPRxJ2DY1FyEs3Lc8=.9f46c83a-e7b8-4549-84c7-133116a22fb7@github.com>

On Wed, 23 Feb 2022 14:58:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple followup of [JDK-8273185](https://bugs.openjdk.java.net/browse/JDK-8273185). This bug should not affect correctness though: treating STW discovery as concurrent discovery.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8282307: Parallel: Incorrect discovery mode in PCReferenceProcessor

Reviewed-by: tschatzl, kbarrett

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

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


From ayang at openjdk.java.net  Fri Feb 25 07:21:28 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 25 Feb 2022 07:21:28 GMT
Subject: RFR: 8282381: Parallel: Remove unnecessary PCReferenceProcessor
Message-ID: <YaQKCS6KrZNLag3MO5znu7GrMtrYCpUbgxgZm5qlx5w=.1e7cd241-fb0b-430d-9e1b-dd9d67e70b0a@github.com>

Simple change of removing a redundant class.

Test: tier1-5

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

Commit messages:
 - ps-ref-discover

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

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


From iwalulya at openjdk.java.net  Fri Feb 25 12:27:51 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 25 Feb 2022 12:27:51 GMT
Subject: RFR: 8267834: Refactor G1CardSetAllocator and
 BufferNode::Allocator to use a common base class [v3]
In-Reply-To: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
References: <YRvZYhNpBXrFxzZa4-TyyS1lMbAoYW8DySl1JB3Wst4=.2408cf0e-2ca0-4c14-b3b5-4e899648362e@github.com>
Message-ID: <5uh-Qua4253Tv4PgIQqNte4jCDH8mF1h2g0PW5ySKeI=.d3f1c644-dc54-435b-a8bb-5af145d49e57@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7615/files
  - new: https://git.openjdk.java.net/jdk/pull/7615/files/60d41d36..01c78d62

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

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

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


From ayang at openjdk.java.net  Fri Feb 25 13:09:56 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 25 Feb 2022 13:09:56 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <k-mqKdvjW5fsIuHomQYgxQI5KnSGtmO2CSFv-TYwbqY=.96384b92-a032-4293-9b38-11009709bdac@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>
Message-ID: <4jUo7n2RZpPa48GqECGWIKvia9v1nzo2mvUCtoMLcLY=.838dd8af-d0aa-4045-8cf6-38dd4a0562e0@github.com>

On Thu, 17 Feb 2022 15:50:05 GMT, Swati Sharma <duke at openjdk.java.net> wrote:

>>> > > I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m.
>>> > 
>>> > 
>>> > I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475
>>> 
>>> Thanks for digging out the JBS issue for this.
>>> 
>>> > > Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.
>>> > 
>>> > 
>>> > I would actually like the following behavior:
>>> > ```
>>> > * LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
>>> > 
>>> > * when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).
>>> > ```
>>> > 
>>> > 
>>> >     
>>> >       
>>> >     
>>> > 
>>> >       
>>> >     
>>> > 
>>> >     
>>> >   
>>> > I think this is close to what we do now.
>>> > So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
>>> > ```
>>> > * a single 1G page and 256 2m pages for the heap
>>> > ```
>>> 
>>> Currently this would round the heap up to 2G and use 2 1G pages, right? But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages. There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
>>> 
>>> > ```
>>> > * 128 2m pages for the code cache
>>> >   ... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.
>>> > ```
>>> > 
>>> > 
>>> >     
>>> >       
>>> >     
>>> > 
>>> >       
>>> >     
>>> > 
>>> >     
>>> >   
>>> > Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?
>>> 
>>> This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
>>> 
>>> If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
>>> 
>>> Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
>> 
>> Hi @kstefanj , @tstuefe 
>> 
>> Thanks for sharing your views and comments. 
>> Please suggest what specific change you want us to do in the patch since it is fixing the already existing functionality.
>> 
>> Best Regards,
>> Swati
>
>> @swati-sha, I took a closer look at the test-case and right now it won't work when run on aarch64? On those systems in our test environment the base page size is 64k and the large page sizes are 2m and 512m. I took it for a spin to see what failures we would get and here it is:
>> 
>> ```
>> [0.001s][info][pagesize] LargePageSizeInBytes is not a valid large page size (1G) using the default large page size: 512M
>> [0.001s][info][pagesize] Usable page sizes: 64k, 2M, 512M
>> [0.001s][info][pagesize] Large page size (512M) failed sanity check, checking if smaller large page sizes are usable
>> [0.001s][warning][pagesize] UseLargePages disabled, no large pages configured and available on the system.
>> [0.002s][info   ][pagesize] CodeHeap 'non-nmethods':  min=2496K max=5760K base=0x0000fffec55d0000 page_size=64K size=5760K
>> [0.002s][info   ][pagesize] CodeHeap 'profiled nmethods':  min=2496K max=120000K base=0x0000fffec5b70000 page_size=64K size=120000K
>> [0.002s][info   ][pagesize] CodeHeap 'non-profiled nmethods':  min=2496K max=120000K base=0x0000fffecd0a0000 page_size=64K size=120000K
>> [0.002s][info   ][pagesize] Heap:  min=1G max=2G base=0x0000000080000000 page_size=64K size=2G
>> [0.002s][info   ][pagesize] Card Table:  min=4194305B max=4194305B base=0x0000fffee0db0000 page_size=64K size=4160K
>> [0.003s][info   ][pagesize] Mark Bitmap:  min=64M max=64M base=0x0000fffebc000000 page_size=64K size=64M
>> [0.003s][info   ][pagesize] Parallel Compact Data:  min=160K max=160K base=0x0000fffee08b0000 page_size=64K size=192K
>> [0.003s][info   ][pagesize] Parallel Compact Data:  min=4M max=4M base=0x0000fffee04b0000 page_size=64K size=4M
>> System does not support 1G pages
>> Number of 2M pages = 0
>> 
>> System does not support 1G pages
>> Number of reserved 1G pages = -1
>> 
>> Number of reserved 2M pages = 0
>> 
>> TestCase1 skipped
>> 
>> TestCase2 skipped
>> 
>> Exceptionjava.lang.RuntimeException: System property 'test.jdk' not set. This property is normally set by jtreg. When running test separately, set this property using '-Dtest.jdk=/path/to/jdk'.
>> TestCase4 skipped
>> 
>> ----------System.err:(11/560)----------
>> java.lang.AssertionError: Failed 4K page allocation
>> 
>> 	at runtime.os.TestExplicitPageAllocation.main(TestExplicitPageAllocation.java:81)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>> 	at java.base/java.lang.Thread.run(Thread.java:828)
>> ```
>> 
>> So either we need to make the test more robust to also work without having hard coded page sizes but rather figure them out during the "setup" stage or we need to add a requires to avoid running on aarch64. I would prefer if the test was fixed to get more coverage and testing with different page sizes. Doing the requires could look something like:
>> 
>> ```
>> @requires os.arch=="amd64" | os.arch=="x86_64"
>> ```
> 
> Hi @kstefanj,
> 
> Added the generalized version of testcase. Please review and let me know.
> 
> Thanks,
> Swati

Hi @swati-sha, I have gone through the latest version. I think the change in hotspot is good enough, but the test still needs some improvement.

The test tries to be generic/general enough to cover many scenarios (diff combinations of archs, huge-page sizes, number of huge-page), which made the logic hard to follow. I believe debugging would be challenging as well when it fails. (At least the experience from @kstefanj corroborates my belief.)  Additionally, the Code Cache consumes large pages as well, so `-XX:ReservedCodeCacheSize=<> -XX:InitialCodeCacheSize=<>` should be in the command line to ensure there are enough large pages left for the Heap. (There are maybe other subtleties --- I didn't test much.)

Therefore, I would prefer sth like the following --- it's amd64 specific and focuses only on the fall-back behavior. (More test cases are probably interesting as well, but this captures exactly what's introduced in this PR.)


  var n_2m_pages = ...
  var n_1g_pages = ...
  
  if (n_1g_pages == 0 && n_2m_pages >= ...) {
    output = $(java <heap_size> <code_cache_size> -XX:-XX:LargePageSizeInBytes=1g --version)
    // checking output
  } else {
    // skip
    print "Skipping test because ..."
  }


Considering that having a reliably-working test in this particular case could be sutble and it's desirable to have this bugfix merged sooner, I suggest dropping the test and the microbenchmark (since there's some unresolved comment on it as well) from this PR and deal with that in another ticket/PR. What do others think?

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

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


From kbarrett at openjdk.java.net  Fri Feb 25 14:45:55 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 25 Feb 2022 14:45:55 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: <7X8xBY0sbp9MANs2vQm-Gn4LLocgw0z2VUvWMgdHqb4=.38e81f68-0e50-4dae-862e-13f4e8eabacc@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

I think this is probably okay, but I'd like to see some performance testing.

The is_unmarked check before calling the generic reference processor's
discover_reference has been present for a long time; it's there in the initial
mercurial version.  The corresponding is_alive_closure for the reference
processor is there too.

It's hard to know whether this was just an unintentional duplication of work,
or if someone thought (or measured) that doing the is_unmarked check early was
beneficial.

Pre-checking for marking is consistent with what's done for collections that
use header marking. It looks like a different way to remove the sometimes
duplicated work would be to not provide the is_alive_non_header closure.
That's what this change should be compared to for performance.

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

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


From kbarrett at openjdk.java.net  Fri Feb 25 15:58:54 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 25 Feb 2022 15:58:54 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: <oTjGSMpg0r50tbSeKPolu1_Ci5YMyJ8VpIc_ASbOsAU=.09a48427-d90d-450b-b3cb-a2fe8ba3f77f@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

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Sat Feb 26 09:32:53 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 26 Feb 2022 09:32:53 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v8]
In-Reply-To: <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <9OmS7843VH_98tTgDxtrjOLxfZgHdP94kfEnbjGvRlk=.92d8cc3c-9f33-4831-b8bf-fc2ac9824a16@github.com>
Message-ID: <NcNhwMK3tQaEGkJRpPXrHRUSftUaNCIxeg4FGTfaleU=.1b629ed3-2094-4f7e-a147-6f01cb652a40@github.com>

On Fri, 18 Feb 2022 12:00:29 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:
> 
>   Thomas review

> `_evac_failure_regions->par_iterate_chunks_in_regions(&chunk_closure, worker_id);` is essentially:
> 
> ```c++
> for (r : evac_fail_regions) {
>   for (chunk : r->chunks) {
>     if (chunk.try_claim()) {
>       chunk_closure(chunk);
>     }
>   }
> }
> ```
> 
> However, I don't see a compelling reason for a two-level iteration, first on all regions and second on chunks inside one region.
> 
> I wonder if sth like the following works. IMO, it expresses the intent more clearly and gets rid of the def/use of closures.
> 
> ```c++
> auto start_chunk_id = worker_id * total_chunks / n_workers;
> 
> for (auto i = 0; i < total_chunks; ++i) {
>   auto chunk_id = (start_chunk_id + i) % total_chunks;
>   G1HeapRegionChunk chunk(chunk_id, ...); // I think the constructor does too much currently
>   if (!chunk.try_claim())
>     continue;
>   // claimed
>   process_chunk(chunk);
> }
> ```
> 
> (This gist is just to show the structure; probably contains bugs.)

Thanks, I agree, will upate the patch as you suggested.

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

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


From mli at openjdk.java.net  Sat Feb 26 09:32:52 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 26 Feb 2022 09:32:52 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v7]
In-Reply-To: <0mpBaUje6TXl5tIicc1R6t9eofBTUe-AbNLtnP2SiM4=.7ad11132-638f-47be-be11-fdb5a5a6bf9e@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <m5KptruKW71ik5_BfcO2JGLcp2zTWqCGUOe6sgpU3kg=.4c328a59-4293-4504-91f5-a4935bd9cf07@github.com>
 <8OKi8-o3NWT7YqAvg2dMOe_Khn-YTLlIm40d_rHeoSI=.9fd3929d-5987-459e-8be0-00a06ae6fe1b@github.com>
 <Tx8MOPzL1-4Tz7JikE4UaIQgfICo7jOTvg_dvAh-S-8=.3e1205a6-dc24-4a78-a977-ecebc3a99d6a@github.com>
 <0mpBaUje6TXl5tIicc1R6t9eofBTUe-AbNLtnP2SiM4=.7ad11132-638f-47be-be11-fdb5a5a6bf9e@github.com>
Message-ID: <iW5KpyTJsV5-fjofXbNSzAfObR7FDilhw0_C1l2R64I=.dd4d5e44-c3cd-4a21-ae98-34542679fc25@github.com>

On Fri, 18 Feb 2022 15:01:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I would prefer including this chunk sizing heuristic in this PR.
> 
Sure, will update the patch.

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

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


From mli at openjdk.java.net  Sat Feb 26 12:31:32 2022
From: mli at openjdk.java.net (Hamlin Li)
Date: Sat, 26 Feb 2022 12:31:32 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v9]
In-Reply-To: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
Message-ID: <rVcZyYfg4vb64MsT8JrIJoQjKg8oZxeCIv4URODTCCo=.28f13f8f-800e-4bf2-86f6-0bdb35c31a3b@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 & Albert review

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

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

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

  Stats: 210 lines in 12 files changed: 83 ins; 81 del; 46 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 ayang at openjdk.java.net  Mon Feb 28 09:58:50 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 28 Feb 2022 09:58:50 GMT
Subject: RFR: 8256265: G1: Improve parallelism in regions that failed
 evacuation [v9]
In-Reply-To: <rVcZyYfg4vb64MsT8JrIJoQjKg8oZxeCIv4URODTCCo=.28f13f8f-800e-4bf2-86f6-0bdb35c31a3b@github.com>
References: <HM0FkWWYz7zc6bijQu15EX8ctrF5WLvMeAtqoKejR1k=.bfd7c2c5-05de-45fe-934e-2d91577607c5@github.com>
 <rVcZyYfg4vb64MsT8JrIJoQjKg8oZxeCIv4URODTCCo=.28f13f8f-800e-4bf2-86f6-0bdb35c31a3b@github.com>
Message-ID: <utq8d2qP_IzhEkJINtPAalpApQlpabQhoBaPhK6cFBI=.dc85a91e-0b68-4e9d-b978-f71d4a0fec29@github.com>

On Sat, 26 Feb 2022 12:31:32 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:
> 
>   Thomas & Albert review

Thank you for the revision; some further comments/suggestions/questions:

1. IMO, `par_iterate_chunks_in_regions` is less readable than the explicit for-loop I suggested above.

2. I think the `update_states` method could be more precisely structured to sth like:


struct RegionMarkedWordsCache {
  int _region_idx;
  size_t _marked_words;

  constructor {
    _region_idx = invalid_region_idx;
  }
  
  void add(int region_idx, size_t marked_words) { // <-- update_states
    if (_region_idx == region_idx) {
      _marked_words += marked_words;
    } else ...
  }
  
  void flush() { // <-- sync_last_region_data
    ...
  }
};


The benefit of having such kind of a cache is that one can easily enable/disable it to check whether a cache is really needed in this case. (I think it does, but it's better to do some benchmarking.)

3. There seems some dead code in this PR, such as `G1ParRemoveSelfForwardPtrsTask::initialize_chunks`, `G1ScanChunksInHeapRegions::_evac_failure_regions_length`. (I may have missed others.)

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`.

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

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


From ayang at openjdk.java.net  Mon Feb 28 10:35:54 2022
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 28 Feb 2022 10:35:54 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: <txFFcsojLPoe_GNqVJ5VHNehE8Jb1UfJZse7VehorWo=.4c626d10-0efb-43bb-a9dd-d79c4a9d3510@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

I have compared 3 versions:

1. baseline (parent of 2 & 3)
2. this PR
3. oneline diff of using `nullptr` as the second arg of `PCReferenceProcessor` constructor.

and there's no significant diff among them running specjbb2015, specjvm2008, etc.

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

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


From duke at openjdk.java.net  Mon Feb 28 13:08:34 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 28 Feb 2022 13:08:34 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v11]
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: <nzDLimKvr9Tjn1UHGMbtASP8Fsdo74KgcnvhX-vQW0U=.ed09a922-1fd4-4d9c-9046-6b0f4ea3224b@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: Resolved the comments.

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

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

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

  Stats: 52 lines in 2 files changed: 20 ins; 15 del; 17 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  Mon Feb 28 13:08:35 2022
From: duke at openjdk.java.net (Swati Sharma)
Date: Mon, 28 Feb 2022 13:08:35 GMT
Subject: RFR: 8271195: Use largest available large page size smaller than
 LargePageSizeInBytes when available [v3]
In-Reply-To: <4jUo7n2RZpPa48GqECGWIKvia9v1nzo2mvUCtoMLcLY=.838dd8af-d0aa-4045-8cf6-38dd4a0562e0@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>
Message-ID: <6MhghRS8-9VQDRVVtluDRKO-d4f5dhgwUog3nVkNIOg=.11cc3a38-c023-433c-82a2-e1c24dad5db4@github.com>

On Fri, 25 Feb 2022 13:06:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> XX:ReservedCodeCacheSize=<> -XX:InitialCodeCacheSize=<>

Hi @albertnetymk , @kstefanj ,

I have pushed the changes as suggested by @kstefanj, Initial version created was having explicit predicate  conditions for each test case and was in line to what is being proposed by you.  To accommodate your comments I have modified the test to include explicit -XX:ReservedCodeCacheSize and considering it while computing the required page count.

With this we should be able extend the existing test case to cover all the comments instead of re-instantiating initial test case version.

Looking forward to your feedback and approval.

Thanks,
Swati Sharma

PS:  Following are  the performance numbers for modified JMH benchmark over 2S 40C Ice lake Server (Intel(R) Xeon(R) Platinum 8380)

2M pages
Benchmark                           (ARRAYSIZE)  (NUM)   Mode  Cnt        Score         Error    Units
MicroLargePages.micro_HOP_DIST_4KB      2097152      1  thrpt   10  2047721.586 ? 1100027.488  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      2  thrpt   10   741954.577 ?  174530.486  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      4  thrpt   10   330249.555 ?   31666.913  ops/min

4K pages
Benchmark                           (ARRAYSIZE)  (NUM)   Mode  Cnt        Score        Error    Units
MicroLargePages.micro_HOP_DIST_4KB      2097152      1  thrpt   10  1412321.440 ? 188738.874  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      2  thrpt   10   515607.542 ?   2258.591  ops/min
MicroLargePages.micro_HOP_DIST_4KB      2097152      4  thrpt   10   303250.463 ?   2862.549  ops/min

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

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


From kbarrett at openjdk.java.net  Mon Feb 28 15:11:47 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 28 Feb 2022 15:11:47 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: <r9AHa4f7IaXYPQ1zZLMYBeA1HK1CM74YpNvZz1ws2XM=.001d1f24-b07b-4438-b1b6-304e264a3585@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

Looks good.  Thanks for doing the perf checks.

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

Marked as reviewed by kbarrett (Reviewer).

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


From iwalulya at openjdk.java.net  Mon Feb 28 16:28:53 2022
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 28 Feb 2022 16:28:53 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: <7VLs8v04fS2-3B8L2Rrss6XUikixaUv4I_Q-irK8i54=.0ada2686-773d-49ed-9d85-71ec4f08d459@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!

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

Marked as reviewed by iwalulya (Reviewer).

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