From kbarrett at openjdk.java.net  Thu Jul  1 00:28:57 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 00:28:57 GMT
Subject: RFR: 8133873: Simplify {Register,
 Unregister}NMethodOopClosure [v2]
In-Reply-To: <bwUdnr5XkSqkN88Np2eZNTkDRrMqiwedQ5Oz6qP2yBI=.5da88022-b0ba-410b-a26b-c49ae821be2a@github.com>
References: <O4O4HUzoBMTb19GKeQjw-rT47zWJ9BB5M5Tmc7ST7Cg=.a66f4f96-ad5a-4b2b-b0fc-738a60b9426c@github.com>
 <bwUdnr5XkSqkN88Np2eZNTkDRrMqiwedQ5Oz6qP2yBI=.5da88022-b0ba-410b-a26b-c49ae821be2a@github.com>
Message-ID: <4wiec4hfU0_sJCVSIlVH2V6YMgxC78NIDD6yg3ypwAs=.9e0a4114-90fd-43f8-a37c-7948b51fedeb@github.com>

On Wed, 30 Jun 2021 13:41:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of excluding compressed oops in nmethod closures.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore assert

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Thu Jul  1 01:40:59 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 1 Jul 2021 01:40:59 GMT
Subject: RFR: JDK-8269651: ZGC: Optimize away gc locker in mark start
In-Reply-To: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
References: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
Message-ID: <TUqxaZXjpB_qQx1KW3DoUspBoASV1zYcT6495Beva74=.06889c49-d0b3-4e74-a526-a4bab6203dc7@github.com>

On Wed, 30 Jun 2021 11:58:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, ZGC involves gc locker in mark-start and relocate-start.
> It seems gc locker in mark-start is not necessary anymore.
> This is to remove this unnecessary(??) gc locker before further optimization is discussed.

Thanks for clarification.
When I invesitgated JDK-8269423, I also thought good/bad mask changing might be the reason to keep gc locker at MarkStart.

But after further investigation, it seems to me that for GetXxxCritical it's OK to remove gc locker at MarkStart.
The reasons are:
1. GetXxxCritical returns the native address, and whether good or bad these addresses are valid address for native code (am I right here?), unless it's relocated later at Relocate.
2. The gc locker in RelocateStart will block until ReleaseXxxCritical, so gc locker in RelocateStart ensures the native address retrieved from GetXxxCritical to be valid.

Please kindly correct my comments above.

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

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


From yyang at openjdk.java.net  Thu Jul  1 01:43:07 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 1 Jul 2021 01:43:07 GMT
Subject: Integrated: 8266746: C1: Replace UnsafeGetRaw with UnsafeGet when
 setting up OSR entry block
In-Reply-To: <vS4aAz7ZBRUqD1q2ccfgAAXzyS7_oDubhQsmVK8kNQQ=.792302b2-036e-403b-8715-ef62f7a81f19@github.com>
References: <vS4aAz7ZBRUqD1q2ccfgAAXzyS7_oDubhQsmVK8kNQQ=.792302b2-036e-403b-8715-ef62f7a81f19@github.com>
Message-ID: <ukGLfFODQ_0ztx-xpGNYvtVEdbTw_TdXhIAJw6AJtQc=.8b3ae2a1-37d9-423d-9207-fc2d2ec3c3f2@github.com>

On Fri, 7 May 2021 14:41:43 GMT, Yi Yang <yyang at openjdk.org> wrote:

> After JDK-8150921, most Unsafe{Get,Put}Raw intrinsic methods can be replaced by Unsafe{Get,Put}Object.
> 
> There is the only one occurrence where c1 refers UnsafeGetRaw among GraphBuilder::setup_osr_entry_block()
> 
> https://github.com/openjdk/jdk/blob/74fecc070a6462e6a2d061525b53a63de15339f9/src/hotspot/share/c1/c1_GraphBuilder.cpp#L3143-L3157
> 
> We can replace UnsafeGetRaw with UnsafeGetObject when setting up OSR entry block. After that, Unsafe{Get,Put}Raw can be completely removed  because no one refers to them.
> 
> (This patch actually does two things:
> 1. `Replace UnsafeGetRaw with UnsafeGetObject when setting up OSR entry block` This is the only occurrence where c1 refers UnsafeGetRaw
> 2. `Cleanup unused Unsafe{Get,Put}Raw code`
> They are related so I put it together, but I still want to hear your suggestions, I will separate them into two patches if you think it is more reasonable)
> 
> Thanks!
> Yang

This pull request has now been integrated.

Changeset: d89e630c
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d89e630cdf05d4ddd07893fa8fe90c32a7eb5433
Stats:     690 lines in 15 files changed: 24 ins; 535 del; 131 mod

8266746: C1: Replace UnsafeGetRaw with UnsafeGet when setting up OSR entry block

Replace UnsafeGetRaw with UnsafeGetObject when setting up OSR entry block, and rename Unsafe{Get,Put}Object to Unsafe{Get,Put}

Reviewed-by: thartmann, dlong, mdoerr

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

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


From mli at openjdk.java.net  Thu Jul  1 07:40:10 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 1 Jul 2021 07:40:10 GMT
Subject: RFR: JDK-8269110: ZGC: Remove dead code in zBarrier
Message-ID: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>

this is a trivial cleanup to remove some dead code in zBarrier.

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

Commit messages:
 - remove dead code in zBarrier

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

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


From ayang at openjdk.java.net  Thu Jul  1 08:01:04 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 1 Jul 2021 08:01:04 GMT
Subject: Integrated: 8133873: Simplify {Register,Unregister}NMethodOopClosure
In-Reply-To: <O4O4HUzoBMTb19GKeQjw-rT47zWJ9BB5M5Tmc7ST7Cg=.a66f4f96-ad5a-4b2b-b0fc-738a60b9426c@github.com>
References: <O4O4HUzoBMTb19GKeQjw-rT47zWJ9BB5M5Tmc7ST7Cg=.a66f4f96-ad5a-4b2b-b0fc-738a60b9426c@github.com>
Message-ID: <wWU9psHoKA9uf4k-omuVNOF0XIj-B_eVEHNBndgGrqE=.ac725d97-eb88-499f-b85f-81ce129a42c7@github.com>

On Wed, 30 Jun 2021 08:08:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of excluding compressed oops in nmethod closures.

This pull request has now been integrated.

Changeset: 54a9c3e3
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/54a9c3e39fedf7eb0277c602c3767af654371c47
Stats:     24 lines in 1 file changed: 8 ins; 10 del; 6 mod

8133873: Simplify {Register,Unregister}NMethodOopClosure

Reviewed-by: tschatzl, kbarrett

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

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


From ayang at openjdk.java.net  Thu Jul  1 08:01:03 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 1 Jul 2021 08:01:03 GMT
Subject: RFR: 8133873: Simplify {Register,
 Unregister}NMethodOopClosure [v2]
In-Reply-To: <bwUdnr5XkSqkN88Np2eZNTkDRrMqiwedQ5Oz6qP2yBI=.5da88022-b0ba-410b-a26b-c49ae821be2a@github.com>
References: <O4O4HUzoBMTb19GKeQjw-rT47zWJ9BB5M5Tmc7ST7Cg=.a66f4f96-ad5a-4b2b-b0fc-738a60b9426c@github.com>
 <bwUdnr5XkSqkN88Np2eZNTkDRrMqiwedQ5Oz6qP2yBI=.5da88022-b0ba-410b-a26b-c49ae821be2a@github.com>
Message-ID: <tbwIcBA2YLSfiCXmtj6ms52BGIJcsL37S89Nqe4T5vc=.54e308a2-fdf3-4dc0-92b6-9b5ea21a3d48@github.com>

On Wed, 30 Jun 2021 13:41:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of excluding compressed oops in nmethod closures.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore assert

Thanks for the review.

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

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


From pliden at openjdk.java.net  Thu Jul  1 08:22:00 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 1 Jul 2021 08:22:00 GMT
Subject: RFR: JDK-8269651: ZGC: Optimize away gc locker in mark start
In-Reply-To: <TUqxaZXjpB_qQx1KW3DoUspBoASV1zYcT6495Beva74=.06889c49-d0b3-4e74-a526-a4bab6203dc7@github.com>
References: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
 <TUqxaZXjpB_qQx1KW3DoUspBoASV1zYcT6495Beva74=.06889c49-d0b3-4e74-a526-a4bab6203dc7@github.com>
Message-ID: <RhTt7WxThks1numhk1qhQRdwd_VREnGZnimFBb8MyeM=.cc58bb53-3da7-433c-83a9-b7f8bd58273b@github.com>

On Thu, 1 Jul 2021 01:38:05 GMT, Hamlin Li <mli at openjdk.org> wrote:

> GetXxxCritical returns the native address, and whether good or bad these addresses are valid address for native code (am I right here?), unless it's relocated later at Relocate.

We currently have the invariant that all accesses must go through the currently good heap view. While you can "cheat" and access objects through a bad heap view that will only work as long as you don't enable -XX:+ZVerifyViews, which will enforce this invariant. ZVerifyViews unmaps memory that isn't currently in the good heap view. It's a valuable debugging option to catch bad accesses, like when a load barrier is missing. ZVerifyViews is disabled by default because it's expensive.

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

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


From mli at openjdk.java.net  Thu Jul  1 08:54:02 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 1 Jul 2021 08:54:02 GMT
Subject: RFR: JDK-8269651: ZGC: Optimize away gc locker in mark start
In-Reply-To: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
References: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
Message-ID: <Gl_4jIhEWdzF1kKh-tLBYl82H99X0geBOOrf2wk2h4I=.2bae7116-d676-4a8c-87fc-6299ecc4b55b@github.com>

On Wed, 30 Jun 2021 11:58:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, ZGC involves gc locker in mark-start and relocate-start.
> It seems gc locker in mark-start is not necessary anymore.
> This is to remove this unnecessary(??) gc locker before further optimization is discussed.

I see, Thanks for clarification!

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

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


From mli at openjdk.java.net  Thu Jul  1 09:29:13 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Thu, 1 Jul 2021 09:29:13 GMT
Subject: RFR: JDK-8269423: ZGC: Support pinned Object and remove/simplify
 GCLocker usage in ZGC
Message-ID: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>

This PR is not an real intention to push current implementation, and current implementation does not support ZVerifyViews (which was pointed out by Per at https://github.com/openjdk/jdk/pull/4638#issuecomment-872033165).

Let's see if this solution is feasible and how to support ZVerifyViews efficiently.

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

Commit messages:
 - ZGC supports obj pinning

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

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


From tschatzl at openjdk.java.net  Thu Jul  1 10:07:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 1 Jul 2021 10:07:02 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying
In-Reply-To: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
Message-ID: <0-HIko0r6V9U948fYK2_83gjmGvATTZCbF9HfyEcwPI=.89b9fc8c-be4c-414b-90fb-77acafedc7bc@github.com>

On Tue, 29 Jun 2021 14:58:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.

Would it be useful to only call the soft ref policy setup via `setup_policy()` when it is (potentially) set to `true`? I.e. only during full gc, and call `setup_policy(false)` afterwards, maybe with a scope object?
This would remove the unnecessary calls with `false` as argument completely in the places where we never actually change it (e.g. for the G1 concurrent mark ref processor), and emphasize for the stw full gc collectors that they are the only ones eventually change it to "always clearing".

Also the sequence

reference_processor()->enable_discovery();
reference_processor()->setup_policy(<some value>);

should be merged into a single call as there are like five places now where both are called one after another.

In `psParallelCompact.cpp`, the `marked_for_unloading` local right after these calls could be removed too, it's unused.

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

Changes requested by tschatzl (Reviewer).

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


From pliden at openjdk.java.net  Thu Jul  1 10:48:02 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 1 Jul 2021 10:48:02 GMT
Subject: RFR: JDK-8269110: ZGC: Remove dead code in zBarrier
In-Reply-To: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
References: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
Message-ID: <YdDnS9Ar3RoEYsOHthn0BwldSC6G_x9t_LU4RPhT6mc=.ce8cb504-6cf9-4bc9-8dee-68ca0cb886e1@github.com>

On Thu, 1 Jul 2021 07:32:17 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is a trivial cleanup to remove some dead code in zBarrier.

Change looks good. However, note that the title of a PR shouldn't start with `JDK-`. I'm a bit surprised that the Skara bot hasn't complained about and/or auto-corrected that.

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

Marked as reviewed by pliden (Reviewer).

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


From pliden at openjdk.java.net  Thu Jul  1 11:56:59 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 1 Jul 2021 11:56:59 GMT
Subject: RFR: JDK-8269110: ZGC: Remove dead code in zBarrier
In-Reply-To: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
References: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
Message-ID: <iuCZYjTBdn4Y4l9pBhDgIEDgGGEu_Ctk4zCbFM6YAxU=.76271b10-b6db-45a5-9295-6c07bb93a976@github.com>

On Thu, 1 Jul 2021 07:32:17 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is a trivial cleanup to remove some dead code in zBarrier.

Ok, so it looks like the bot reformated the commit message correctly anyway.

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

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


From ayang at openjdk.java.net  Thu Jul  1 12:46:24 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 1 Jul 2021 12:46:24 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying [v2]
In-Reply-To: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
Message-ID: <Hpjn-WlNbp-Z2_6qhDa2BO2X0O6Rqdox0OXU6wn51Ck=.9e2bf418-5d91-4933-be64-419470f6fdc1@github.com>

> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.

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

  start_discovery

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4624/files
  - new: https://git.openjdk.java.net/jdk/pull/4624/files/f13bed4b..ca0e71eb

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

  Stats: 27 lines in 7 files changed: 6 ins; 12 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4624.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4624/head:pull/4624

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


From ayang at openjdk.java.net  Thu Jul  1 12:46:24 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 1 Jul 2021 12:46:24 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying
In-Reply-To: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
Message-ID: <Ep5csLJWM64uowtNwzhL73jgN6UN97I4qn_7MYzvJRY=.66c9cfc6-11b9-4539-a2f6-8df2f0a9a71d@github.com>

On Tue, 29 Jun 2021 14:58:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.

Merged `enable_discovery` and `setup_policy` into one call, and made `setup_policy` private.

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

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


From pliden at openjdk.java.net  Thu Jul  1 13:01:04 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Thu, 1 Jul 2021 13:01:04 GMT
Subject: RFR: JDK-8269423: ZGC: Support pinned Object and remove/simplify
 GCLocker usage in ZGC
In-Reply-To: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>
References: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>
Message-ID: <aBRODrLzz9CvndCzeI0BRan46Th9NG0A6kscsPtfWIA=.6ca161ec-e942-43f8-89e2-2126c5cc3228@github.com>

On Thu, 1 Jul 2021 09:21:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This PR is not an real intention to push current implementation, and current implementation does not support ZVerifyViews (which was pointed out by Per at https://github.com/openjdk/jdk/pull/4638#issuecomment-872033165).
> 
> Let's see if this solution is feasible and how to support ZVerifyViews efficiently.

I suggest we close this PR for now and revisit this once we have the generational work in place, since that might open up some doors for this.

One thing to also keep in mind is that ZGC is less affected by the GC locker than an STW collector is, since all the GC locker does is potentially delaying the start of the marking and relocation phases. In a STW collector context it typically also blocks allocations from happening, which isn't the case in ZGC. So, I am a bit curious if you have actually seen GC locker related problems with ZGC?

Finally, just a quick comment on the code. I see you moved the installation of the relocation set and the setup of forwarding tables into `ZHeap::relocate_start()`. This means this will now be executed in a STW pause, which is not an option as those operations can be quite expensive and are not O(1).

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

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


From tschatzl at openjdk.java.net  Thu Jul  1 15:34:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 1 Jul 2021 15:34:56 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying [v2]
In-Reply-To: <Hpjn-WlNbp-Z2_6qhDa2BO2X0O6Rqdox0OXU6wn51Ck=.9e2bf418-5d91-4933-be64-419470f6fdc1@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
 <Hpjn-WlNbp-Z2_6qhDa2BO2X0O6Rqdox0OXU6wn51Ck=.9e2bf418-5d91-4933-be64-419470f6fdc1@github.com>
Message-ID: <IzWUXIOLqHCYpmZKKv8pIF6X9lvhOYK9jLXWqZtNFQI=.6225062b-f6bb-41d2-849d-61b273055784@github.com>

On Thu, 1 Jul 2021 12:46:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   start_discovery

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From kbarrett at openjdk.java.net  Thu Jul  1 16:02:20 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 16:02:20 GMT
Subject: [jdk17] RFR: 8260684:
 vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed
 out [v2]
In-Reply-To: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
References: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
Message-ID: <oCZrK2nCVxpL0HNZQ3qQxLf8q5y8QAiPWjl61s3uq7c=.e143ad28-ecdd-4adf-a3bf-caef271f5b76@github.com>

> Please review this fix of
> vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java to
> eliminate races that can lead to the test occasionally timing out.
> 
> When the referent being tested by a particular iteration is a finalizable
> class, the test invoked eatMemory() repeatedly until the referent's
> finalize() function set a flag.  Then, whether the referent is finalizable
> or not, there is a call to eatMemory() to cause the phantom reference to be
> cleared and notified.  The testing thread then proceeds to wait for the
> reference to be notified.
> 
> This has a problem with ZGC.  One collection made the referent finalizable.
> Reference processing and finalization will end up ensuring it will survive
> the following collection.  If the post-finalization eatMemory() is that next
> collection, then it won't clear and notify the associated PhantomReference.
> Usually that doesn't cause a problem because the referent will be reclaimed
> by some other thread's later call to eatMemory().  But if the test is done
> and terminating, there won't be a later GC, and the wait for notification
> will block until the test times out.
> 
> There are other, rarer, scenarios with various collectors that could lead to
> similar timeouts, but the one described above is "relatively" likely.
> 
> While investigating this issue I did a bunch of code cleanup (for example,
> there was some really badly formatted code), refactoring, and commenting.
> As a result, a large fraction of the test has changed, though mostly in ways
> that don't affect it's function.  The first of the two commits in the PR is
> a whitespace-only cleanup.  Excluding it may make reviewing easier.
> 
> Testing:
> Ran the phantom002 test a couple thousand times.
> 
> Using a modified version of the test, verified that the described problem
> case actually occurs, on the order of 1% of the time.

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

  remove stray whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/142/files
  - new: https://git.openjdk.java.net/jdk17/pull/142/files/5238beca..12b9c7e8

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

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

PR: https://git.openjdk.java.net/jdk17/pull/142


From kbarrett at openjdk.java.net  Thu Jul  1 16:12:35 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 16:12:35 GMT
Subject: [jdk17] RFR: 8260684:
 vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed
 out [v3]
In-Reply-To: <g6s3H_jwaE0nALQxUvl3LavGsgUbGrkbkS66ay755HE=.d6166211-75a0-43a5-9a55-816f69cbe09b@github.com>
References: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
 <g6s3H_jwaE0nALQxUvl3LavGsgUbGrkbkS66ay755HE=.d6166211-75a0-43a5-9a55-816f69cbe09b@github.com>
Message-ID: <x7Cb8z2lTzxGJG41o_Y11LFt2SaeNdnLUxD_vKprNGY=.23022b7e-a132-4a69-86e0-e6111b6809bc@github.com>

On Wed, 30 Jun 2021 21:23:17 GMT, Leo Korinth <lkorinth 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 phantom_bug
>>  - remove stray whitespace
>>  - refactor and fix
>>  - fix indentation
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java line 130:
> 
>> 128:             GarbageUtils.eatMemory(getExecutionController(),
>> 129:                                    garbageProducer,
>> 130:                                    initialFactor , 10, 0);
> 
> remove space before comma

Done.

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

PR: https://git.openjdk.java.net/jdk17/pull/142


From kbarrett at openjdk.java.net  Thu Jul  1 16:12:36 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 16:12:36 GMT
Subject: [jdk17] Integrated: 8260684:
 vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed
 out
In-Reply-To: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
References: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
Message-ID: <J4NdwwcFvk2BkBBmTTmKW_ZwI8uiUGUyFfC3ai69ddk=.7b07a038-764e-459c-86a1-faae770f53fc@github.com>

On Thu, 24 Jun 2021 20:57:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of
> vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java to
> eliminate races that can lead to the test occasionally timing out.
> 
> When the referent being tested by a particular iteration is a finalizable
> class, the test invoked eatMemory() repeatedly until the referent's
> finalize() function set a flag.  Then, whether the referent is finalizable
> or not, there is a call to eatMemory() to cause the phantom reference to be
> cleared and notified.  The testing thread then proceeds to wait for the
> reference to be notified.
> 
> This has a problem with ZGC.  One collection made the referent finalizable.
> Reference processing and finalization will end up ensuring it will survive
> the following collection.  If the post-finalization eatMemory() is that next
> collection, then it won't clear and notify the associated PhantomReference.
> Usually that doesn't cause a problem because the referent will be reclaimed
> by some other thread's later call to eatMemory().  But if the test is done
> and terminating, there won't be a later GC, and the wait for notification
> will block until the test times out.
> 
> There are other, rarer, scenarios with various collectors that could lead to
> similar timeouts, but the one described above is "relatively" likely.
> 
> While investigating this issue I did a bunch of code cleanup (for example,
> there was some really badly formatted code), refactoring, and commenting.
> As a result, a large fraction of the test has changed, though mostly in ways
> that don't affect it's function.  The first of the two commits in the PR is
> a whitespace-only cleanup.  Excluding it may make reviewing easier.
> 
> Testing:
> Ran the phantom002 test a couple thousand times.
> 
> Using a modified version of the test, verified that the described problem
> case actually occurs, on the order of 1% of the time.

This pull request has now been integrated.

Changeset: 6c76e771
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6c76e771580815c7999b2f5cd633659be99ce4a0
Stats:     95 lines in 1 file changed: 58 ins; 11 del; 26 mod

8260684: vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out

Reviewed-by: pliden, lkorinth

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

PR: https://git.openjdk.java.net/jdk17/pull/142


From kbarrett at openjdk.java.net  Thu Jul  1 16:12:27 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 16:12:27 GMT
Subject: [jdk17] RFR: 8260684:
 vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed
 out [v3]
In-Reply-To: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
References: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
Message-ID: <ADIetiIzKidabVp6oNsv5QasumPwXs9CYu-dwgHUPjw=.28171c6f-228b-4725-8910-51cc64299426@github.com>

> Please review this fix of
> vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java to
> eliminate races that can lead to the test occasionally timing out.
> 
> When the referent being tested by a particular iteration is a finalizable
> class, the test invoked eatMemory() repeatedly until the referent's
> finalize() function set a flag.  Then, whether the referent is finalizable
> or not, there is a call to eatMemory() to cause the phantom reference to be
> cleared and notified.  The testing thread then proceeds to wait for the
> reference to be notified.
> 
> This has a problem with ZGC.  One collection made the referent finalizable.
> Reference processing and finalization will end up ensuring it will survive
> the following collection.  If the post-finalization eatMemory() is that next
> collection, then it won't clear and notify the associated PhantomReference.
> Usually that doesn't cause a problem because the referent will be reclaimed
> by some other thread's later call to eatMemory().  But if the test is done
> and terminating, there won't be a later GC, and the wait for notification
> will block until the test times out.
> 
> There are other, rarer, scenarios with various collectors that could lead to
> similar timeouts, but the one described above is "relatively" likely.
> 
> While investigating this issue I did a bunch of code cleanup (for example,
> there was some really badly formatted code), refactoring, and commenting.
> As a result, a large fraction of the test has changed, though mostly in ways
> that don't affect it's function.  The first of the two commits in the PR is
> a whitespace-only cleanup.  Excluding it may make reviewing easier.
> 
> Testing:
> Ran the phantom002 test a couple thousand times.
> 
> Using a modified version of the test, verified that the described problem
> case actually occurs, on the order of 1% of the time.

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 phantom_bug
 - remove stray whitespace
 - refactor and fix
 - fix indentation

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/142/files
  - new: https://git.openjdk.java.net/jdk17/pull/142/files/12b9c7e8..9c53bb66

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

  Stats: 3117 lines in 106 files changed: 2463 ins; 388 del; 266 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/142.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/142/head:pull/142

PR: https://git.openjdk.java.net/jdk17/pull/142


From kbarrett at openjdk.java.net  Thu Jul  1 16:12:29 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Jul 2021 16:12:29 GMT
Subject: [jdk17] RFR: 8260684:
 vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed
 out [v3]
In-Reply-To: <VhcdP6MyHfj3msOQqFuXNI-Am5SqEftciGe4Pai9wek=.26a3202a-4d81-44a2-bfa8-500ad1a6a75d@github.com>
References: <KmFSveB9df8WPy3CX62gZ07iowmCJnmzkgBodlC-TKU=.d1678a36-e85d-4cc5-9fd3-f6c2a1c4f67f@github.com>
 <VhcdP6MyHfj3msOQqFuXNI-Am5SqEftciGe4Pai9wek=.26a3202a-4d81-44a2-bfa8-500ad1a6a75d@github.com>
Message-ID: <WbzeHmIPAmxonE3BlTpUbJe3TruongJsfGNSykOB8zw=.514add65-4993-46fb-b8a5-aae75050336a@github.com>

On Tue, 29 Jun 2021 12:34:44 GMT, Per Liden <pliden 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 phantom_bug
>>  - remove stray whitespace
>>  - refactor and fix
>>  - fix indentation
>
> Looks good.

Thanks for reviews @pliden and @lkorinth

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

PR: https://git.openjdk.java.net/jdk17/pull/142


From ayang at openjdk.java.net  Thu Jul  1 16:37:28 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 1 Jul 2021 16:37:28 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying [v2]
In-Reply-To: <Hpjn-WlNbp-Z2_6qhDa2BO2X0O6Rqdox0OXU6wn51Ck=.9e2bf418-5d91-4933-be64-419470f6fdc1@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
 <Hpjn-WlNbp-Z2_6qhDa2BO2X0O6Rqdox0OXU6wn51Ck=.9e2bf418-5d91-4933-be64-419470f6fdc1@github.com>
Message-ID: <yYHaw7toCHER8dLOq_MtkpwghGUgFD5qinA5IWcmgME=.4b8a52b1-978e-4115-9f53-c028b4f52431@github.com>

On Thu, 1 Jul 2021 12:46:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   start_discovery

I accidentally removed a call to `disable_discovery();` in `genCollectedHeap.cpp`. Restored in the latest commit.

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

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


From ayang at openjdk.java.net  Thu Jul  1 16:37:27 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 1 Jul 2021 16:37:27 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying [v3]
In-Reply-To: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
Message-ID: <hUg76SjMVGwKTIVzzla9URtFmizvmeBn3p5ovmG8d9o=.3a94157f-b6f3-4751-89d0-77efc6af5839@github.com>

> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.

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

  restore

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4624/files
  - new: https://git.openjdk.java.net/jdk/pull/4624/files/ca0e71eb..6ba25591

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

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

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


From duke at openjdk.java.net  Thu Jul  1 22:15:03 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 1 Jul 2021 22:15:03 GMT
Subject: Withdrawn: 8266422: GC ergo tests should not write cores
In-Reply-To: <om5VExGjc9A0cR8Ug1ShDxCGDMO_6QJsTpepYPcz3Yc=.6f15a327-03b8-46f6-be78-6c906c1aa342@github.com>
References: <om5VExGjc9A0cR8Ug1ShDxCGDMO_6QJsTpepYPcz3Yc=.6f15a327-03b8-46f6-be78-6c906c1aa342@github.com>
Message-ID: <Y5hHuFPhelrrPqVep290xNeNpAVCxf3gQFKdppiOwNY=.9413ccc4-2c05-4960-b8ae-774794574205@github.com>

On Mon, 3 May 2021 07:28:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> unrelated crashes in GC tests showed timeouts and large core files on AIX, which unfortunately has no concept of committing memory - reserved memory counts toward the commit charge right away and hence are reflected in core file size.
> 
> Therefore I would like to run these tests without cores. Note that it is not my intention to fix up all potential tests which do this, which would be a much larger task, or would require a change at a lower layer (e.g. always pass -CreateCoredumpOnCrash to createJavaProcessBuilder).
> 
> Thanks, Thomas

This pull request has been closed without being integrated.

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

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


From mli at openjdk.java.net  Fri Jul  2 01:34:02 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 2 Jul 2021 01:34:02 GMT
Subject: RFR: JDK-8269110: ZGC: Remove dead code in zBarrier
In-Reply-To: <iuCZYjTBdn4Y4l9pBhDgIEDgGGEu_Ctk4zCbFM6YAxU=.76271b10-b6db-45a5-9295-6c07bb93a976@github.com>
References: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
 <iuCZYjTBdn4Y4l9pBhDgIEDgGGEu_Ctk4zCbFM6YAxU=.76271b10-b6db-45a5-9295-6c07bb93a976@github.com>
Message-ID: <QhczjLmCXR9eku-x9a8aN2dZA3-LVClT4XC7xWfHfDo=.1d8b4e8b-5a5d-4f6b-b5e7-d905b909011a@github.com>

On Thu, 1 Jul 2021 11:54:30 GMT, Per Liden <pliden at openjdk.org> wrote:

>> this is a trivial cleanup to remove some dead code in zBarrier.
>
> Ok, so it looks like the bot reformated the commit message correctly anyway.

Thanks @pliden for review and comment, I'll use the correct PR title in the future.

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

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


From mli at openjdk.java.net  Fri Jul  2 01:34:03 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 2 Jul 2021 01:34:03 GMT
Subject: Integrated: JDK-8269110: ZGC: Remove dead code in zBarrier
In-Reply-To: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
References: <Ql_l0er0YzLe8lj2KF8o6ReooD_Ub1kNUK49Ntzqfec=.3615ddd8-d2a2-4b7b-ba6f-5e3ce73a5221@github.com>
Message-ID: <T4b1RO7Y-PPL1P8-_p1KrsBw9wgFz_oq3SyZsGIZuo0=.beac537c-9dc5-4ed5-8e89-765dc3086c07@github.com>

On Thu, 1 Jul 2021 07:32:17 GMT, Hamlin Li <mli at openjdk.org> wrote:

> this is a trivial cleanup to remove some dead code in zBarrier.

This pull request has now been integrated.

Changeset: 589f0841
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/589f084161645ee513ffcfbbbcd56c0f0cd98ade
Stats:     13 lines in 2 files changed: 0 ins; 13 del; 0 mod

8269110: ZGC: Remove dead code in zBarrier

Reviewed-by: pliden

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

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


From mli at openjdk.java.net  Fri Jul  2 01:39:06 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 2 Jul 2021 01:39:06 GMT
Subject: RFR: JDK-8269423: ZGC: Support pinned Object and remove/simplify
 GCLocker usage in ZGC
In-Reply-To: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>
References: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>
Message-ID: <RMTbzzOVdJTuODX58NvVZmNiltkOfH6vsIFDhxN1p4k=.3df94db8-7b72-4b26-9903-53dff224ac1d@github.com>

On Thu, 1 Jul 2021 09:21:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This PR is not an real intention to push current implementation, and current implementation does not support ZVerifyViews (which was pointed out by Per at https://github.com/openjdk/jdk/pull/4638#issuecomment-872033165).
> 
> Let's see if this solution is feasible and how to support ZVerifyViews efficiently.

I see your points, thanks for the deailed comments!
I'm OK to close the PR for now, and will come back then to investigate the issue to see if there will be better solution.

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

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


From mli at openjdk.java.net  Fri Jul  2 01:39:06 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 2 Jul 2021 01:39:06 GMT
Subject: Withdrawn: JDK-8269423: ZGC: Support pinned Object and
 remove/simplify GCLocker usage in ZGC
In-Reply-To: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>
References: <tMAWnKXyY-YCvhH158BAtCY7_QfKwTAyv4vBidd5uNw=.6cfdad00-cd2f-421a-984f-008b29d03403@github.com>
Message-ID: <5Giwa-xldri9sJZl8cMg39spH5tU55e6OR-eETjMbro=.a71b6353-c827-4f33-8de4-dda16a1576bd@github.com>

On Thu, 1 Jul 2021 09:21:33 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This PR is not an real intention to push current implementation, and current implementation does not support ZVerifyViews (which was pointed out by Per at https://github.com/openjdk/jdk/pull/4638#issuecomment-872033165).
> 
> Let's see if this solution is feasible and how to support ZVerifyViews efficiently.

This pull request has been closed without being integrated.

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

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


From mli at openjdk.java.net  Fri Jul  2 01:47:01 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 2 Jul 2021 01:47:01 GMT
Subject: Withdrawn: JDK-8269651: ZGC: Optimize away gc locker in mark start
In-Reply-To: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
References: <9V_WWyLoW4HTawdfVy-87KYwIWKJBL0_A-WIgyGn-m4=.853df81d-22bf-4fc9-991d-88314a138fc5@github.com>
Message-ID: <rTPLI1nBlpw_pin_tsvIgaQqOOyf6smmK7LCIB3IdMY=.82c93c4f-557e-4f4e-9d3d-cc1472561815@github.com>

On Wed, 30 Jun 2021 11:58:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Currently, ZGC involves gc locker in mark-start and relocate-start.
> It seems gc locker in mark-start is not necessary anymore.
> This is to remove this unnecessary(??) gc locker before further optimization is discussed.

This pull request has been closed without being integrated.

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

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


From kbarrett at openjdk.java.net  Fri Jul  2 08:24:06 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 2 Jul 2021 08:24:06 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying [v3]
In-Reply-To: <hUg76SjMVGwKTIVzzla9URtFmizvmeBn3p5ovmG8d9o=.3a94157f-b6f3-4751-89d0-77efc6af5839@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
 <hUg76SjMVGwKTIVzzla9URtFmizvmeBn3p5ovmG8d9o=.3a94157f-b6f3-4751-89d0-77efc6af5839@github.com>
Message-ID: <1_nbhhBI7eDN6vPYzFUi4N_yWH2ZHg6iKsikUU-3_kE=.0aa17db9-18a2-4f01-ab79-d8ef8857d93f@github.com>

On Thu, 1 Jul 2021 16:37:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Fri Jul  2 09:23:05 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 2 Jul 2021 09:23:05 GMT
Subject: RFR: 8269596: Snapshot soft ref policy before marking/copying [v3]
In-Reply-To: <hUg76SjMVGwKTIVzzla9URtFmizvmeBn3p5ovmG8d9o=.3a94157f-b6f3-4751-89d0-77efc6af5839@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
 <hUg76SjMVGwKTIVzzla9URtFmizvmeBn3p5ovmG8d9o=.3a94157f-b6f3-4751-89d0-77efc6af5839@github.com>
Message-ID: <c3CoQeWceokVNoNIxM_WEcg5-GvGJjdKqSSyYpGusNY=.64e07aa3-f570-4cc4-ae01-36502b2b1402@github.com>

On Thu, 1 Jul 2021 16:37:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore

Thanks for the review.

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

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


From ayang at openjdk.java.net  Fri Jul  2 09:23:05 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 2 Jul 2021 09:23:05 GMT
Subject: Integrated: 8269596: Snapshot soft ref policy before marking/copying
In-Reply-To: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
References: <ONZ1oHZhrnqcNR8YBd3fNSrzKf_PJ3dRZ42OS0oT1tQ=.25031da8-096f-4094-8ade-c4cc886e1dbb@github.com>
Message-ID: <uhjkykLxWbfM31lf8MDwhxHwNsqs5t-Smb70EFEuOt4=.7619b543-772f-4f6c-8b00-97276efff973@github.com>

On Tue, 29 Jun 2021 14:58:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Set up soft ref policy before marking/copying for Serial, Parallel and G1. With this change, all collectors do soft-ref policy setup in the beginning of a GC cycle.

This pull request has now been integrated.

Changeset: f8bcbf01
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f8bcbf0172af25ac17b110d22232bd618cfd621a
Stats:     46 lines in 11 files changed: 7 ins; 26 del; 13 mod

8269596: Snapshot soft ref policy before marking/copying

Reviewed-by: tschatzl, kbarrett

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

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


From ayang at openjdk.java.net  Fri Jul  2 11:06:18 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 2 Jul 2021 11:06:18 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery
Message-ID: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>

Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.

Test: hotspot_gc

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

Commit messages:
 - cm_discovery

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

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


From ayang at openjdk.java.net  Fri Jul  2 13:06:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 2 Jul 2021 13:06:14 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider
Message-ID: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>

This PR consists of 3 commits:

1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.

2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.

3. Rename phase{2,3,4} to phase{1,2,3}.

Test: hotspot_gc

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

Commit messages:
 - rename
 - clock
 - phase1

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

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


From tschatzl at openjdk.java.net  Fri Jul  2 15:24:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 2 Jul 2021 15:24:02 GMT
Subject: RFR: 8269821: Remove is-queue-active check in inner loop of
 write_ref_array_pre_work
Message-ID: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>

Hi all,

  can I have reviews for this small micro-optimization that removes unnecessary work in the innermost loop of  write_ref_array_pre_work()?

In particular it removes the superfluous check whether marking is active (already done at the top of the loop) and hoists out several other code that the compiler for some reason does not automatically hoist.

Testing: tier1

Thanks,
  Thomas

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

Commit messages:
 - Improve a bit
 - Improve write_ref_array_work

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

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


From dcubed at openjdk.java.net  Fri Jul  2 16:16:12 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 2 Jul 2021 16:16:12 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced
Message-ID: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>

This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
piece of history that I'm finally getting around to cleaning up. While this macro has
been with us for a long time, its time has passed...

Tested with Mach5 Tier[1-3].

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

Commit messages:
 - 8193559.cr0

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

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


From eosterlund at openjdk.java.net  Fri Jul  2 21:01:52 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 2 Jul 2021 21:01:52 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <H5l8N4rH0nIrtG9rtS0mAiVA4irRIEFONT-CZRUEzLk=.2ccef153-e257-49b2-9183-e6041fc33e8e@github.com>

On Fri, 2 Jul 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Goodbye ugly macro. You have served us well. Looks good Dan. Thanks for cleaning up.

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

Marked as reviewed by eosterlund (Reviewer).

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


From dcubed at openjdk.java.net  Fri Jul  2 21:12:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 2 Jul 2021 21:12:48 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced
In-Reply-To: <H5l8N4rH0nIrtG9rtS0mAiVA4irRIEFONT-CZRUEzLk=.2ccef153-e257-49b2-9183-e6041fc33e8e@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <H5l8N4rH0nIrtG9rtS0mAiVA4irRIEFONT-CZRUEzLk=.2ccef153-e257-49b2-9183-e6041fc33e8e@github.com>
Message-ID: <O5JC-DaJrwWp5ykuOC6IbFPqJI3M7bvX9Ysz8SMFsVM=.5b1702d0-e898-4d6b-8477-726a1f0be529@github.com>

On Fri, 2 Jul 2021 20:58:23 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Goodbye ugly macro. You have served us well. Looks good Dan. Thanks for cleaning up.

@fisk - Thanks for the review!

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

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


From ayang at openjdk.java.net  Fri Jul  2 21:27:54 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 2 Jul 2021 21:27:54 GMT
Subject: RFR: 8269821: Remove is-queue-active check in inner loop of
 write_ref_array_pre_work
In-Reply-To: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
References: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
Message-ID: <iMBNB1SNvqVeTPrLu2xrW7rCz0EympMHD5NVaYmKics=.64357b74-2863-4e0f-903e-8c8a593a2a8c@github.com>

On Fri, 2 Jul 2021 14:58:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this small micro-optimization that removes unnecessary work in the innermost loop of  write_ref_array_pre_work()?
> 
> In particular it removes the superfluous check whether marking is active (already done at the top of the loop) and hoists out several other code that the compiler for some reason does not automatically hoist.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Committer).

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

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


From kbarrett at openjdk.java.net  Fri Jul  2 21:41:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 2 Jul 2021 21:41:53 GMT
Subject: RFR: 8269821: Remove is-queue-active check in inner loop of
 write_ref_array_pre_work
In-Reply-To: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
References: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
Message-ID: <24v3MTWL7weIFc1-_hBCr5U-KvyadzoXq47-RD9zkeE=.cf924680-882f-40c5-87fa-3152daf6f3ce@github.com>

On Fri, 2 Jul 2021 14:58:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this small micro-optimization that removes unnecessary work in the innermost loop of  write_ref_array_pre_work()?
> 
> In particular it removes the superfluous check whether marking is active (already done at the top of the loop) and hoists out several other code that the compiler for some reason does not automatically hoist.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Fri Jul  2 21:45:48 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 2 Jul 2021 21:45:48 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <P_r9XwzON78jZ9hXZw24UhWWV-u1h4KQB-mrnIhTMVw=.4208714c-edcd-48ba-bed9-583dd15dedb0@github.com>

On Fri, 2 Jul 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Marked as reviewed by ayang (Committer).

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

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


From kbarrett at openjdk.java.net  Fri Jul  2 21:59:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 2 Jul 2021 21:59:52 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>

On Fri, 2 Jul 2021 16:03:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Changes requested by kbarrett (Reviewer).

src/hotspot/share/runtime/thread.cpp line 2470:

> 2468: 
> 2469:     JavaThreadPrefetchedIterator(ThreadsList* list) :
> 2470:       _list(list), _end(list->threads() + list->length()), _current(list->threads()) {}

I don't see any uses of the `_list` member.

src/hotspot/share/runtime/thread.cpp line 2484:

> 2482: 
> 2483: #define DO_JAVA_THREADS(LIST, X) \
> 2484:   for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = iter.current(); iter.next())

The condition is an implicit conversion to bool, which is disallowed
by the style guide.  In fact, it's a declaration, which is
specifically called out by the style guide.  When I revised the style
guide I made explicit mention of that usage because I'd tried to use
that sort of thing several years ago and got several complaints.  So
it's not that I personally think that usage is bad; rather, I was
hoping someone would take on the little project of convincing the team
it was good.  I don't have any objection to this part of the change.

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

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


From dcubed at openjdk.java.net  Sat Jul  3 03:40:12 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 3 Jul 2021 03:40:12 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  kbarrett CR - delete unused _list member.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4671/files
  - new: https://git.openjdk.java.net/jdk/pull/4671/files/3f653c53..5ee49914

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

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

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


From dcubed at openjdk.java.net  Sat Jul  3 03:40:13 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 3 Jul 2021 03:40:13 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <P_r9XwzON78jZ9hXZw24UhWWV-u1h4KQB-mrnIhTMVw=.4208714c-edcd-48ba-bed9-583dd15dedb0@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <P_r9XwzON78jZ9hXZw24UhWWV-u1h4KQB-mrnIhTMVw=.4208714c-edcd-48ba-bed9-583dd15dedb0@github.com>
Message-ID: <Spq-0ZVpKhWbwsyYO6aCaIqIs7PukuwMCY31KtTFTfs=.e42754b3-bfa6-465c-923d-e9f17436061e@github.com>

On Fri, 2 Jul 2021 21:43:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett CR - delete unused _list member.
>
> Marked as reviewed by ayang (Committer).

@albertnetymk - Thanks for the review!

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

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


From dcubed at openjdk.java.net  Sat Jul  3 03:40:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 3 Jul 2021 03:40:15 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>
 <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com>
Message-ID: <XWsJfMd3L1KajyMrPsvfNJMt4jU-XodlzbsAgmo0VZo=.bbc6b9b2-1d4e-4ffa-b6f1-f260569126fb@github.com>

On Fri, 2 Jul 2021 22:18:08 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 2470:
>> 
>>> 2468: 
>>> 2469:     JavaThreadPrefetchedIterator(ThreadsList* list) :
>>> 2470:       _list(list), _end(list->threads() + list->length()), _current(list->threads()) {}
>> 
>> I don't see any uses of the `_list` member.
>
> Nice catch. I don't see any either.

Fixed that.

>> src/hotspot/share/runtime/thread.cpp line 2484:
>> 
>>> 2482: 
>>> 2483: #define DO_JAVA_THREADS(LIST, X) \
>>> 2484:   for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = iter.current(); iter.next())
>> 
>> The condition is an implicit conversion to bool, which is disallowed
>> by the style guide.  In fact, it's a declaration, which is
>> specifically called out by the style guide.  When I revised the style
>> guide I made explicit mention of that usage because I'd tried to use
>> that sort of thing several years ago and got several complaints.  So
>> it's not that I personally think that usage is bad; rather, I was
>> hoping someone would take on the little project of convincing the team
>> it was good.  I don't have any objection to this part of the change.
>
> I'll take a look at fixing that.

I can't find a way to fix that without adding back some of the crazy things
in the original macro.

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

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


From dcubed at openjdk.java.net  Sat Jul  3 03:40:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 3 Jul 2021 03:40:15 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>
Message-ID: <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com>

On Fri, 2 Jul 2021 21:56:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett CR - delete unused _list member.
>
> src/hotspot/share/runtime/thread.cpp line 2470:
> 
>> 2468: 
>> 2469:     JavaThreadPrefetchedIterator(ThreadsList* list) :
>> 2470:       _list(list), _end(list->threads() + list->length()), _current(list->threads()) {}
> 
> I don't see any uses of the `_list` member.

Nice catch. I don't see any either.

> src/hotspot/share/runtime/thread.cpp line 2484:
> 
>> 2482: 
>> 2483: #define DO_JAVA_THREADS(LIST, X) \
>> 2484:   for (JavaThreadPrefetchedIterator iter(LIST); JavaThread* X = iter.current(); iter.next())
> 
> The condition is an implicit conversion to bool, which is disallowed
> by the style guide.  In fact, it's a declaration, which is
> specifically called out by the style guide.  When I revised the style
> guide I made explicit mention of that usage because I'd tried to use
> that sort of thing several years ago and got several complaints.  So
> it's not that I personally think that usage is bad; rather, I was
> hoping someone would take on the little project of convincing the team
> it was good.  I don't have any objection to this part of the change.

I'll take a look at fixing that.

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

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


From kbarrett at openjdk.java.net  Sat Jul  3 17:13:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 3 Jul 2021 17:13:52 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <XWsJfMd3L1KajyMrPsvfNJMt4jU-XodlzbsAgmo0VZo=.bbc6b9b2-1d4e-4ffa-b6f1-f260569126fb@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>
 <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com>
 <XWsJfMd3L1KajyMrPsvfNJMt4jU-XodlzbsAgmo0VZo=.bbc6b9b2-1d4e-4ffa-b6f1-f260569126fb@github.com>
Message-ID: <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com>

On Sat, 3 Jul 2021 03:33:51 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I'll take a look at fixing that.
>
> I can't find a way to fix that without adding back some of the crazy things
> in the original macro.

I wasn't expecting any change based on that comment, just pointing out that the code
*is* contrary to the style guide, in a place where I think the guide should be changed.

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

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


From kbarrett at openjdk.java.net  Sat Jul  3 17:21:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 3 Jul 2021 17:21:53 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
Message-ID: <BHt6qg4xf4lMYmdfnhzmHTHwlFve0Z7PCJgcKN-fc-4=.c30a1bd0-e4c1-43dc-b2c2-e934cfbc8474@github.com>

On Sat, 3 Jul 2021 03:40:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett CR - delete unused _list member.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From dholmes at openjdk.java.net  Sun Jul  4 12:25:55 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 4 Jul 2021 12:25:55 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>
 <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com>
 <XWsJfMd3L1KajyMrPsvfNJMt4jU-XodlzbsAgmo0VZo=.bbc6b9b2-1d4e-4ffa-b6f1-f260569126fb@github.com>
 <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com>
Message-ID: <z8qUzNyM7EP-VvWjZztm6HcxrQiS91gKOwn8gwZpeSo=.8fbaab53-dd7d-41bd-b78c-7920c4fe746b@github.com>

On Sat, 3 Jul 2021 17:11:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I can't find a way to fix that without adding back some of the crazy things
>> in the original macro.
>
> I wasn't expecting any change based on that comment, just pointing out that the code
> *is* contrary to the style guide, in a place where I think the guide should be changed.

I'm surprised that a declaration is even legal in that position - but then I should never be surprised at the crazy things C++ allows. :( I do think  it looks truly awful to have a declaration there. Surely we do not have to reduce this to being a single-line macro that emulates a for-loop? That said I can't make any sense out of the original macro so sure this is a less-ugly macro. But why does this have to be so obscure - aren't we just walking the current threads-list ??

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

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


From kbarrett at openjdk.java.net  Sun Jul  4 22:32:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 4 Jul 2021 22:32:59 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <z8qUzNyM7EP-VvWjZztm6HcxrQiS91gKOwn8gwZpeSo=.8fbaab53-dd7d-41bd-b78c-7920c4fe746b@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <dEb1TtUTnRZOzt_5zKBox3-zUoyPom79rICSJpk99yU=.1e0aeb2d-f1a2-41d1-b2c7-9ce3cacabe95@github.com>
 <3e_ySPWMRm6NSgmQkcdrr_upq-cw8H3lyFfS1yF2_4w=.4dfa82ef-fc62-4354-bab2-a657ce54f1ec@github.com>
 <XWsJfMd3L1KajyMrPsvfNJMt4jU-XodlzbsAgmo0VZo=.bbc6b9b2-1d4e-4ffa-b6f1-f260569126fb@github.com>
 <_QR2JVWXyT9p_PDGG10cLeRjYmN_J_6QnnqccgT2gfo=.d28f293b-ef8a-48d2-898a-f64809f8760e@github.com>
 <z8qUzNyM7EP-VvWjZztm6HcxrQiS91gKOwn8gwZpeSo=.8fbaab53-dd7d-41bd-b78c-7920c4fe746b@github.com>
Message-ID: <6H4AyrJIVrYLzRomzJ_g5Br_BBR3ziePOe0RFBAlqbc=.506b6994-ed67-4f38-bdf4-870e92f64b76@github.com>

On Sun, 4 Jul 2021 12:22:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I wasn't expecting any change based on that comment, just pointing out that the code
>> *is* contrary to the style guide, in a place where I think the guide should be changed.
>
> I'm surprised that a declaration is even legal in that position - but then I should never be surprised at the crazy things C++ allows. :( I do think  it looks truly awful to have a declaration there. Surely we do not have to reduce this to being a single-line macro that emulates a for-loop? That said I can't make any sense out of the original macro so sure this is a less-ugly macro. But why does this have to be so obscure - aren't we just walking the current threads-list ??

I failed to notice previously that the new macro introduces the "iter" variable into the body scope.  The old macro used naming conventions to avoid adding any "simple" names that could inadvertently affect the meaning of the code.

Thinking about David's reply, I'm also wondering if it might be possible to do better by making use of range-based for.  It would involve defining a compliant iterator rather than the JavaThreadPrefetchedIterator, but that's not very hard.  (And I can help with that.)  Doing so would really simplify the macro, or perhaps even render it so trivial as to not be worth using any more.

So I'm rescinding my approval of this change.

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

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


From kbarrett at openjdk.java.net  Sun Jul  4 22:32:58 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 4 Jul 2021 22:32:58 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
Message-ID: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com>

On Sat, 3 Jul 2021 03:40:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett CR - delete unused _list member.

Changes requested by kbarrett (Reviewer).

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

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


From kbarrett at openjdk.java.net  Mon Jul  5 07:05:57 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 5 Jul 2021 07:05:57 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
Message-ID: <Pe8s3uIg-bMPAeNc14f5jlZtpQSW14NuxppLChbGZRI=.9d056a0c-822c-4f20-b15e-ade4ff9743fc@github.com>

On Sat, 3 Jul 2021 03:40:12 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett CR - delete unused _list member.

src/hotspot/share/runtime/thread.cpp line 2464:

> 2462: }
> 2463: 
> 2464: struct JavaThreadPrefetchedIterator {

I think the only really important difference between this new iterator class
and the existing JavaThreadIterator and JavaThreadIteratorWithHandle is that
the prefetched iterator prefetches. It seems like if that's useful there
then it's probably useful for the other two as well. I think these could all
be collapsed down to one iterator over ThreadsList that is typically used
via range-based for.

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

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


From tschatzl at openjdk.java.net  Mon Jul  5 07:27:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 5 Jul 2021 07:27:52 GMT
Subject: Integrated: 8269821: Remove is-queue-active check in inner loop of
 write_ref_array_pre_work
In-Reply-To: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
References: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
Message-ID: <odcQpSyFrmkTB72jZf6xX-hj3wqer4MVUQM51mWja6o=.088de04f-574a-4ac5-b9ac-521224f69db0@github.com>

On Fri, 2 Jul 2021 14:58:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this small micro-optimization that removes unnecessary work in the innermost loop of  write_ref_array_pre_work()?
> 
> In particular it removes the superfluous check whether marking is active (already done at the top of the loop) and hoists out several other code that the compiler for some reason does not automatically hoist.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8269821: Remove is-queue-active check in inner loop of write_ref_array_pre_work

Reviewed-by: ayang, kbarrett

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

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


From tschatzl at openjdk.java.net  Mon Jul  5 07:27:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 5 Jul 2021 07:27:51 GMT
Subject: RFR: 8269821: Remove is-queue-active check in inner loop of
 write_ref_array_pre_work
In-Reply-To: <24v3MTWL7weIFc1-_hBCr5U-KvyadzoXq47-RD9zkeE=.cf924680-882f-40c5-87fa-3152daf6f3ce@github.com>
References: <yRq8a-fpwKi5xeOtBXOLDuuj5DlkGA1Erwr2x_mOaxw=.9de0a67c-98a1-47ee-82d9-7d0a8df28e9c@github.com>
 <24v3MTWL7weIFc1-_hBCr5U-KvyadzoXq47-RD9zkeE=.cf924680-882f-40c5-87fa-3152daf6f3ce@github.com>
Message-ID: <IEK5uTpJcGI9yUu6bDc3TAay0m1VZX7Ovamb_nq3LdY=.7c2482ae-5890-43dc-b828-17600931e165@github.com>

On Fri, 2 Jul 2021 21:38:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this small micro-optimization that removes unnecessary work in the innermost loop of  write_ref_array_pre_work()?
>> 
>> In particular it removes the superfluous check whether marking is active (already done at the top of the loop) and hoists out several other code that the compiler for some reason does not automatically hoist.
>> 
>> Testing: tier1
>> 
>> Thanks,
>>   Thomas
>
> Looks good.

Thanks @kimbarrett @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Jul  5 09:34:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 5 Jul 2021 09:34:50 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery
In-Reply-To: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
Message-ID: <Op_ytJfprSsgRBmnM6Tm9ZJVw_aBRlD7uZUiVQc1vEY=.9a32c2fd-409d-4fc3-9bad-46e37aabd0e9@github.com>

On Fri, 2 Jul 2021 11:00:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
> 
> Test: hotspot_gc

I think the comment beginning `g1CollectedHeap.hpp:929` should be adapted too.

Looks good otherwise.

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

Changes requested by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jul  5 11:59:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 5 Jul 2021 11:59:22 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v4]
In-Reply-To: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
Message-ID: <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>

> Hi all,
> 
>   can I have reviews for this change that puts the evacuation failure marker from a separate log line into the GC timing message. I.e. instead of
> 
> 
> Pause Young (Normal) (G1 Evacuation Pause)
> To-space exhausted
> 
> into
> 
> 
> Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause) 
> 
> 
> This is imho easier to read, better to process and less wasteful with log space.
> 
> Testing: tier1, gc/g1 tests

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

  Fix G1AllowPreventiveGC -> G1UsePreventiveGC

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4539/files
  - new: https://git.openjdk.java.net/jdk/pull/4539/files/004c0a9c..90ca1244

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

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

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


From duke at openjdk.java.net  Tue Jul  6 01:36:57 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 6 Jul 2021 01:36:57 GMT
Subject: Withdrawn: 8266744: Make AbstractGangTask stack-allocatable only
In-Reply-To: <7LmLJTgczCvKoYRBOgmadnxpOdpOlvM-7DoPDFMsxw0=.c3f12435-94e0-4727-81ae-65b83f4ed032@github.com>
References: <7LmLJTgczCvKoYRBOgmadnxpOdpOlvM-7DoPDFMsxw0=.c3f12435-94e0-4727-81ae-65b83f4ed032@github.com>
Message-ID: <SyJ6kf8wTEkZ5yHDXFGIPTiLZTCp0gM0ArcvhirHx44=.db88221c-e6c5-45e6-b381-8ee22b045ba1@github.com>

On Fri, 7 May 2021 14:44:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Remove the inheritance relation in `class AbstractGangTask : public CHeapObj<mtInternal>`, and export necessary classes.

This pull request has been closed without being integrated.

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

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


From kbarrett at openjdk.java.net  Tue Jul  6 08:01:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 6 Jul 2021 08:01:50 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery
In-Reply-To: <Op_ytJfprSsgRBmnM6Tm9ZJVw_aBRlD7uZUiVQc1vEY=.9a32c2fd-409d-4fc3-9bad-46e37aabd0e9@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
 <Op_ytJfprSsgRBmnM6Tm9ZJVw_aBRlD7uZUiVQc1vEY=.9a32c2fd-409d-4fc3-9bad-46e37aabd0e9@github.com>
Message-ID: <Dl9WMJk6ZLulMRXDMG3Fmm5rPMuy-5dL9CEG_I0fv7s=.6d7028d8-4e21-4290-b77d-b0a2f0f821cf@github.com>

On Mon, 5 Jul 2021 09:31:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I think the comment beginning `g1CollectedHeap.hpp:929` should be adapted too.
> 
> Looks good otherwise.

Other than the mentioned need for a comment update, I also thing this looks good.

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

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


From kbarrett at openjdk.java.net  Tue Jul  6 08:21:51 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 6 Jul 2021 08:21:51 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider
In-Reply-To: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
Message-ID: <vbWIVTX7V6smB8KsEd7TTmBW3ZNwpXXnF4Zl9ezUqEQ=.38ed9d9d-71bc-4211-b076-05f027d8a481@github.com>

On Fri, 2 Jul 2021 12:59:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

The first two commits look good.

As for the 3rd (phase renumbering) commit, if we're going to do all this
renaming, I'd prefer the new names were semantically meaningful, rather than
just Phase1,2,3,4.  Unfortunately that didn't happen either in or as a
followup to JDK-8202845.

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

Changes requested by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Jul  6 08:45:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 08:45:06 GMT
Subject: RFR: 8269295: Verification time before/after young collection only
 covers parts of the verification
Message-ID: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>

Hi all,

  can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.

This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.

Testing: tier1

Thanks,
  Thomas

Note: this depends on PR4586.

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

Depends on: https://git.openjdk.java.net/jdk/pull/4586

Commit messages:
 - Initial implementation

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

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


From kbarrett at openjdk.java.net  Tue Jul  6 10:00:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 6 Jul 2021 10:00:55 GMT
Subject: RFR: 8269294: Verify_before/after_young_collection should execute
 all verification
In-Reply-To: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
References: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
Message-ID: <Rs8MUhu-Rrf3ddjpffctDpmhicPgqkboN90gTB4aEUA=.794499b8-c8c9-4d5d-8804-c70f019e6358@github.com>

On Thu, 24 Jun 2021 16:12:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this tiny change that moves all verification from `do_collection_pause_at_safepoint_helper()` to `verify_before/after_young_collection`?
> 
> I actually removed one call to `_hrm.verify_optional()` because it is already called in `_verifier->verify_region_sets_optional` although they are not completely equivalent as one call is `DEBUG_ONLY` and the other `NOT_PRODUCT`, but nobody is probably using the optimized build anyway. I can re-add the missing call if required.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> P.S: this is based on PR#4539, so it would be nice if it could be reviewed before this.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Tue Jul  6 10:20:54 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 6 Jul 2021 10:20:54 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v4]
In-Reply-To: <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
 <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>
Message-ID: <cIlcg0KktPMSL7jNSJa4-8xeYovNdx9hLVqzUrkJcuE=.b8d7bc47-231c-472e-817d-f9da0de31486@github.com>

On Mon, 5 Jul 2021 11:59:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that puts the evacuation failure marker from a separate log line into the GC timing message. I.e. instead of
>> 
>> 
>> Pause Young (Normal) (G1 Evacuation Pause)
>> To-space exhausted
>> 
>> into
>> 
>> 
>> Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause) 
>> 
>> 
>> This is imho easier to read, better to process and less wasteful with log space.
>> 
>> Testing: tier1, gc/g1 tests
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix G1AllowPreventiveGC -> G1UsePreventiveGC

Regarding `Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause)`, I interpret the three pairs of parens as:


1. (<gc pause kind, deciding what should be done in this pause>)
2. (<sth unexpected happened, deviating from the original plan>)
3. (<what initiates this pause>)

2 occurs strictly later than 1&3, so a more natural order is

`Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure)`.

This way, the original structure (meaning of the first two pairs of parens) could be preserved in all cases. When sth unexpected happens, the log is only appended, leaving the "conceptually existing" part intact.

Ofc, this is very subjective; just my 2 cents. (Merely a comment, not a review. I am fine with the current change.)

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

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


From lkorinth at openjdk.java.net  Tue Jul  6 10:28:50 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 6 Jul 2021 10:28:50 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
Message-ID: <zcUzmKESFevrwJwOjS3gAVhXfTBwx-cH9ytU38eSTU0=.e40d9723-0242-45a8-9619-324c3647aed5@github.com>

On Thu, 24 Jun 2021 16:31:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> Note: this depends on PR4586.

Marked as reviewed by lkorinth (Committer).

Looks good to me!

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

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


From tschatzl at openjdk.java.net  Tue Jul  6 10:28:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 10:28:50 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v4]
In-Reply-To: <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
 <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>
Message-ID: <L-KlfSVRtnlYXF45HZ0Ll-tsKpW2khn7mnUFMS3Ja0I=.8f1c61ac-861e-4721-9412-4b563c5e1c51@github.com>

On Mon, 5 Jul 2021 11:59:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that puts the evacuation failure marker from a separate log line into the GC timing message. I.e. instead of
>> 
>> 
>> Pause Young (Normal) (G1 Evacuation Pause)
>> To-space exhausted
>> 
>> into
>> 
>> 
>> Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause) 
>> 
>> 
>> This is imho easier to read, better to process and less wasteful with log space.
>> 
>> Testing: tier1, gc/g1 tests
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix G1AllowPreventiveGC -> G1UsePreventiveGC

I am aware of this and this has come up before. The problem is that the order of adding these strings is fixed by the execution order of the scoped objects. My initial attempt to fix this was too messy, but 'll look into this again, maybe I can find some better way.

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

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


From tschatzl at openjdk.java.net  Tue Jul  6 11:00:24 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 11:00:24 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v4]
In-Reply-To: <cIlcg0KktPMSL7jNSJa4-8xeYovNdx9hLVqzUrkJcuE=.b8d7bc47-231c-472e-817d-f9da0de31486@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
 <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>
 <cIlcg0KktPMSL7jNSJa4-8xeYovNdx9hLVqzUrkJcuE=.b8d7bc47-231c-472e-817d-f9da0de31486@github.com>
Message-ID: <Fzo4itkC83uARSY3-q7kAvroUP7uAcVXFQbAg5Be0hM=.4ccdae48-f6f7-427d-80ed-7a35ab92c6bf@github.com>

On Tue, 6 Jul 2021 10:17:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix G1AllowPreventiveGC -> G1UsePreventiveGC
>
> Regarding `Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause)`, I interpret the three pairs of parens as:
> 
> 
> 1. (<gc pause kind, deciding what should be done in this pause>)
> 2. (<sth unexpected happened, deviating from the original plan>)
> 3. (<what initiates this pause>)
> 
> 2 occurs strictly later than 1&3, so a more natural order is
> 
> `Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure)`.
> 
> This way, the original structure (meaning of the first two pairs of parens) could be preserved in all cases. When sth unexpected happens, the log is only appended, leaving the "conceptually existing" part intact.
> 
> Ofc, this is very subjective; just my 2 cents. (Merely a comment, not a review. I am fine with the current change.)

@albertnetymk : fixed :)

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

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


From tschatzl at openjdk.java.net  Tue Jul  6 11:00:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 11:00:22 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v5]
In-Reply-To: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
Message-ID: <l5phIDRWSOsl4tgswQofz6jjuFV2hZL9thac0bXgVGI=.c3aa35e6-b7d6-4f98-98bc-87cbd1e0c530@github.com>

> Hi all,
> 
>   can I have reviews for this change that puts the evacuation failure marker from a separate log line into the GC timing message. I.e. instead of
> 
> 
> Pause Young (Normal) (G1 Evacuation Pause)
> To-space exhausted
> 
> into
> 
> 
> Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause) 
> 
> 
> This is imho easier to read, better to process and less wasteful with log space.
> 
> Testing: tier1, gc/g1 tests

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

 - Reorder messages in string to be more natural
 - Merge branch 'master' of gh:tschatzl/jdk into 8269022-evac-failure-string-in-gc-info-message
 - Fix G1AllowPreventiveGC -> G1UsePreventiveGC
 - lkorinth review - forgot to save comment update
 - lkorinth review
 - Initial implementation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4539/files
  - new: https://git.openjdk.java.net/jdk/pull/4539/files/90ca1244..6183e9c9

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

  Stats: 26435 lines in 776 files changed: 11496 ins; 11891 del; 3048 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4539.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4539/head:pull/4539

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


From tschatzl at openjdk.java.net  Tue Jul  6 12:35:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 12:35:59 GMT
Subject: RFR: 8269908: Move MemoryService::track_memory_usage call into
 G1MonitoringScope
Message-ID: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>

Hi all,

  can I have reviews for this tiny change that moves the `MemoryService::track_memory_usage()` call into the destructor of `G1MonitoringScope` so that all jstat/mxbeans related reporting is handled by that single place?

Testing: tier1-3

Thanks,
  Thomas

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

Commit messages:
 - Initial implementation

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

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


From tschatzl at openjdk.java.net  Tue Jul  6 12:40:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 12:40:05 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
Message-ID: <ULVT8wPLhpgPVTVjwOMfRPpN1L49h0n-x8MDCmp4Jhs=.f6fbd3d2-ef33-469f-8a9d-d42f8009114b@github.com>

Hi all,

can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?

There is some minor change in order of unrelated options (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.

Based on #4539 .

Thanks,
Thomas

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

Depends on: https://git.openjdk.java.net/jdk/pull/4539

Commit messages:
 - Initial implementation of heap printing refactoring

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

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


From tschatzl at openjdk.java.net  Tue Jul  6 14:02:11 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 14:02:11 GMT
Subject: RFR: 8269908: Move MemoryService::track_memory_usage call into
 G1MonitoringScope [v2]
In-Reply-To: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
References: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
Message-ID: <kKrUliZegsHpxNHcUbyiTBhX6fih88LicsFrO4y0wtI=.bdebe2d0-80f9-4bd4-a413-864e18a2f07f@github.com>

> Hi all,
> 
>   can I have reviews for this tiny change that moves the `MemoryService::track_memory_usage()` call into the destructor of `G1MonitoringScope` so that all jstat/mxbeans related reporting is handled by that single place?
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

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

  ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4687/files
  - new: https://git.openjdk.java.net/jdk/pull/4687/files/97e18b35..a445ae33

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

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

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


From ayang at openjdk.java.net  Tue Jul  6 14:02:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 6 Jul 2021 14:02:12 GMT
Subject: RFR: 8269908: Move MemoryService::track_memory_usage call into
 G1MonitoringScope [v2]
In-Reply-To: <kKrUliZegsHpxNHcUbyiTBhX6fih88LicsFrO4y0wtI=.bdebe2d0-80f9-4bd4-a413-864e18a2f07f@github.com>
References: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
 <kKrUliZegsHpxNHcUbyiTBhX6fih88LicsFrO4y0wtI=.bdebe2d0-80f9-4bd4-a413-864e18a2f07f@github.com>
Message-ID: <FjgR8lPtSmT4QUAcL0rtKk8TgzW4uAVulZxfnbtwsxo=.8a50365e-decb-4cc7-b516-0c829ac1713c@github.com>

On Tue, 6 Jul 2021 13:59:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this tiny change that moves the `MemoryService::track_memory_usage()` call into the destructor of `G1MonitoringScope` so that all jstat/mxbeans related reporting is handled by that single place?
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Marked as reviewed by ayang (Committer).

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

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


From shade at openjdk.java.net  Tue Jul  6 15:21:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Jul 2021 15:21:10 GMT
Subject: RFR: 8269924: Shenandoah: Introduce weak/strong marking asserts
Message-ID: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>

For debugging, it is sometimes important to have not only `shenandoah_assert_marked`, but also `shenandoah_assert_marked_(weak|strong)` flavors.

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

Commit messages:
 - 8269924: Shenandoah: Introduce weak/strong marking asserts

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

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


From tschatzl at openjdk.java.net  Tue Jul  6 16:23:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 6 Jul 2021 16:23:52 GMT
Subject: Withdrawn: 8269914: Factor out heap printing for G1 young and full gc
In-Reply-To: <ULVT8wPLhpgPVTVjwOMfRPpN1L49h0n-x8MDCmp4Jhs=.f6fbd3d2-ef33-469f-8a9d-d42f8009114b@github.com>
References: <ULVT8wPLhpgPVTVjwOMfRPpN1L49h0n-x8MDCmp4Jhs=.f6fbd3d2-ef33-469f-8a9d-d42f8009114b@github.com>
Message-ID: <sEfNegt5jiQiQLxpy8i-jjADUVgzx2TOOfhbqAM8QV8=.a47d53a6-0e99-4727-87d7-bd46dc5ed856@github.com>

On Tue, 6 Jul 2021 12:33:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
> 
> There is some minor change in order of unrelated options (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
> 
> Based on #4539 .
> 
> Thanks,
> Thomas

This pull request has been closed without being integrated.

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

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


From rkennke at openjdk.java.net  Tue Jul  6 19:17:58 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 6 Jul 2021 19:17:58 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as strong
Message-ID: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>

We've observed test failures in jcstress, see:
https://bugs.openjdk.java.net/browse/JDK-8269897

We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.

A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.

Testing:
 - [x] the provided jcstress test
 - [x] hotspot_gc_shenandoah
 - [x] tier1

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

Commit messages:
 - 8269897: Shenandoah: Treat UNKNOWN refs access as strong

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From kbarrett at openjdk.java.net  Tue Jul  6 21:56:57 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 6 Jul 2021 21:56:57 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
Message-ID: <nuQprpEbSZ6nbfURmxdrTVDEON3B4lw78RZicyhylQY=.75d9bba2-f600-4433-bb28-61ec5211c56e@github.com>

On Thu, 24 Jun 2021 16:31:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> Note: this depends on PR4586.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Jul  6 21:58:52 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 6 Jul 2021 21:58:52 GMT
Subject: RFR: 8269908: Move MemoryService::track_memory_usage call into
 G1MonitoringScope [v2]
In-Reply-To: <kKrUliZegsHpxNHcUbyiTBhX6fih88LicsFrO4y0wtI=.bdebe2d0-80f9-4bd4-a413-864e18a2f07f@github.com>
References: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
 <kKrUliZegsHpxNHcUbyiTBhX6fih88LicsFrO4y0wtI=.bdebe2d0-80f9-4bd4-a413-864e18a2f07f@github.com>
Message-ID: <An2R79NUAeRkZl6uw2dzGDOh7T3UFNJJm4R0G00Wx9M=.1c4cf513-00c5-407d-b1dc-776f0895f5e2@github.com>

On Tue, 6 Jul 2021 14:02:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this tiny change that moves the `MemoryService::track_memory_usage()` call into the destructor of `G1MonitoringScope` so that all jstat/mxbeans related reporting is handled by that single place?
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Tue Jul  6 22:11:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 6 Jul 2021 22:11:55 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v5]
In-Reply-To: <l5phIDRWSOsl4tgswQofz6jjuFV2hZL9thac0bXgVGI=.c3aa35e6-b7d6-4f98-98bc-87cbd1e0c530@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
 <l5phIDRWSOsl4tgswQofz6jjuFV2hZL9thac0bXgVGI=.c3aa35e6-b7d6-4f98-98bc-87cbd1e0c530@github.com>
Message-ID: <Y_HSIW-qPkmPpe_JZAEXsWNzO3J1le9shl9_Wl5cbuY=.e5bed6c3-6d56-4240-ae56-97ceb508cc4d@github.com>

On Tue, 6 Jul 2021 11:00:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that puts the evacuation failure marker from a separate log line into the GC timing message. I.e. instead of
>> 
>> 
>> Pause Young (Normal) (G1 Evacuation Pause)
>> To-space exhausted
>> 
>> into
>> 
>> 
>> Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause) 
>> 
>> 
>> This is imho easier to read, better to process and less wasteful with log space.
>> 
>> Testing: tier1, gc/g1 tests
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Reorder messages in string to be more natural
>  - Merge branch 'master' of gh:tschatzl/jdk into 8269022-evac-failure-string-in-gc-info-message
>  - Fix G1AllowPreventiveGC -> G1UsePreventiveGC
>  - lkorinth review - forgot to save comment update
>  - lkorinth review
>  - Initial implementation

Looks good.

I agreed with Albert's comment about the order of the annotations.  I'm glad you found a (nice, not kludgy) way to fix that.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Wed Jul  7 07:30:22 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 7 Jul 2021 07:30:22 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery [v2]
In-Reply-To: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
Message-ID: <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>

> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
> 
> 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/4664/files
  - new: https://git.openjdk.java.net/jdk/pull/4664/files/6e58bbd1..f5ebe866

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

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

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


From ayang at openjdk.java.net  Wed Jul  7 07:30:23 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 7 Jul 2021 07:30:23 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery
In-Reply-To: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
Message-ID: <DFiihAEUd6a51mx6m4hLVN2oWLTVL868gUhBD4zYL4Q=.8bc2c6b1-d305-413e-8ea7-8d2fd059032d@github.com>

On Fri, 2 Jul 2021 11:00:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
> 
> Test: hotspot_gc

Updated the comments.

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:36:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:36:52 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery [v2]
In-Reply-To: <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
 <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>
Message-ID: <BjmhLLCojdTlMU8BadDgGWZLe2Z_AIUyEBjGwVpeW68=.76801f45-c352-49d3-8081-667f241c0648@github.com>

On Wed, 7 Jul 2021 07:30:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:36:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:36:59 GMT
Subject: Integrated: 8269022: Put evacuation failure string directly into
 gc=info log message
In-Reply-To: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
Message-ID: <kuCt-yQpQ0UesZGk1ccmQD_Ag9eawt_elcdoLei3NsY=.2c2f096c-8a44-4a43-a4f2-856477288013@github.com>

On Mon, 21 Jun 2021 13:18:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that puts the evacuation failure marker from a separate log line into the GC timing message. I.e. instead of
> 
> 
> Pause Young (Normal) (G1 Evacuation Pause)
> To-space exhausted
> 
> into
> 
> 
> Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause) 
> 
> 
> This is imho easier to read, better to process and less wasteful with log space.
> 
> Testing: tier1, gc/g1 tests

This pull request has now been integrated.

Changeset: a6850111
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6850111accfd50d04227a4cc1e8e6fff4d8de68
Stats:     148 lines in 4 files changed: 122 ins; 24 del; 2 mod

8269022: Put evacuation failure string directly into gc=info log message

Reviewed-by: iwalulya, lkorinth, kbarrett

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:36:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:36:57 GMT
Subject: RFR: 8269022: Put evacuation failure string directly into gc=info
 log message [v4]
In-Reply-To: <cIlcg0KktPMSL7jNSJa4-8xeYovNdx9hLVqzUrkJcuE=.b8d7bc47-231c-472e-817d-f9da0de31486@github.com>
References: <y4KNBaymgkExCdEoy30fFDPLXUrXK64_G8kMOpByIU8=.43111234-9c48-4832-b117-7ce56915d9b0@github.com>
 <nixX-lT7OhUjGw9r4t7jrU_weS_9EfTFQFjggo9AM04=.14d9da3a-af13-4ea2-86e0-e37d7db616b7@github.com>
 <cIlcg0KktPMSL7jNSJa4-8xeYovNdx9hLVqzUrkJcuE=.b8d7bc47-231c-472e-817d-f9da0de31486@github.com>
Message-ID: <VFhSfN52aloYVAlzCW6fskAxX9P2wzq8IGrYM6gEcsg=.333184f6-478e-48a1-8954-f6049c0752e0@github.com>

On Tue, 6 Jul 2021 10:17:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix G1AllowPreventiveGC -> G1UsePreventiveGC
>
> Regarding `Pause Young (Normal) (Evacuation Failure) (G1 Evacuation Pause)`, I interpret the three pairs of parens as:
> 
> 
> 1. (<gc pause kind, deciding what should be done in this pause>)
> 2. (<sth unexpected happened, deviating from the original plan>)
> 3. (<what initiates this pause>)
> 
> 2 occurs strictly later than 1&3, so a more natural order is
> 
> `Pause Young (Normal) (G1 Evacuation Pause) (Evacuation Failure)`.
> 
> This way, the original structure (meaning of the first two pairs of parens) could be preserved in all cases. When sth unexpected happens, the log is only appended, leaving the "conceptually existing" part intact.
> 
> Ofc, this is very subjective; just my 2 cents. (Merely a comment, not a review. I am fine with the current change.)

Thanks @albertnetymk @walulyai @lkorinth @kimbarrett for your reviews.

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

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


From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jul  7 07:40:20 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 7 Jul 2021 07:40:20 GMT
Subject: RFR: 8269294: Verify_before/after_young_collection should execute
 all verification
In-Reply-To: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
References: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
Message-ID: <RqsGjFEf6jh6U9jA3d-Zi0B0uiBfFQo5mVM1Z_YbI8I=.12f4f426-5cc0-4b3a-9aac-bc341c516f15@github.com>

On Thu, 24 Jun 2021 16:12:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this tiny change that moves all verification from `do_collection_pause_at_safepoint_helper()` to `verify_before/after_young_collection`?
> 
> I actually removed one call to `_hrm.verify_optional()` because it is already called in `_verifier->verify_region_sets_optional` although they are not completely equivalent as one call is `DEBUG_ONLY` and the other `NOT_PRODUCT`, but nobody is probably using the optimized build anyway. I can re-add the missing call if required.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> P.S: this is based on PR#4539, so it would be nice if it could be reviewed before this.

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout submit/8269022-evac-failure-string-in-gc-info-message
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:40:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:40:20 GMT
Subject: RFR: 8269294: Verify_before/after_young_collection should execute
 all verification [v2]
In-Reply-To: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
References: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
Message-ID: <RBhn1rWYgA9Kbj54LT4gx783KDkYom2kBtWywTgP5zg=.d0280570-dcec-424a-96f4-a8f8c311261b@github.com>

> Hi all,
> 
>   can I have reviews for this tiny change that moves all verification from `do_collection_pause_at_safepoint_helper()` to `verify_before/after_young_collection`?
> 
> I actually removed one call to `_hrm.verify_optional()` because it is already called in `_verifier->verify_region_sets_optional` although they are not completely equivalent as one call is `DEBUG_ONLY` and the other `NOT_PRODUCT`, but nobody is probably using the optimized build anyway. I can re-add the missing call if required.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> P.S: this is based on PR#4539, so it would be nice if it could be reviewed before this.

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4586/files
  - new: https://git.openjdk.java.net/jdk/pull/4586/files/14cf1aa1..14cf1aa1

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

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:42:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:42:47 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <zcUzmKESFevrwJwOjS3gAVhXfTBwx-cH9ytU38eSTU0=.e40d9723-0242-45a8-9619-324c3647aed5@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
 <zcUzmKESFevrwJwOjS3gAVhXfTBwx-cH9ytU38eSTU0=.e40d9723-0242-45a8-9619-324c3647aed5@github.com>
Message-ID: <-KNhwkZrpRTHSIKScSdidfJ1Ng5v_9RCxNSv-cpp6UE=.3c9bf9bd-1d23-40fc-bcd7-5461f29a0043@github.com>

On Tue, 6 Jul 2021 10:25:00 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
>> 
>> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
>> 
>> Testing: tier1
>> 
>> Thanks,
>>   Thomas
>> 
>> Note: this depends on PR4586.
>
> Looks good to me!

Thanks @lkorinth @kimbarrett  for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:42:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:42:50 GMT
Subject: Integrated: 8269908: Move MemoryService::track_memory_usage call into
 G1MonitoringScope
In-Reply-To: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
References: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
Message-ID: <U33P03eoFHa2PdbxhxFGzxs5iuY4YqP89qEWL8AQJjw=.23983ef8-85bf-41bb-b8c0-6058a392a156@github.com>

On Tue, 6 Jul 2021 12:26:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this tiny change that moves the `MemoryService::track_memory_usage()` call into the destructor of `G1MonitoringScope` so that all jstat/mxbeans related reporting is handled by that single place?
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8269908: Move MemoryService::track_memory_usage call into G1MonitoringScope

Reviewed-by: ayang, kbarrett

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 07:42:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 07:42:49 GMT
Subject: RFR: 8269908: Move MemoryService::track_memory_usage call into
 G1MonitoringScope [v2]
In-Reply-To: <FjgR8lPtSmT4QUAcL0rtKk8TgzW4uAVulZxfnbtwsxo=.8a50365e-decb-4cc7-b516-0c829ac1713c@github.com>
References: <GdVXWuPYAlwo0KG4pxrBChZo3gnZEaqExZQ0JwPQdjQ=.e17fbb4c-b9c7-4663-9dd9-52b8725aeb83@github.com>
 <kKrUliZegsHpxNHcUbyiTBhX6fih88LicsFrO4y0wtI=.bdebe2d0-80f9-4bd4-a413-864e18a2f07f@github.com>
 <FjgR8lPtSmT4QUAcL0rtKk8TgzW4uAVulZxfnbtwsxo=.8a50365e-decb-4cc7-b516-0c829ac1713c@github.com>
Message-ID: <GSO4GnBxGZ6LqDEfDJBEvpx1lP6aO7gyfrrz3rygP80=.6f43774a-44aa-415d-a3bd-ec9a43d65368@github.com>

On Tue, 6 Jul 2021 13:57:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks @albertnetymk @kimbarrett for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 08:01:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 08:01:20 GMT
Subject: RFR: 8269294: Verify_before/after_young_collection should execute
 all verification [v3]
In-Reply-To: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
References: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
Message-ID: <m7he4L0NZ6D7Nql1G8R7WM2liWjJuQ8Fnil9BpZJ3sg=.28b1e052-2bf9-4666-adba-5d9080aa08a2@github.com>

> Hi all,
> 
>   can I have reviews for this tiny change that moves all verification from `do_collection_pause_at_safepoint_helper()` to `verify_before/after_young_collection`?
> 
> I actually removed one call to `_hrm.verify_optional()` because it is already called in `_verifier->verify_region_sets_optional` although they are not completely equivalent as one call is `DEBUG_ONLY` and the other `NOT_PRODUCT`, but nobody is probably using the optimized build anyway. I can re-add the missing call if required.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> P.S: this is based on PR#4539, so it would be nice if it could be reviewed before this.

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

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into submit/8269294-merge-verify-stages
 - Fix young gc verify stages
 - Initial implementation

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

Changes: https://git.openjdk.java.net/jdk/pull/4586/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4586&range=02
  Stats: 9 lines in 1 file changed: 3 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4586.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4586/head:pull/4586

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


From tschatzl at openjdk.java.net  Wed Jul  7 08:01:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 08:01:20 GMT
Subject: RFR: 8269294: Verify_before/after_young_collection should execute
 all verification [v2]
In-Reply-To: <Rs8MUhu-Rrf3ddjpffctDpmhicPgqkboN90gTB4aEUA=.794499b8-c8c9-4d5d-8804-c70f019e6358@github.com>
References: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
 <Rs8MUhu-Rrf3ddjpffctDpmhicPgqkboN90gTB4aEUA=.794499b8-c8c9-4d5d-8804-c70f019e6358@github.com>
Message-ID: <0p3Nv5k2TNm8f2mKUD5VQc-kKJsUjv19AzJVFr48IAQ=.214d1aa8-c54c-4a48-a707-de029541614e@github.com>

On Tue, 6 Jul 2021 09:57:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Fix young gc verify stages
>>  - Initial implementation
>
> Looks good.

Thanks @kimbarrett @walulyai for your reviews.

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 08:01:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 08:01:22 GMT
Subject: Integrated: 8269294: Verify_before/after_young_collection should
 execute all verification
In-Reply-To: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
References: <Am5HnPtPOojROd69Tnkiq-rUnw_GYBvP3xxazdY-nCg=.b3c1abb4-decf-455a-806b-f08e3d9ed9e2@github.com>
Message-ID: <aC_M9pS8MBiKpWiZzYk6ML19FKIT_jGzvR-86nUp67c=.8fa1523c-ed53-4ad6-af79-eeb87d8464e0@github.com>

On Thu, 24 Jun 2021 16:12:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this tiny change that moves all verification from `do_collection_pause_at_safepoint_helper()` to `verify_before/after_young_collection`?
> 
> I actually removed one call to `_hrm.verify_optional()` because it is already called in `_verifier->verify_region_sets_optional` although they are not completely equivalent as one call is `DEBUG_ONLY` and the other `NOT_PRODUCT`, but nobody is probably using the optimized build anyway. I can re-add the missing call if required.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> P.S: this is based on PR#4539, so it would be nice if it could be reviewed before this.

This pull request has now been integrated.

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

8269294: Verify_before/after_young_collection should execute all verification

Reviewed-by: iwalulya, kbarrett

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 08:01:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 08:01:37 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification [v2]
In-Reply-To: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
Message-ID: <Dgva75gYQJHLQydqKVlxuo_yxKBX2WrgUSjPSCkYeik=.7d41204a-0afb-47fd-99a3-99a58714bfa2@github.com>

> Hi all,
> 
>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> Note: this depends on PR4586.

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4587/files
  - new: https://git.openjdk.java.net/jdk/pull/4587/files/7b4ce0e2..7b4ce0e2

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

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

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


From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net  Wed Jul  7 08:01:39 2021
From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot])
Date: Wed, 7 Jul 2021 08:01:39 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
Message-ID: <WjHnbWOrz-EJjO7hxB9PWrGuHQ0j7sgmfoNI3bUB1VU=.52cc6bba-de3c-40ad-8b47-4ca0f598e3e1@github.com>

On Thu, 24 Jun 2021 16:31:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> Note: this depends on PR4586.

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:


git checkout submit/8269294-merge-verify-stages
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 08:01:39 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 08:01:39 GMT
Subject: Withdrawn: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
Message-ID: <PCrMygvmziVZaoJQ2IPbjfgCgjTNteXOKbMxFnlVUeU=.1392c9b6-2b57-41ce-b1ad-9dd5723eb5d0@github.com>

On Thu, 24 Jun 2021 16:31:09 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> Note: this depends on PR4586.

This pull request has been closed without being integrated.

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

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


From ayang at openjdk.java.net  Wed Jul  7 08:05:51 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 7 Jul 2021 08:05:51 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider
In-Reply-To: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
Message-ID: <7EZFZ_i__jyMgXdjVKsP5_D8VLzr-BNdKxBR0__D2Ak=.7f456278-709b-4085-b868-ee21f8ed65b9@github.com>

On Fri, 2 Jul 2021 12:59:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

Names and responsibility of various phases:


  enum RefProcSubPhases {
    SoftRefSubPhase1,
    WeakRefSubPhase1,
    FinalRefSubPhase1,
    FinalRefSubPhase2,
    PhantomRefSubPhase3,
    RefSubPhaseMax
  };

  enum RefProcPhases {
    RefPhase1,
    RefPhase2,
    RefPhase3,
    RefPhaseMax
  };
  
  // Phase 1: Drop Soft/Weak/Final references with a NULL or live referent, and clear
  // and enqueue non-Final references.
  void process_soft_weak_final_refs(RefProcProxyTask& proxy_task,
                                    ReferenceProcessorPhaseTimes& phase_times);

  // Phase 2: Keep alive followers of Final references, and enqueue.
  void process_final_keep_alive(RefProcProxyTask& proxy_task,
                                ReferenceProcessorPhaseTimes& phase_times);

  // Phase 3: Drop and keep alive live Phantom references, or clear and enqueue if dead.
  void process_phantom_refs(RefProcProxyTask& proxy_task,
                            ReferenceProcessorPhaseTimes& phase_times);


Kim's suggestion:


Process{Soft,Weak,Final}RefsSubPhase, KeepAliveFinalRefsSubPhase, ProcessPhantomRefsSubPhase

SoftWeakFinalRefsPhase, KeepAliveFinalRefsPhase, PhantomRefsPhase


Given such renaming is quite invasive, maybe it can be done in a separate PR. So which option do reviewers think is the best to take?

1. create a revert for the third commit, leaving renaming to another PR. (The phases will start from "2" in the logs.)
2. make semantic renaming in this PR. (Mixing real changes with large renaming.)

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 08:31:03 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 08:31:03 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
Message-ID: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>

Hi all,

can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?

There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.

(Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)

Thanks,
  Thomas

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

Commit messages:
 - Add missing code
 - Initial implementation of heap printing refactoring
 - Fix G1AllowPreventiveGC -> G1UsePreventiveGC
 - lkorinth review
 - Initial implementation

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

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


From ayang at openjdk.java.net  Wed Jul  7 10:35:01 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 7 Jul 2021 10:35:01 GMT
Subject: RFR: 8270021: Incorrect log decorators in
 gc/g1/plab/TestPLABEvacuationFailure.java
Message-ID: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>

Fixed the log decorator, and added checks for non-empty statistics.

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

Commit messages:
 - plab

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

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


From shade at openjdk.java.net  Wed Jul  7 10:44:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Jul 2021 10:44:51 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong
In-Reply-To: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
Message-ID: <jY3wUZPv8m2GsY4n_KJ3SdlYI2GCGVOx9pBVAulG-FQ=.0e18333e-dfe9-4228-bb7f-c02674992b5a@github.com>

On Tue, 6 Jul 2021 19:11:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

It looks okay to me, and it fixes the jcstress failures. But I see one of the `tier1` tests failing:


$ make run-test TEST=gc/TestReferenceClearDuringReferenceProcessing.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
...
TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: ref not enqueued

I wonder if that failure indicates that fix is still incomplete or too conservative.

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From tschatzl at openjdk.java.net  Wed Jul  7 10:58:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 10:58:52 GMT
Subject: RFR: 8270021: Incorrect log decorators in
 gc/g1/plab/TestPLABEvacuationFailure.java
In-Reply-To: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
References: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
Message-ID: <QgkrJL3RcqgREtfmUO2ifWDmJW5oFXOyKhkOIwabfh4=.82830333-f90d-4a1e-ad47-6edf8529df59@github.com>

On Wed, 7 Jul 2021 10:29:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fixed the log decorator, and added checks for non-empty statistics.

Marked as reviewed by tschatzl (Reviewer).

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

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


From rkennke at openjdk.java.net  Wed Jul  7 12:37:16 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 7 Jul 2021 12:37:16 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v2]
In-Reply-To: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
Message-ID: <l7TXRUKDYKkwOf2UZFMe9aMtZune06nQ_poHXgMsoAA=.a4fb8bf0-5429-4586-942e-ca47d38f2609@github.com>

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Treat UNKNOWN as STRONG more selectively only on CAE

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/219/files
  - new: https://git.openjdk.java.net/jdk17/pull/219/files/07d7a9f1..31805dee

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

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From rkennke at openjdk.java.net  Wed Jul  7 12:37:16 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 7 Jul 2021 12:37:16 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v2]
In-Reply-To: <jY3wUZPv8m2GsY4n_KJ3SdlYI2GCGVOx9pBVAulG-FQ=.0e18333e-dfe9-4228-bb7f-c02674992b5a@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
 <jY3wUZPv8m2GsY4n_KJ3SdlYI2GCGVOx9pBVAulG-FQ=.0e18333e-dfe9-4228-bb7f-c02674992b5a@github.com>
Message-ID: <R6h4AWOrzX3v9V_aOGxDtXfbVsET9iBUwfgkH_gfOiA=.78ce5874-e8e9-41a1-af32-25b899ff2e90@github.com>

On Wed, 7 Jul 2021 10:41:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It looks okay to me, and it fixes the jcstress failures. But I see one of the `tier1` tests failing:
> 
> ```
> $ make run-test TEST=gc/TestReferenceClearDuringReferenceProcessing.java TEST_VM_OPTS="-XX:+UseShenandoahGC"
> ...
> TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: ref not enqueued
> ```
> 
> I wonder if that failure indicates that fix is still incomplete or too conservative.

Changing behaviour for oop_load_in_heap() seems to break it (although it is not quite obvious to me how - the test does not seem to access Reference.referent itself, especially not via reflection/unsafe/etc. Maybe something internal in Reference queue does, and expects it to return NULL on unreachable.)
Let's limit the change to treat UNKNOWN as STRONG only for CAE.

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From iwalulya at openjdk.java.net  Wed Jul  7 12:40:52 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 7 Jul 2021 12:40:52 GMT
Subject: RFR: 8270021: Incorrect log decorators in
 gc/g1/plab/TestPLABEvacuationFailure.java
In-Reply-To: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
References: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
Message-ID: <S83m8-CgkqjacFdaaPMn2eGaV1r1FsgMKwqlhzoTBAI=.2b4a3604-d86a-4cbd-9bd9-24ade8a94a0e@github.com>

On Wed, 7 Jul 2021 10:29:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fixed the log decorator, and added checks for non-empty statistics.

Marked as reviewed by iwalulya (Committer).

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 15:03:24 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 15:03:24 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
In-Reply-To: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
Message-ID: <VLChGAEibCa0Szh8M7FFROSxMb2B_MRGzPSaQ5ngozw=.750e20c7-1274-4ec7-9bdc-c12679fdd3e9@github.com>

On Wed, 7 Jul 2021 08:23:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
> 
> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
> 
> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
> 
> To keep JFR event sending in the correct order, this change includes JDK-8270018.
> 
> Thanks,
>   Thomas

Apologies for this recent change: due to the way I split the change containing all changes there had been a problem with JFR events getting sent out of order which some tests checked (in `jdk/jfr/event/gc/collection/*`). The event to send the age table had been sent after the "gc end" event.
This is fixed by making sure that the JFR tracer/timers are appropriately used in scoped objects as well.

Also the original change contained the output of a merge error.

Apologies. Should be all fixed now though, but I'll rerun tier1-5

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

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


From tschatzl at openjdk.java.net  Wed Jul  7 15:03:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 7 Jul 2021 15:03:22 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v2]
In-Reply-To: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
Message-ID: <c-7wLTEab0E723COahd4RQ2Xm13O51KugDwBgOzyWhc=.9be04f5e-80e1-493e-a3f4-bac0ed6227e2@github.com>

> Hi all,
> 
> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
> 
> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
> 
> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
> 
> To keep JFR event sending in the correct order, this change includes JDK-8270018.
> 
> Thanks,
>   Thomas

Thomas Schatzl 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:

  Initial implementation of heap printing refactoring

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4705/files
  - new: https://git.openjdk.java.net/jdk/pull/4705/files/bb712baa..b5b57c06

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

  Stats: 191 lines in 5 files changed: 73 ins; 109 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4705.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4705/head:pull/4705

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


From shade at openjdk.java.net  Wed Jul  7 18:32:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Jul 2021 18:32:54 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v2]
In-Reply-To: <22QG4_SdgK-z2XrxRCJ17H_G9Rk8paxapKURHrDD3A4=.1d67309e-3149-4722-92cf-a2b394eeaa54@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
 <l7TXRUKDYKkwOf2UZFMe9aMtZune06nQ_poHXgMsoAA=.a4fb8bf0-5429-4586-942e-ca47d38f2609@github.com>
 <22QG4_SdgK-z2XrxRCJ17H_G9Rk8paxapKURHrDD3A4=.1d67309e-3149-4722-92cf-a2b394eeaa54@github.com>
Message-ID: <Wv6K1Y3GXtz6l5OmF9d2gXR0O1luvvppipN1dutg4rU=.166a600f-14e7-42e5-8178-2b66fc6a2f24@github.com>

On Wed, 7 Jul 2021 17:48:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Treat UNKNOWN as STRONG more selectively only on CAE
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 270:
> 
>> 268:   // Note: We don't need a keep-alive-barrier here. We already enqueue any loaded reference for SATB anyway,
>> 269:   // because it must be the previous value.
>> 270:   res = ShenandoahBarrierSet::barrier_set()->load_reference_barrier<decorators & ~ON_UNKNOWN_OOP_REF, T>(res, NULL);
> 
> Add a comment: 
> 
> 
>   // Note: We don't need a keep-alive-barrier here. We already enqueue any loaded reference for SATB anyway,
>   // because it must be the previous value. Convert ON_UNKNOWN_OOP_REF to strong, so that we don't return
>   // NULL for weak values, breaking CAS contract. The downside is this method effectively resurrecting
>   // weak values without GC knowing about it. If Unsafe/JNI users are using this method on weak values
>   // (i.e. doing unsafe accesses to Reference.referent), they are on their own.

I also believe "xchg" needs the same fix and a comment:


  // Note: We don't need a keep-alive-barrier here. We already enqueue any loaded reference for SATB anyway,
  // because it must be the previous value. Convert ON_UNKNOWN_OOP_REF to strong, so that we don't return
  // NULL for weak values. ShenandoahBarrierSet::See oop_atomic_cmpxchg_not_in_heap for explanation.

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From shade at openjdk.java.net  Wed Jul  7 18:32:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Jul 2021 18:32:53 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v2]
In-Reply-To: <l7TXRUKDYKkwOf2UZFMe9aMtZune06nQ_poHXgMsoAA=.a4fb8bf0-5429-4586-942e-ca47d38f2609@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
 <l7TXRUKDYKkwOf2UZFMe9aMtZune06nQ_poHXgMsoAA=.a4fb8bf0-5429-4586-942e-ca47d38f2609@github.com>
Message-ID: <22QG4_SdgK-z2XrxRCJ17H_G9Rk8paxapKURHrDD3A4=.1d67309e-3149-4722-92cf-a2b394eeaa54@github.com>

On Wed, 7 Jul 2021 12:37:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Treat UNKNOWN as STRONG more selectively only on CAE

Need synopsis change after limiting a fix?
Need to handle `xchg` case too. 

This patch passes `tier1` with Shenandoah for me, but fails jcstress bundle when run with C1. A relevant `ShenandoahBarrierSetC1` change is quite probably missing.

Also, probably `Unsafe` `get` and `set` require the same handling: under concurrent weak roots, it is safer to return overly strong value, not NULL for strong refs. Let it be users' problem accessing weak values with Unsafe?

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 643:

> 641:     }
> 642: #endif
> 643:     load_store = kit->gvn().transform(new ShenandoahLoadReferenceBarrierNode(NULL, load_store, access.decorators() & ~ON_UNKNOWN_OOP_REF));

Add a comment:


    // Convert ON_UNKNOWN_OOP_REF to strong, so that we don't return NULL for weak values.
    // See ShenandoahBarrierSet::See oop_atomic_cmpxchg_not_in_heap for explanation.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 270:

> 268:   // Note: We don't need a keep-alive-barrier here. We already enqueue any loaded reference for SATB anyway,
> 269:   // because it must be the previous value.
> 270:   res = ShenandoahBarrierSet::barrier_set()->load_reference_barrier<decorators & ~ON_UNKNOWN_OOP_REF, T>(res, NULL);

Add a comment: 


  // Note: We don't need a keep-alive-barrier here. We already enqueue any loaded reference for SATB anyway,
  // because it must be the previous value. Convert ON_UNKNOWN_OOP_REF to strong, so that we don't return
  // NULL for weak values, breaking CAS contract. The downside is this method effectively resurrecting
  // weak values without GC knowing about it. If Unsafe/JNI users are using this method on weak values
  // (i.e. doing unsafe accesses to Reference.referent), they are on their own.

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

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/219


From kbarrett at openjdk.java.net  Wed Jul  7 22:59:49 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 7 Jul 2021 22:59:49 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery [v2]
In-Reply-To: <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
 <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>
Message-ID: <YZGWW92NNNirZWgdbQGj7g5GzWyz9dErFxhJcgVfDpI=.ac70c27d-dd45-40c3-9331-9b2388a7f81f@github.com>

On Wed, 7 Jul 2021 07:30:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
>> 
>> 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/4664


From ayang at openjdk.java.net  Thu Jul  8 06:18:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 06:18:49 GMT
Subject: RFR: 8269803: G1: remove unnecessary NoRefDiscovery [v2]
In-Reply-To: <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
 <S8-C3X-APK4TgR1UUdmG7UeuKQ_2zWyLR0qcApBoKbM=.4cdbf2b4-2f4d-4b8f-a60d-795f1d104176@github.com>
Message-ID: <5IEzik9dQIKIRY40iKvZNNtiaqLYfFOEgDF0DDj3fLs=.88dd23e5-5143-4415-94fd-b79db638e5a2@github.com>

On Wed, 7 Jul 2021 07:30:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
>> 
>> 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/4664


From ayang at openjdk.java.net  Thu Jul  8 06:18:50 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 06:18:50 GMT
Subject: Integrated: 8269803: G1: remove unnecessary NoRefDiscovery
In-Reply-To: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
References: <gE1E5-zcm9VWyZ7-K8h0qONVraL5LK7oa5ahHAauNAo=.74f75c5f-567a-441d-bcc3-631447cac1df@github.com>
Message-ID: <VHG-4j5OZRVUx6sOz5Nwv4HT6ZFRyIVFMnXcqtpdTnk=.040500df-5895-4690-a328-a7241feca0bf@github.com>

On Fri, 2 Jul 2021 11:00:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing the unnecessary disable of ref-discovery for CM during young-gc pause.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8269803: G1: remove unnecessary NoRefDiscovery

Reviewed-by: tschatzl, kbarrett

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

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


From ayang at openjdk.java.net  Thu Jul  8 09:58:03 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 09:58:03 GMT
Subject: RFR: 8270082: Remove unnecessary gc_timer null check in
 ReferenceProcessorPhaseTimes
Message-ID: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>

Simple change of removing a null check.

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

Commit messages:
 - rp-timer

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

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


From tschatzl at openjdk.java.net  Thu Jul  8 10:38:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 8 Jul 2021 10:38:51 GMT
Subject: RFR: 8270082: Remove unnecessary gc_timer null check in
 ReferenceProcessorPhaseTimes
In-Reply-To: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
References: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
Message-ID: <ZBZLO5QGRjH40K3k1GAH_uqNhRLG1Ytyk0wdTDYfAJU=.8bd64a0c-2226-4480-b715-afdee29b7402@github.com>

On Thu, 8 Jul 2021 09:49:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a null check.

Marked as reviewed by tschatzl (Reviewer).

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

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


From ayang at openjdk.java.net  Thu Jul  8 10:42:54 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 10:42:54 GMT
Subject: Integrated: 8270021: Incorrect log decorators in
 gc/g1/plab/TestPLABEvacuationFailure.java
In-Reply-To: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
References: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
Message-ID: <wmfn2244hKmx9f6A7QWDFr5xMkij-97NR1MlP4mCHoc=.4d2afdaa-7bb9-48fa-aee4-8f87d0ad25b0@github.com>

On Wed, 7 Jul 2021 10:29:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fixed the log decorator, and added checks for non-empty statistics.

This pull request has now been integrated.

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

8270021: Incorrect log decorators in gc/g1/plab/TestPLABEvacuationFailure.java

Reviewed-by: tschatzl, iwalulya

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

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


From ayang at openjdk.java.net  Thu Jul  8 10:42:54 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 10:42:54 GMT
Subject: RFR: 8270021: Incorrect log decorators in
 gc/g1/plab/TestPLABEvacuationFailure.java
In-Reply-To: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
References: <ZERra77vV89MwltCdYOnicc17tM-LfK94khq0-pwvA4=.ff0470f0-ef03-462d-97c1-9f5729fa040e@github.com>
Message-ID: <_FSu82cvQ2Ce1tyow1k7RFwyWzlQPMe4hfq9YeKcbuM=.382ee778-97cf-430d-bf6b-23b2c7bbd051@github.com>

On Wed, 7 Jul 2021 10:29:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fixed the log decorator, and added checks for non-empty statistics.

Thanks for the review.

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

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


From ayang at openjdk.java.net  Thu Jul  8 11:48:53 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 11:48:53 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v2]
In-Reply-To: <c-7wLTEab0E723COahd4RQ2Xm13O51KugDwBgOzyWhc=.9be04f5e-80e1-493e-a3f4-bac0ed6227e2@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <c-7wLTEab0E723COahd4RQ2Xm13O51KugDwBgOzyWhc=.9be04f5e-80e1-493e-a3f4-bac0ed6227e2@github.com>
Message-ID: <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>

On Wed, 7 Jul 2021 15:03:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
>> 
>> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
>> 
>> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
>> 
>> To keep JFR event sending in the correct order, this change includes JDK-8270018.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl 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.

Many comments are very subjective; the current version looks fine as well.

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

> 981: };
> 982: 
> 983: void G1CollectedHeap::print_heap_after_full_collection() {

It's a bit odd to see `*_full_collection` as an API of `G1CollectedHeap`; I would have expected full-collection-only APIs in g1 full gc files.

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

> 2946:   _g1h->print_heap_after_gc();
> 2947:   // We are at the end of the GC. Total collections has already been increased.
> 2948:   _g1h->rem_set()->print_periodic_summary_info("After GC RS summary", _g1h->total_collections() - 1);

It's unclear to me why they are separated into two sections here. Additionally, does the order matter? If not, is it possible to group the two `rem_set()` calls together?

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

> 2979:   void report_pause_type(G1GCPauseType type) {
> 2980:     tracer()->report_young_gc_pause(type);
> 2981:   }

This one seems unused.

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

> 3068:         _allocator->release_mutator_alloc_regions();
> 3069: 
> 3070:         calculate_collection_set(*jtm.evacuation_info(), target_pause_time_ms);

`*jtm.evacuation_info()` seems odd; `calculate_collection_set` could use pointer instead of reference, right?

src/hotspot/share/gc/g1/g1FullGCScope.hpp line 71:

> 69:                 bool clear_soft,
> 70:                 bool do_maximal_compaction);
> 71:   ~G1FullGCScope() { }

Why not just remove this destructor?

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

Changes requested by ayang (Committer).

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


From tschatzl at openjdk.java.net  Thu Jul  8 12:01:54 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 8 Jul 2021 12:01:54 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v2]
In-Reply-To: <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <c-7wLTEab0E723COahd4RQ2Xm13O51KugDwBgOzyWhc=.9be04f5e-80e1-493e-a3f4-bac0ed6227e2@github.com>
 <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>
Message-ID: <DTsx94YHNoE6xT3EOpktWcNrLE0R3M7gjBfQRdzqgG4=.59e44150-7ad5-4553-8d13-6ff6980949ea@github.com>

On Thu, 8 Jul 2021 11:32:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl 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.
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2948:
> 
>> 2946:   _g1h->print_heap_after_gc();
>> 2947:   // We are at the end of the GC. Total collections has already been increased.
>> 2948:   _g1h->rem_set()->print_periodic_summary_info("After GC RS summary", _g1h->total_collections() - 1);
> 
> It's unclear to me why they are separated into two sections here. Additionally, does the order matter? If not, is it possible to group the two `rem_set()` calls together?

One is printing about the heap, other is printing "other" stuff.

> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2981:
> 
>> 2979:   void report_pause_type(G1GCPauseType type) {
>> 2980:     tracer()->report_young_gc_pause(type);
>> 2981:   }
> 
> This one seems unused.

Fixed.

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

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


From tschatzl at openjdk.java.net  Thu Jul  8 12:05:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 8 Jul 2021 12:05:55 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v2]
In-Reply-To: <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <c-7wLTEab0E723COahd4RQ2Xm13O51KugDwBgOzyWhc=.9be04f5e-80e1-493e-a3f4-bac0ed6227e2@github.com>
 <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>
Message-ID: <UOkvK_1__mkK0_l6D-OuyHD62VgiHi4QIc3UpF93rzA=.536e042a-8e09-4ccd-bdc5-bb6fef78b7a1@github.com>

On Thu, 8 Jul 2021 11:41:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl 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.
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3070:
> 
>> 3068:         _allocator->release_mutator_alloc_regions();
>> 3069: 
>> 3070:         calculate_collection_set(*jtm.evacuation_info(), target_pause_time_ms);
> 
> `*jtm.evacuation_info()` seems odd; `calculate_collection_set` could use pointer instead of reference, right?

It has been there that way, so I kept it in that change. Now changed all uses to pointers.

> src/hotspot/share/gc/g1/g1FullGCScope.hpp line 71:
> 
>> 69:                 bool clear_soft,
>> 70:                 bool do_maximal_compaction);
>> 71:   ~G1FullGCScope() { }
> 
> Why not just remove this destructor?

Forgotten.

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

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


From tschatzl at openjdk.java.net  Thu Jul  8 12:21:37 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 8 Jul 2021 12:21:37 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v2]
In-Reply-To: <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <c-7wLTEab0E723COahd4RQ2Xm13O51KugDwBgOzyWhc=.9be04f5e-80e1-493e-a3f4-bac0ed6227e2@github.com>
 <piJAaS_Q-O03Ct-hUW03xpq-r8DWvEcs88-QSjsaqas=.da44e425-2753-42a0-9c9e-b731aec69cb3@github.com>
Message-ID: <ajAOl7w94i1FUrraDquo_CGKjvdcbgM6Zj_46OIN-HE=.279e6265-a0c8-4d62-8fe3-41407f31b7bd@github.com>

On Thu, 8 Jul 2021 11:37:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl 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.
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 983:
> 
>> 981: };
>> 982: 
>> 983: void G1CollectedHeap::print_heap_after_full_collection() {
> 
> It's a bit odd to see `*_full_collection` as an API of `G1CollectedHeap`; I would have expected full-collection-only APIs in g1 full gc files.

There are quite a few "after_full_collection" methods in `G1CollectedHeap`, everything below the

  // Internal helpers used during full GC to split it up to
  // increase readability.

comment. Ultimately there will always be young/full gc specific in `G1CollectedHeap` to avoid exposing too many details to the respective collector algorithm class. I do not know whether the current division is good, but I can and will revisit this at some point later.

Fwiw, the next PR will also add a few methods for young gc that are somewhat similar. Maybe we can group them in special per gc type `G1CollectedHeap` accessor classes?

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

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


From tschatzl at openjdk.java.net  Thu Jul  8 12:21:33 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 8 Jul 2021 12:21:33 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v3]
In-Reply-To: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
Message-ID: <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>

> Hi all,
> 
> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
> 
> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
> 
> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
> 
> To keep JFR event sending in the correct order, this change includes JDK-8270018.
> 
> Thanks,
>   Thomas

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

  ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4705/files
  - new: https://git.openjdk.java.net/jdk/pull/4705/files/b5b57c06..f0506932

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

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

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


From ayang at openjdk.java.net  Thu Jul  8 12:28:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 8 Jul 2021 12:28:49 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v3]
In-Reply-To: <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
Message-ID: <-zICOFyge66WK3J8sBeTnhC8kFdqNnMALnEIKBVnsHQ=.38e67cd6-40eb-4f03-8477-db92ae762ee7@github.com>

On Thu, 8 Jul 2021 12:21:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
>> 
>> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
>> 
>> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
>> 
>> To keep JFR event sending in the correct order, this change includes JDK-8270018.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Marked as reviewed by ayang (Committer).

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

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


From rkennke at openjdk.java.net  Thu Jul  8 12:41:26 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 12:41:26 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v3]
In-Reply-To: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
Message-ID: <DQ4QQLsz0-9Nz-WeakWcqzLZMu0lJCh3yQjYYbrZE-Y=.a1ea6b3a-2a21-43fb-8433-d78727a12da0@github.com>

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Properly resolve access strength in load, cmpxchg and xchg

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/219/files
  - new: https://git.openjdk.java.net/jdk17/pull/219/files/31805dee..7647b234

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

  Stats: 78 lines in 2 files changed: 68 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/219.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/219/head:pull/219

PR: https://git.openjdk.java.net/jdk17/pull/219


From rkennke at openjdk.java.net  Thu Jul  8 12:47:15 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 12:47:15 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v4]
In-Reply-To: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
Message-ID: <5HFkesTKX9967Ne_KryaXvJ8uRO8VO_bIUzx4ektRP4=.67c13b70-706f-449a-aa81-930aaa5cb48a@github.com>

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix assert

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/219/files
  - new: https://git.openjdk.java.net/jdk17/pull/219/files/7647b234..8c48c9aa

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

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From shade at openjdk.java.net  Thu Jul  8 13:07:03 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Jul 2021 13:07:03 GMT
Subject: RFR: 8270096: Shenandoah: Optimize
 gc/shenandoah/TestRefprocSanity.java for interpreter mode
Message-ID: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>

Found this while testing Shenandoah with Zero. This configuration takes a lot of time, and eventually times out:


$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/shenandoah/TestRefprocSanity.java TEST_OPTS="JAVA_OPTIONS=-Xint"
<timeout after 1200 seconds>


With these fixes, the run time with `-Xint` is under 1 minute:


real	0m51.472s
user	3m0.366s
sys	0m5.473s


In default mode, the run time is now under 20 seconds:


real	0m20.584s
user	1m8.693s
sys	0m5.030s


This also passes with Zero (plus some Zero fixes) now.

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

Commit messages:
 - Drop the window to 1K too
 - 8270096: Shenandoah: Optimize gc/shenandoah/TestRefprocSanity.java for interpreter mode

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

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


From iwalulya at openjdk.java.net  Thu Jul  8 13:50:52 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 8 Jul 2021 13:50:52 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v3]
In-Reply-To: <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
Message-ID: <6SMOPIUSMjfN2Ivd8CRAlVTF_TzDcvxCWkE3l5_7bXs=.e83c9bd5-95b1-4047-b11a-f184241c1c2e@github.com>

On Thu, 8 Jul 2021 12:21:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
>> 
>> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
>> 
>> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
>> 
>> To keep JFR event sending in the correct order, this change includes JDK-8270018.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

lgtm!

Minor:
can we change

hpm -> heap_printer
jtm   -> tracer_mark

as done in G1FullGCScope

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

Marked as reviewed by iwalulya (Committer).

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


From shade at openjdk.java.net  Thu Jul  8 14:00:14 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Jul 2021 14:00:14 GMT
Subject: RFR: 8270094: Shenandoah: Provide human-readable labels for test
 configurations
Message-ID: <XyzbYGtVJU9dDBAa7OSs1rwt8toAyHF8W9pexJOvlm4=.cda8a6fd-5903-45b0-ac1c-722832c6b19f@github.com>

`hotspot_gc_shenandoah` contains a lot of parallel test configurations, and it would be much nicer to have them named appropriately, rather than just #id1...#id2.

Additional testing:
 - [x] `hotspot_gc_shenandoah`, eyeballing test names

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

Commit messages:
 - 8270094: Shenandoah: Provide human-readable labels for test configurations

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

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


From zgu at openjdk.java.net  Thu Jul  8 14:01:54 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 8 Jul 2021 14:01:54 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v4]
In-Reply-To: <5HFkesTKX9967Ne_KryaXvJ8uRO8VO_bIUzx4ektRP4=.67c13b70-706f-449a-aa81-930aaa5cb48a@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
 <5HFkesTKX9967Ne_KryaXvJ8uRO8VO_bIUzx4ektRP4=.67c13b70-706f-449a-aa81-930aaa5cb48a@github.com>
Message-ID: <S8dMQIyfQmqcwSwEyKDojoSWJ9gxZE81u4JE13oWUfg=.19198298-405b-4461-8e52-fd1c18251bf4@github.com>

On Thu, 8 Jul 2021 12:47:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assert

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 643:

> 641:     }
> 642: #endif
> 643:     load_store = kit->gvn().transform(new ShenandoahLoadReferenceBarrierNode(NULL, load_store, access.decorators() & ~ON_UNKNOWN_OOP_REF));

This load should go through slow path when GC is in progress, right? Should let slow path to resolve the strength? sounds there is possibility to resurrect dead oop.

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From zgu at openjdk.java.net  Thu Jul  8 14:08:51 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 8 Jul 2021 14:08:51 GMT
Subject: RFR: 8270094: Shenandoah: Provide human-readable labels for test
 configurations
In-Reply-To: <XyzbYGtVJU9dDBAa7OSs1rwt8toAyHF8W9pexJOvlm4=.cda8a6fd-5903-45b0-ac1c-722832c6b19f@github.com>
References: <XyzbYGtVJU9dDBAa7OSs1rwt8toAyHF8W9pexJOvlm4=.cda8a6fd-5903-45b0-ac1c-722832c6b19f@github.com>
Message-ID: <SpWEhvmU19WuPBpsMXymSPNhn9wtXMOOIDq9dnGEK4c=.ad11708d-89cc-4448-b2bb-18d82c311c59@github.com>

On Thu, 8 Jul 2021 13:54:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `hotspot_gc_shenandoah` contains a lot of parallel test configurations, and it would be much nicer to have them named appropriately, rather than just #id1...#id2.
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`, eyeballing test names

Good to me

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

Marked as reviewed by zgu (Reviewer).

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


From simonis at openjdk.java.net  Thu Jul  8 15:25:04 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Thu, 8 Jul 2021 15:25:04 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
Message-ID: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>

If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:

[0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
[0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]

Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.

Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:

[13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
[13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K


The fix is trivial.

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

Commit messages:
 - 8270100: Fix some inaccurate GC logging

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

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


From zgu at openjdk.java.net  Thu Jul  8 16:01:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 8 Jul 2021 16:01:53 GMT
Subject: RFR: 8270096: Shenandoah: Optimize
 gc/shenandoah/TestRefprocSanity.java for interpreter mode
In-Reply-To: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>
References: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>
Message-ID: <HzqxgkJloR0g9hDFuu2Bnh7EwwPv0Ptr97f9J14ipSg=.6e7af0db-5532-486d-a08e-9f393cc43a3b@github.com>

On Thu, 8 Jul 2021 12:59:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found this while testing Shenandoah with Zero. This configuration takes a lot of time, and eventually times out:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/shenandoah/TestRefprocSanity.java TEST_OPTS="JAVA_OPTIONS=-Xint"
> <timeout after 1200 seconds>
> 
> 
> With these fixes, the run time with `-Xint` is under 1 minute:
> 
> 
> real	0m51.472s
> user	3m0.366s
> sys	0m5.473s
> 
> 
> In default mode, the run time is now under 20 seconds:
> 
> 
> real	0m20.584s
> user	1m8.693s
> sys	0m5.030s
> 
> 
> This also passes with Zero (plus some Zero fixes) now.

Looks good to me.

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

Marked as reviewed by zgu (Reviewer).

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


From shade at openjdk.java.net  Thu Jul  8 16:46:02 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Jul 2021 16:46:02 GMT
Subject: Integrated: 8270096: Shenandoah: Optimize
 gc/shenandoah/TestRefprocSanity.java for interpreter mode
In-Reply-To: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>
References: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>
Message-ID: <5-XsEjUXMByJHbgIOywqfPki1-B8TuPD5ootQeqsEgY=.dcc0c0e4-533a-47a3-8333-b20798aa9264@github.com>

On Thu, 8 Jul 2021 12:59:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found this while testing Shenandoah with Zero. This configuration takes a lot of time, and eventually times out:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/shenandoah/TestRefprocSanity.java TEST_OPTS="JAVA_OPTIONS=-Xint"
> <timeout after 1200 seconds>
> 
> 
> With these fixes, the run time with `-Xint` is under 1 minute:
> 
> 
> real	0m51.472s
> user	3m0.366s
> sys	0m5.473s
> 
> 
> In default mode, the run time is now under 20 seconds:
> 
> 
> real	0m20.584s
> user	1m8.693s
> sys	0m5.030s
> 
> 
> This also passes with Zero (plus some Zero fixes) now.

This pull request has now been integrated.

Changeset: 4f322a9b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4f322a9b6c9cfdf080df23326daa45733f1b9aad
Stats:     17 lines in 1 file changed: 7 ins; 0 del; 10 mod

8270096: Shenandoah: Optimize gc/shenandoah/TestRefprocSanity.java for interpreter mode

Reviewed-by: zgu

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

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


From shade at openjdk.java.net  Thu Jul  8 16:46:01 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Jul 2021 16:46:01 GMT
Subject: RFR: 8270096: Shenandoah: Optimize
 gc/shenandoah/TestRefprocSanity.java for interpreter mode
In-Reply-To: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>
References: <4PhHOGTQrjGVKUFDmomEdyifdQpu0WI4r-nw0fvEdJY=.647f9dbc-5f70-4dd2-9203-8b0e6eb41914@github.com>
Message-ID: <pj2-IdFGrnN4LzgInIb1_kz92z0vZNHfYP-OP_RQcGM=.cc96b99a-4027-425e-92fc-828d9a3a268e@github.com>

On Thu, 8 Jul 2021 12:59:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found this while testing Shenandoah with Zero. This configuration takes a lot of time, and eventually times out:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=gc/shenandoah/TestRefprocSanity.java TEST_OPTS="JAVA_OPTIONS=-Xint"
> <timeout after 1200 seconds>
> 
> 
> With these fixes, the run time with `-Xint` is under 1 minute:
> 
> 
> real	0m51.472s
> user	3m0.366s
> sys	0m5.473s
> 
> 
> In default mode, the run time is now under 20 seconds:
> 
> 
> real	0m20.584s
> user	1m8.693s
> sys	0m5.030s
> 
> 
> This also passes with Zero (plus some Zero fixes) now.

Thanks! There is only one unrelated failure in GHA testing.

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

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


From rkennke at openjdk.java.net  Thu Jul  8 18:36:10 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 18:36:10 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible
Message-ID: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>

We've observed test failures in jcstress, see:
https://bugs.openjdk.java.net/browse/JDK-8269897

We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.

A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.

Testing:
 - [x] the provided jcstress test
 - [x] hotspot_gc_shenandoah
 - [x] tier1

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

Commit messages:
 - Determine access strength in all runtime barriers, where possible
 - Treat UNKNOWN as STRONG more selectively only on CAE
 - 8269897: Shenandoah: Treat UNKNOWN refs access as strong

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

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


From rkennke at openjdk.java.net  Thu Jul  8 18:36:10 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 18:36:10 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible
In-Reply-To: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
Message-ID: <T2y8pcal71RpD-hEfa7mdjoBSgFvBCwdmARRv1qG0-E=.fb0c8154-2bb8-481c-ac44-cde3d658521a@github.com>

On Tue, 6 Jul 2021 19:00:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Closing and retargeting to jdk17.

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

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


From rkennke at openjdk.java.net  Thu Jul  8 18:40:33 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 18:40:33 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v2]
In-Reply-To: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
Message-ID: <XXQ-iSh6KBFHP07xQ9IBgCbew0bmmLGfgRp9wQ7onnI=.19624dd5-e066-42ae-9be9-cb55588f957c@github.com>

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Revert C2 changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4697/files
  - new: https://git.openjdk.java.net/jdk/pull/4697/files/99e11285..c2e666b9

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

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

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


From rkennke at openjdk.java.net  Thu Jul  8 20:02:56 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 20:02:56 GMT
Subject: [jdk17] RFR: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong [v4]
In-Reply-To: <5HFkesTKX9967Ne_KryaXvJ8uRO8VO_bIUzx4ektRP4=.67c13b70-706f-449a-aa81-930aaa5cb48a@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
 <5HFkesTKX9967Ne_KryaXvJ8uRO8VO_bIUzx4ektRP4=.67c13b70-706f-449a-aa81-930aaa5cb48a@github.com>
Message-ID: <UvoenLJF3N9fM7oXRcrnVCYWWhNxONCKJH5uFxwxdhw=.0b1b7edc-87a9-4140-a31f-f8ab1121af24@github.com>

On Thu, 8 Jul 2021 12:47:15 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assert

Fixing this in jdk18 first, should backport to jdk17 later, after some testing in 18. See: https://github.com/openjdk/jdk/pull/4697

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From rkennke at openjdk.java.net  Thu Jul  8 20:02:57 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Jul 2021 20:02:57 GMT
Subject: [jdk17] Withdrawn: 8269897: Shenandoah: Treat UNKNOWN refs access as
 strong
In-Reply-To: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
References: <edntEJOLnwMNumWrkh0KCwiZdIdi3UoH9VKmJORDDYM=.97751e35-678f-4574-8d50-c8d585d32cb8@github.com>
Message-ID: <tjwFtDTNTivfkqYpH6i7BtR7R1Z7axMt5w04NLyYVdQ=.5ac06ecf-f77e-4b74-be1b-4d1bc5f618b5@github.com>

On Tue, 6 Jul 2021 19:11:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk17/pull/219


From kbarrett at openjdk.java.net  Fri Jul  9 05:40:54 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 9 Jul 2021 05:40:54 GMT
Subject: RFR: 8270082: Remove unnecessary gc_timer null check in
 ReferenceProcessorPhaseTimes
In-Reply-To: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
References: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
Message-ID: <mLzlg2ILom8mBWvrz53Rjy17H4u2hZ520du89ssoZyo=.881d4122-66c8-4d58-bfe5-33f7527442e8@github.com>

On Thu, 8 Jul 2021 09:49:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a null check.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Fri Jul  9 05:44:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 9 Jul 2021 05:44:50 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider
In-Reply-To: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
Message-ID: <PKCAt1K5qEqiZ5aQ7b9EMXoMwOgUFHceFYkaSD_PCyc=.47fc0fad-6bff-4f5f-95df-59666a3a8a17@github.com>

On Fri, 2 Jul 2021 12:59:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

I would prefer to have the renaming done in a separate PR.

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

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


From kbarrett at openjdk.java.net  Fri Jul  9 05:50:51 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 9 Jul 2021 05:50:51 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v3]
In-Reply-To: <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
Message-ID: <zzuPh-i4Br4dCdiImxoXwGqeSJbNhjeHvQle2SatW3k=.ebf2caac-e80d-44dd-a73a-b47a89573b16@github.com>

On Thu, 8 Jul 2021 12:21:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
>> 
>> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
>> 
>> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
>> 
>> To keep JFR event sending in the correct order, this change includes JDK-8270018.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Jul  9 06:54:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 9 Jul 2021 06:54:56 GMT
Subject: RFR: 8269914: Factor out heap printing for G1 young and full gc
 [v3]
In-Reply-To: <-zICOFyge66WK3J8sBeTnhC8kFdqNnMALnEIKBVnsHQ=.38e67cd6-40eb-4f03-8477-db92ae762ee7@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
 <dFNGyN2eMvh7zaM6aLHInNgurfWWS54dDDZn57xHAbw=.d8430395-283a-4086-bc49-d05e1a42094e@github.com>
 <-zICOFyge66WK3J8sBeTnhC8kFdqNnMALnEIKBVnsHQ=.38e67cd6-40eb-4f03-8477-db92ae762ee7@github.com>
Message-ID: <MkWZhsKQ0xZIWMriweRCOoCajQoBOKkctEMisQBpZ-U=.fe847309-2ec2-46a4-8166-4837fbd8e4f6@github.com>

On Thu, 8 Jul 2021 12:25:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks @albertnetymk @kimbarrett @walulyai for your reviews.

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

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


From tschatzl at openjdk.java.net  Fri Jul  9 06:54:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 9 Jul 2021 06:54:57 GMT
Subject: Integrated: 8269914: Factor out heap printing for G1 young and full gc
In-Reply-To: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
References: <0_7E6Ycr_mZ-qqTlZs-3985qPFQe5Fe9dU2dQ2MVe_c=.e839ad1f-802d-45dd-a81d-ecf9ba412c80@github.com>
Message-ID: <L1jeEz5SyA4btSiB0VoqKJFFv7UP21wRy0QrrjCz9Zk=.00eaa974-766b-4da4-844d-8aa1a7b668bc@github.com>

On Wed, 7 Jul 2021 08:23:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
> can I have reviews for this change that factors out before/after heap related printing into a single scoped object to be used for both young and full gc code?
> 
> There is some minor change in order of printing of unrelated log output (COMMIT/UNCOMMIT region state changes vs. other heap printing), during full gc but since this is very low level debugging I do not see a problem to do that.
> 
> (Sorry for the trouble with open/closing this issue already: have been experimenting with the feature to base PRs on other PRs which kind-of failed a bit; rebased on tip after being able to push all dependencies, so this one should be good)
> 
> To keep JFR event sending in the correct order, this change includes JDK-8270018.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c93204ce
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c93204ce3d4653705e6aeeadb9b3c591e469de77
Stats:     199 lines in 7 files changed: 107 ins; 62 del; 30 mod

8269914: Factor out heap printing for G1 young and full gc
8270018: Add scoped object for g1 young gc JFR notification

Reviewed-by: ayang, iwalulya, kbarrett

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

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


From shade at openjdk.java.net  Fri Jul  9 07:57:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Jul 2021 07:57:54 GMT
Subject: Integrated: 8270094: Shenandoah: Provide human-readable labels for
 test configurations
In-Reply-To: <XyzbYGtVJU9dDBAa7OSs1rwt8toAyHF8W9pexJOvlm4=.cda8a6fd-5903-45b0-ac1c-722832c6b19f@github.com>
References: <XyzbYGtVJU9dDBAa7OSs1rwt8toAyHF8W9pexJOvlm4=.cda8a6fd-5903-45b0-ac1c-722832c6b19f@github.com>
Message-ID: <9UMCrzvn0D3vHMMhFULWzN-UkG4oWfG9SpRiZH7WYE0=.87c840d1-4c84-44ca-ad72-7ad8f6c09b3d@github.com>

On Thu, 8 Jul 2021 13:54:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `hotspot_gc_shenandoah` contains a lot of parallel test configurations, and it would be much nicer to have them named appropriately, rather than just #id1...#id2.
> 
> Additional testing:
>  - [x] `hotspot_gc_shenandoah`, eyeballing test names

This pull request has now been integrated.

Changeset: 676f1d76
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/676f1d76cab9108655f2ce462db321b975563eb7
Stats:     227 lines in 81 files changed: 19 ins; 0 del; 208 mod

8270094: Shenandoah: Provide human-readable labels for test configurations

Reviewed-by: zgu

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

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


From ayang at openjdk.java.net  Fri Jul  9 08:08:19 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 08:08:19 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider [v2]
In-Reply-To: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
Message-ID: <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

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

  Revert "rename"
  
  This reverts commit 740e18530eae4be0824398c156ae4ce3634b4e1e.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4667/files
  - new: https://git.openjdk.java.net/jdk/pull/4667/files/740e1853..22d5605d

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

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

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


From ayang at openjdk.java.net  Fri Jul  9 08:08:19 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 08:08:19 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider
In-Reply-To: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
Message-ID: <ZD5CvSHm5lvsJ_WfBMhvD4Sc8eZI0Kamf42XLDdTpCM=.bb08efcc-7127-4c33-a00e-84ce1c038cd2@github.com>

On Fri, 2 Jul 2021 12:59:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

I have reverted the renaming commit; this PR effectively contains only the first two commits.

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

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


From ayang at openjdk.java.net  Fri Jul  9 08:08:55 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 08:08:55 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
Message-ID: <n95VuR82cba1VJd_x8J5tMol1xM4DYMS3FpT6ocCOTI=.3bc83aea-3893-4700-9076-b2806adf8d87@github.com>

On Thu, 8 Jul 2021 15:19:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

Can you share the complete flags and the benchmark for easy reproducing? Somehow I can't reproduce the gc logs; the flags and the benchmark I used:

`java -XX:+UseSerialGC -Xms2g -Xmx2g  '-Xlog:gc,gc+heap*=trace:gc.log::filecount=0' -jar dacapo-9.12-MR1-bach.jar h2 -s huge -n 1`

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

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


From ayang at openjdk.java.net  Fri Jul  9 10:06:59 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 10:06:59 GMT
Subject: RFR: 8270082: Remove unnecessary gc_timer null check in
 ReferenceProcessorPhaseTimes
In-Reply-To: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
References: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
Message-ID: <urJkYIXJMcuu7UVY7Osl4EsaIpyYunDXtjsMKOEPzjo=.742e9dd9-656f-4898-8bde-44f413b64c21@github.com>

On Thu, 8 Jul 2021 09:49:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a null check.

Thanks for the review.

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

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


From ayang at openjdk.java.net  Fri Jul  9 10:06:59 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 10:06:59 GMT
Subject: Integrated: 8270082: Remove unnecessary gc_timer null check in
 ReferenceProcessorPhaseTimes
In-Reply-To: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
References: <gzZ4Nt2OzQUk8mL16bTcX45IQXjLVBPK6oAWxXBGVY0=.61bbb6c7-a537-4065-97e1-fd28e9c63904@github.com>
Message-ID: <n7ovkjGB0RIa1E49qJktSbXnmzQ5iMhFOaWTT5uuIL0=.fdf8ce5d-e40f-476e-b35b-3e4ccc58997d@github.com>

On Thu, 8 Jul 2021 09:49:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of removing a null check.

This pull request has now been integrated.

Changeset: 3d193adb
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d193adbec07a77dce3b34fe5d0dbb99ff03b9a7
Stats:     8 lines in 1 file changed: 0 ins; 4 del; 4 mod

8270082: Remove unnecessary gc_timer null check in ReferenceProcessorPhaseTimes

Reviewed-by: tschatzl, kbarrett

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

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


From shade at openjdk.java.net  Fri Jul  9 10:48:51 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Jul 2021 10:48:51 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v2]
In-Reply-To: <XXQ-iSh6KBFHP07xQ9IBgCbew0bmmLGfgRp9wQ7onnI=.19624dd5-e066-42ae-9be9-cb55588f957c@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
 <XXQ-iSh6KBFHP07xQ9IBgCbew0bmmLGfgRp9wQ7onnI=.19624dd5-e066-42ae-9be9-cb55588f957c@github.com>
Message-ID: <sU5d1bC82IFAr4ONh1P4V3lYgn0RBpZkGGIWyRihuyw=.44a1c212-7aa5-4d92-8a76-4677478a7c21@github.com>

On Thu, 8 Jul 2021 18:40:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert C2 changes

Looks okay to me, I am testing. 

One nit: lets assert no UNKNOWN decorators are passed to AccessBarrier methods that do not do the UNKNOWN resolve?

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

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


From shade at openjdk.java.net  Fri Jul  9 12:20:58 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Jul 2021 12:20:58 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v2]
In-Reply-To: <XXQ-iSh6KBFHP07xQ9IBgCbew0bmmLGfgRp9wQ7onnI=.19624dd5-e066-42ae-9be9-cb55588f957c@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
 <XXQ-iSh6KBFHP07xQ9IBgCbew0bmmLGfgRp9wQ7onnI=.19624dd5-e066-42ae-9be9-cb55588f957c@github.com>
Message-ID: <_oqNWhYQRm3xeTlTpnARISiGQCz1rfIBT7TyORCsj4Y=.7e621de4-9e81-46a5-b3e0-cd534e1b7926@github.com>

On Thu, 8 Jul 2021 18:40:33 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert C2 changes

Current patch passes my testing, thanks. Still think we need to do asserts for extra safety.

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

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


From zgu at openjdk.java.net  Fri Jul  9 13:17:08 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Jul 2021 13:17:08 GMT
Subject: RFR: 8270110: Shenandoah: Add test for JDK-8269661
Message-ID: <omUo7LXdRA-ZPLH9dfi-guPL7K30LT1-Uz_S5yUpVmw=.47ed7d52-c55f-47dc-ae61-0e02d02799a8@github.com>

I would like to add a test for JDK-8269661. 

Currently, JDK-8269661 only affects Shenandoah GC, as it is the only GC supports object pinning and string deduplication.

Test:
- [x] new test passes with JDK-8269661, fails after backout JDK-8269661 fix.

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

Commit messages:
 - Disable compact string
 - Merge branch 'master' into string_critical_dedup
 - update test
 - v2
 - v0

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

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


From ayang at openjdk.java.net  Fri Jul  9 13:18:07 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 13:18:07 GMT
Subject: RFR: 8270169: G1: Incorrect reference discovery MT degree in
 concurrent marking
Message-ID: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>

Simple change of ref discovery MT degree in concurrent marking.

Test: hotspot_gc

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

Commit messages:
 - cm-rp

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

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


From zgu at openjdk.java.net  Fri Jul  9 13:31:16 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Jul 2021 13:31:16 GMT
Subject: RFR: 8270171: Shenandoah: Cleanup TestStringDedup and
 TestStringDedupStress tests
Message-ID: <mnhxbIF-Ttjn9UlHyuvLpzTc0cFCbOH6q3guW6TpdCo=.47b530d1-9b23-44c7-a65b-7d321b359d1f@github.com>

Please review this trivial patch to cleanup TestStringDedup and TestStringDedupStress tests, removes unused Unsafe usages.

Test:
- [x] Both tests still pass

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

Commit messages:
 - v0

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

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


From shade at openjdk.java.net  Fri Jul  9 13:49:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Jul 2021 13:49:57 GMT
Subject: RFR: 8270171: Shenandoah: Cleanup TestStringDedup and
 TestStringDedupStress tests
In-Reply-To: <mnhxbIF-Ttjn9UlHyuvLpzTc0cFCbOH6q3guW6TpdCo=.47b530d1-9b23-44c7-a65b-7d321b359d1f@github.com>
References: <mnhxbIF-Ttjn9UlHyuvLpzTc0cFCbOH6q3guW6TpdCo=.47b530d1-9b23-44c7-a65b-7d321b359d1f@github.com>
Message-ID: <n_wmChtFH3DUtB7GpztZT0Onxw-Uq_24vcq6BsSOXEs=.a0354989-70a1-4950-9f96-8a961ea29df1@github.com>

On Fri, 9 Jul 2021 13:23:56 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to cleanup TestStringDedup and TestStringDedupStress tests, removes unused Unsafe usages.
> 
> Test:
> - [x] Both tests still pass

Ah yes, `java.lang:open` already provides this. Good!

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

Marked as reviewed by shade (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Jul  9 14:00:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 9 Jul 2021 14:00:59 GMT
Subject: RFR: 8270169: G1: Incorrect reference discovery MT degree in
 concurrent marking
In-Reply-To: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
References: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
Message-ID: <nbvns7DzBfCygqWKnM6HJWC8Yl1zdzrmNAyRtRp08zM=.e6b0270e-2f28-474b-a466-78ad9d74cd92@github.com>

On Fri, 9 Jul 2021 13:11:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of ref discovery MT degree in concurrent marking.
> 
> Test: hotspot_gc

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Fri Jul  9 14:49:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 9 Jul 2021 14:49:02 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
Message-ID: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>

Hi all,

  can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - Initial implementation of method reshuffling

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

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


From tschatzl at openjdk.java.net  Fri Jul  9 15:18:29 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 9 Jul 2021 15:18:29 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification [v3]
In-Reply-To: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
References: <Gz0Mhlg096wwi_ff6B-ommQV_w__AqHxhHUxV1lnU_g=.d1b356d2-51c3-4b46-b84a-de6364a0d5f4@github.com>
Message-ID: <cVZyXyzCtIPqt_KuzDU5CgoWNDu6-bYV5uG5nN-IMBQ=.57b2ecd9-af9f-4473-9bde-f40ece024ce7@github.com>

> Hi all,
> 
>   can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas
> 
> Note: this depends on PR4586.

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

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into 8269295-verify-time-only-covers-parts
 - Initial implementation
 - Fix young gc verify stages
 - Initial implementation

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

Changes: https://git.openjdk.java.net/jdk/pull/4587/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4587&range=02
  Stats: 28 lines in 3 files changed: 12 ins; 12 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4587.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4587/head:pull/4587

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


From tschatzl at openjdk.java.net  Fri Jul  9 15:27:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 9 Jul 2021 15:27:02 GMT
Subject: RFR: 8269295: Verification time before/after young collection only
 covers parts of the verification
Message-ID: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>

Hello,

  another mess-up of mine related to dependent merge-requests: after trying to integrate I assumed everything was fine but the bot did not agree - after the push of the base change there were merge errors. I did not notice that and just deleted the branch.
Then I tried to resurrect it, but it did not work, after the manual merge there were tons of changes. Since I'm too afraid to mess something up, I just made a new PR. Apologies for all the reviewers to be required to look at this again. :(
It looks like I'm now "healed" from dependent PRs...

Nothing changed, really - here's the original PR request text:

can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.

This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.

Testing: tier1

Thanks,
  Thomas

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

Commit messages:
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into 8269295-verify-time-only-covers-parts
 - Initial implementation
 - Fix young gc verify stages
 - Initial implementation

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

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


From rkennke at openjdk.java.net  Fri Jul  9 15:31:23 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Jul 2021 15:31:23 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v3]
In-Reply-To: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
Message-ID: <byU-01gy1UutM5I8wJOLtspOglgSEvIolgGooD4_UTg=.2aed8394-d4f3-4315-9e29-01360fcb5f26@github.com>

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Add asserts for various decorators to runtime barriers

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4697/files
  - new: https://git.openjdk.java.net/jdk/pull/4697/files/c2e666b9..307ce30b

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

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

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


From simonis at openjdk.java.net  Fri Jul  9 17:03:52 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Fri, 9 Jul 2021 17:03:52 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <n95VuR82cba1VJd_x8J5tMol1xM4DYMS3FpT6ocCOTI=.3bc83aea-3893-4700-9076-b2806adf8d87@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <n95VuR82cba1VJd_x8J5tMol1xM4DYMS3FpT6ocCOTI=.3bc83aea-3893-4700-9076-b2806adf8d87@github.com>
Message-ID: <XfEq-eHQ-VFHRQCUDet25dbTl2Zj4xIcrMWvikKwGtI=.08915b55-c02e-47cc-bd29-5da5fba5bff3@github.com>

On Fri, 9 Jul 2021 08:05:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
>> 
>> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
>> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
>> 
>> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
>> 
>> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
>> 
>> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
>> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
>> 
>> 
>> The fix is trivial.
>
> Can you share the complete flags and the benchmark for easy reproducing? Somehow I can't reproduce the gc logs; the flags and the benchmark I used:
> 
> `java -XX:+UseSerialGC -Xms2g -Xmx2g  '-Xlog:gc,gc+heap*=trace:gc.log::filecount=0' -jar dacapo-9.12-MR1-bach.jar h2 -s huge -n 1`

Hi @albertnetymk,

to see the first issue, you have to make the initial heap smaller than the the maximum heap. It can easily seen with your command line. Before the change:

$ java -XX:+UseSerialGC -Xms100m -Xmx2g '-Xlog:gc,gc+heap*=trace' -jar /share/soware/Java/dacapo-9.12-MR1-bach.jar h2 -s huge -n 1 | grep "allowed 0K extra"
[1,339s][trace][gc,ergo,heap ] GC(11)   [allowed 0K extra for 0 threads]
[2,066s][trace][gc,ergo,heap ] GC(17)   [allowed 0K extra for 0 threads]
[3,323s][trace][gc,ergo,heap ] GC(23)   [allowed 0K extra for 0 threads]
[5,560s][trace][gc,ergo,heap ] GC(29)   [allowed 0K extra for 0 threads]
...

After the change:

$ java -XX:+UseSerialGC -Xms100m -Xmx2g '-Xlog:gc,gc+heap*=trace' -jar /share/soware/Java/dacapo-9.12-MR1-bach.jar h2 -s huge -n 1 | grep "allowed 0K extra"
[1,397s][trace][gc,ergo,heap ] GC(11)   [allowed 5K extra for 1 threads]
[2,202s][trace][gc,ergo,heap ] GC(17)   [allowed 5K extra for 1 threads]
[3,468s][trace][gc,ergo,heap ] GC(23)   [allowed 5K extra for 1 threads]
[5,699s][trace][gc,ergo,heap ] GC(29)   [allowed 5K extra for 1 threads]
...
``` 

To see the second issue, you obviously will have to shrink the heap and set `-XX:-ShrinkHeapInSteps`. You can use the `Uncommit.java` program attached below. Before the change:

$ java -XX:+UseSerialGC -Xms100m -Xmx1g '-Xlog:gc,gc+heap*=trace' -XX:-ShrinkHeapInSteps Uncommit
...
[9,759s][trace][gc,heap      ] GC(11)     shrinking:  initSize: 68288,0K  maximum_desired_capacity: 90337,3K
[9,759s][trace][gc,heap      ] GC(11)     shrink_bytes: 572226,7K  current_shrink_factor: 0  new shrink factor: 0  _min_heap_delta_bytes: 192,0K
[9,780s][trace][gc,heap      ] GC(11) Shrinking tenured generation from 662564K to 90340K
...

After the change:

$ java -XX:+UseSerialGC -Xms100m -Xmx1g '-Xlog:gc,gc+heap*=trace' -XX:-ShrinkHeapInSteps Uncommit
...
[3,941s][trace][gc,heap      ] GC(11)     shrinking:  initSize: 68288,0K  maximum_desired_capacity: 92130,6K
[3,941s][trace][gc,heap      ] GC(11)     shrink_bytes: 575773,4K  current_shrink_factor: 100  new shrink factor: 100  _min_heap_delta_bytes: 192,0K
[3,958s][trace][gc,heap      ] GC(11) Shrinking tenured generation from 667904K to 92132K
...


Here's the example program:

import java.io.IOException;
import java.nio.file.FileSystems;
import java.nio.file.Files;
import java.nio.file.Path;

public class Uncommit {

  static class KB {
    int[] kb;
    public KB() {
      kb = new int[256];
    }
  }

  static class MB {
    KB[] mb;
    public MB() {
      mb = new KB[1024];
      for (int i = 0; i < mb.length; i++) {
        mb[i] = new KB();
      }
    }
  }

  static class GB {
    MB[] gb;
    public GB() {
      gb = new MB[1024];
      for (int i = 0; i < gb.length; i++) {
        gb[i] = new MB();
      }
    }
  }

  static void printRSS() throws IOException {
    Files.lines(FileSystems.getDefault().getPath("/proc/self/status")).
      filter(l -> l.startsWith("VmRSS")).
      forEach(System.out::println);
  }

  public static void main(String[] args) throws Exception {
    System.out.println("Calling System.gc()");
    System.gc();
    printRSS();
    System.out.println("\nPress <Enter>");
    System.console().readLine();

    int size = Integer.parseInt(args.length > 0 ? args[0] : "512");
    MB mb[] = new MB[size];
    for (int i = 0; i < size; i++) {
      mb[i] = new MB();
    }
    System.out.println("Successfully allocated " + size + "MB memory");
    printRSS();
    System.out.println("\nPress <Enter>");
    System.console().readLine();
    for (int i = 0; i < size; i++) {
      mb[i] = null;
    }
    System.out.println("Successfully unlinked " + size + "MB memory");
    printRSS();
    System.out.println("\nPress <Enter>");
    System.console().readLine();
    int gcs = 5;
    if (args.length > 1) {
      gcs = Integer.parseInt(args[1]);
    }
    for (int i = 1; i <= gcs; i++) {
      System.gc();
      System.out.println("Performed " + i + ". System.gc()\n");
      printRSS();
      System.out.println("Press <Enter>");
      System.console().readLine();
      }
  }
}

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

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


From shade at openjdk.java.net  Fri Jul  9 17:23:54 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Jul 2021 17:23:54 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v3]
In-Reply-To: <byU-01gy1UutM5I8wJOLtspOglgSEvIolgGooD4_UTg=.2aed8394-d4f3-4315-9e29-01360fcb5f26@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
 <byU-01gy1UutM5I8wJOLtspOglgSEvIolgGooD4_UTg=.2aed8394-d4f3-4315-9e29-01360fcb5f26@github.com>
Message-ID: <guWeYJFUpJ3CUIydMdzMsdalG-PjOmbxOzthCsYXMIQ=.fcacdd48-0131-48c2-8bc5-d8cbf960493b@github.com>

On Fri, 9 Jul 2021 15:31:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add asserts for various decorators to runtime barriers

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 128:

> 126:   class AccessBarrier: public BarrierSet::AccessBarrier<decorators, BarrierSetT> {
> 127:     typedef BarrierSet::AccessBarrier<decorators, BarrierSetT> Raw;
> 128: 

This change looks unnecessary.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 320:

> 318: template <DecoratorSet decorators, typename BarrierSetT>
> 319: inline oop ShenandoahBarrierSet::AccessBarrier<decorators, BarrierSetT>::oop_atomic_xchg_in_heap_at(oop base, ptrdiff_t offset, oop new_value) {
> 320:   assert((decorators & ON_STRONG_OOP_REF) != 0, "must be present");

Shouldn't this be `| ON_UNKNOWN_OOP_REF`? We are doing `resolve_possibly_unknown_oop_ref_strength` later.

In fact, I am not so sure about asserting `ON_STRONG_OOP_REF` here and elsewhere as well. The future `ON_WEAK_OOP_REF` code should work fine here too? I think only asserting that `ON_Uresolve_possibly_unknown_oop_ref_strengthNKNOWN_OOP_REF` is not passed on bad paths is enough?

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

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


From zgu at openjdk.java.net  Fri Jul  9 17:37:57 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Jul 2021 17:37:57 GMT
Subject: Integrated: 8270171: Shenandoah: Cleanup TestStringDedup and
 TestStringDedupStress tests
In-Reply-To: <mnhxbIF-Ttjn9UlHyuvLpzTc0cFCbOH6q3guW6TpdCo=.47b530d1-9b23-44c7-a65b-7d321b359d1f@github.com>
References: <mnhxbIF-Ttjn9UlHyuvLpzTc0cFCbOH6q3guW6TpdCo=.47b530d1-9b23-44c7-a65b-7d321b359d1f@github.com>
Message-ID: <Lh2yjsyc9P_EZiWXui4ktqCmJCZSxZsqCskJF3SjKoU=.c6833945-2547-4131-80c2-55846ec6e39b@github.com>

On Fri, 9 Jul 2021 13:23:56 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to cleanup TestStringDedup and TestStringDedupStress tests, removes unused Unsafe usages.
> 
> Test:
> - [x] Both tests still pass

This pull request has now been integrated.

Changeset: e4c24f01
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4c24f01ef97de1c9a5a5faca5dd8ea2ad8c62d9
Stats:     20 lines in 2 files changed: 0 ins; 19 del; 1 mod

8270171: Shenandoah: Cleanup TestStringDedup and TestStringDedupStress tests

Reviewed-by: shade

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

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


From kbarrett at openjdk.java.net  Fri Jul  9 20:27:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 9 Jul 2021 20:27:50 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider [v2]
In-Reply-To: <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
 <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>
Message-ID: <jJaECenZHnjRAoCVwSR3Nvnsgh8aPAHAw9eOHqBVXEA=.f4a8aee5-59a4-4ab1-b523-8f902edac5e2@github.com>

On Fri, 9 Jul 2021 08:08:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR consists of 3 commits:
>> 
>> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
>> 
>> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
>> 
>> 3. Rename phase{2,3,4} to phase{1,2,3}.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "rename"
>   
>   This reverts commit 740e18530eae4be0824398c156ae4ce3634b4e1e.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Fri Jul  9 21:32:52 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 9 Jul 2021 21:32:52 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
Message-ID: <EPMTOFyvoJa2TynXNybm2k_bFzFCgi-dAol5oejuHcA=.2d5b8c7d-3398-43fc-8702-f403d741a663@github.com>

On Thu, 8 Jul 2021 15:19:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

Thank you for the instruction, with which I can reproduce both issues.

As for the first fix, `threads_count` and `thread_increase_size` don't really depend on `adjust_for_thread_increase`, right? Then how about just changing the values in the log, sth like:


int threads_count = Threads::number_of_non_daemon_threads();;
size_t thread_increase_size = threads_count * NewSizeThreadIncrease;
log_trace(gc, ergo, heap)(
        "  [allowed " SIZE_FORMAT "K extra for %d threads]",
          thread_increase_size/K, threads_count);


As for the second fix, I think the following is more symmetric:


if (ShrinkHeapInSteps) {
  // assign current_shrink_factor and _shrink_factor
} else {
  // Shink 100% to the desired value
  _shrink_factor = current_shrink_factor = 100;
}


PS: currently, the assignment of `current_shrink_factor` is done at the beginning of the method, but it's quite far from its actual usage. Maybe move it to the if-branch above.


assert(_shrink_factor <= 100, "invalid shrink factor");
size_t current_shrink_factor = _shrink_factor;
_shrink_factor = 0;

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

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


From kbarrett at openjdk.java.net  Sun Jul 11 22:38:58 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 11 Jul 2021 22:38:58 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
Message-ID: <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>

On Fri, 9 Jul 2021 14:40:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

A few minor nits, but generally looks good.  Hopefully I didn't miss anything; this kind of code rearrangement can be hard to review.  (Not that it shouldn't be done, but all the scrolling around and needing to dig through things made it hard to keep track.)

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

> 2990: void G1CollectedHeap::set_default_active_worker_threads(){
> 2991:   uint active_workers = WorkerPolicy::calc_active_workers(workers()->total_workers(),
> 2992:           workers()->active_workers(),

indentation

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

> 3018:   ResourceMark rm;
> 3019: 
> 3020:   IsGCActiveMark active_gc_mark;

Moving the IsGCActiveMark here expands the scope of is_gc_active() being true to cover areas it didn't used to.  I _think_ this is okay, but I didn't check all callers carefully.

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

> 3048:       {
> 3049:         // The elapsed time induced by the start time below deliberately elides
> 3050:         // the possible verification above.

Why is this comment being removed?

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

> 3532:   Atomic::store(&_num_regions_failed_evacuation, 0u);
> 3533: 
> 3534:   wait_for_root_region_scanning();

I kind of dislike having this wait moved here into this helper function, where I feel like it's less obvious in the flow of the collection pause.  I'd rather it was still in the main body.  And it's not like there's anything gained by waiting until after the other things that precede it in this function.  It looks like it's okay to delay the wait later than its current location though; the scan is performed using the concurrent marking threads, so other parts of the setup along the way should be fine.

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 01:37:56 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 01:37:56 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
References: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
Message-ID: <8yH-2rWAHPCACiCSm1V0R6lPgCEmSVMBHNxsqUnyhQU=.827bbe09-c36b-4eb8-a73e-e070ef6e249f@github.com>

On Fri, 9 Jul 2021 15:19:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hello,
> 
>   another mess-up of mine related to dependent merge-requests: after trying to integrate I assumed everything was fine but the bot did not agree - after the push of the base change there were merge errors. I did not notice that and just deleted the branch.
> Then I tried to resurrect it, but it did not work, after the manual merge there were tons of changes. Since I'm too afraid to mess something up, I just made a new PR. Apologies for all the reviewers to be required to look at this again. :(
> It looks like I'm now "healed" from dependent PRs...
> 
> Nothing changed, really - here's the original PR request text:
> 
> can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From mli at openjdk.java.net  Mon Jul 12 02:55:02 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 12 Jul 2021 02:55:02 GMT
Subject: RFR: 8269870: PS: Membar in
 PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed
Message-ID: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>

Membar in PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed.
( Please also refer to the similar membar relaxed in G1ParScanThreadState::do_copy_to_survivor_space )

Per the specjbb2015 test results, it has about 8% improvement in critical.
https://bugs.openjdk.java.net/secure/attachment/95445/jdk17_default_options.v2.png

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

Commit messages:
 - move copy back
 - Optimize PS by moving copying after forwarding successfully during evac

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 04:59:56 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 04:59:56 GMT
Subject: RFR: 8269870: PS: Membar in
 PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed
In-Reply-To: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
References: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
Message-ID: <rm9VqGCjbJMJz-AgjDuMgmaFaJmfJx8CQwtzVZI_PjY=.e851e73a-15d6-481f-b1b5-dfe859231259@github.com>

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

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

A change of this kind requires careful analysis and supporting arguments that it is correct.  As mentioned in the bug comments, this same change was proposed and extensively discussed previously (JDK-8154736), and rejected.  What has changed that makes this even worth discussing again?  It is the responsibility of the author to make those arguments and provide the needed evidence.

Simply referring to a similar part of G1 is not sufficient evidence for the correctness of this change.  G1 and Parallel have significant differences; it cannot be assumed that something that works for one will work for the other.

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

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


From ayang at openjdk.java.net  Mon Jul 12 07:23:52 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 07:23:52 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
Message-ID: <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>

On Fri, 9 Jul 2021 14:40:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Only minor comments regarding certain names.

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

> 2988: }
> 2989: 
> 2990: void G1CollectedHeap::set_default_active_worker_threads(){

The name, `set_default_active_worker_threads`, is quite generic, suggesting it's called from multiple places. However, it's actually only for the incremental evacuation pause, right? If so, it's probably clearer to include "evacuation" in the name, IMO.

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

> 3849:   prepare_tlabs_for_mutator();
> 3850: 
> 3851:   gc_epilogue(false);

I wonder if `gc_epilogue` could be made more explicit about what it includes, like its neighbors.

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

Marked as reviewed by ayang (Committer).

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


From tschatzl at openjdk.java.net  Mon Jul 12 07:34:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 07:34:56 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider [v2]
In-Reply-To: <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
 <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>
Message-ID: <LKInr2l3-1ypsLCjJH80GeQfi85DbvueHjdwv4gPxEw=.e554d212-0813-4ff7-a41d-6f3ad95d8842@github.com>

On Fri, 9 Jul 2021 08:08:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR consists of 3 commits:
>> 
>> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
>> 
>> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
>> 
>> 3. Rename phase{2,3,4} to phase{1,2,3}.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "rename"
>   
>   This reverts commit 740e18530eae4be0824398c156ae4ce3634b4e1e.

Marked as reviewed by tschatzl (Reviewer).

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

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


From iwalulya at openjdk.java.net  Mon Jul 12 07:40:54 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 12 Jul 2021 07:40:54 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
References: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
Message-ID: <AaEHpzMGkWCw4m2I5MBSwRl9XrXw4vkE26RFuKYcRh0=.cd284e8c-6a33-4dab-9a70-d1bbfb94e810@github.com>

On Fri, 9 Jul 2021 15:19:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hello,
> 
>   another mess-up of mine related to dependent merge-requests: after trying to integrate I assumed everything was fine but the bot did not agree - after the push of the base change there were merge errors. I did not notice that and just deleted the branch.
> Then I tried to resurrect it, but it did not work, after the manual merge there were tons of changes. Since I'm too afraid to mess something up, I just made a new PR. Apologies for all the reviewers to be required to look at this again. :(
> It looks like I'm now "healed" from dependent PRs...
> 
> Nothing changed, really - here's the original PR request text:
> 
> can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas

lgtm!

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

Marked as reviewed by iwalulya (Committer).

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


From tschatzl at openjdk.java.net  Mon Jul 12 07:52:56 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 07:52:56 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
Message-ID: <IRng_v-aWM4UdIu7fq57YtmHUC68jN4RfBpr7lyUymc=.32eb9b49-323e-4f47-af37-4bd74abfd96a@github.com>

On Sun, 11 Jul 2021 22:06:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3020:
> 
>> 3018:   ResourceMark rm;
>> 3019: 
>> 3020:   IsGCActiveMark active_gc_mark;
> 
> Moving the IsGCActiveMark here expands the scope of is_gc_active() being true to cover areas it didn't used to.  I _think_ this is okay, but I didn't check all callers carefully.

None of the code before that (verification, timing setup, heap printing) should be dependent on that. Actually I was considering moving the mark right after the guarantee in `G1CollectedHeap::do_collection_pause_at_safepoint`, but then I reconsidered due to the `GCLocker` check there.

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

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


From ayang at openjdk.java.net  Mon Jul 12 07:56:55 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 07:56:55 GMT
Subject: RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider [v2]
In-Reply-To: <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
 <e-prjuyEbQd1NuJNipvnNFNYEYc4p1uyhoOLws70cwk=.44379b51-fcd3-44a3-af35-135036937dab@github.com>
Message-ID: <jFj1B9MaM0KJXa40e2e_P8miDwlE3wlPlAJl8UeonPY=.7c727a46-3227-4ccd-a810-56fa1591787c@github.com>

On Fri, 9 Jul 2021 08:08:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR consists of 3 commits:
>> 
>> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
>> 
>> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
>> 
>> 3. Rename phase{2,3,4} to phase{1,2,3}.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "rename"
>   
>   This reverts commit 740e18530eae4be0824398c156ae4ce3634b4e1e.

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Jul 12 07:56:56 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 07:56:56 GMT
Subject: Integrated: 8051680: (ref) unnecessary process_soft_ref_reconsider
In-Reply-To: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
References: <zjNxv6pX_hPoQguokwJTsYYaNKzMCaTfrVVl6EoDLm0=.8fb47675-c65d-4d81-9a9c-64b50e965828@github.com>
Message-ID: <cy5tDi0ugWXXmmRtI8FFd6hqF1jWJ-UZd8XfRcBU0dk=.33210f66-33a2-4e2b-9bda-fd377dfa69ec@github.com>

On Fri, 2 Jul 2021 12:59:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8051680: (ref) unnecessary process_soft_ref_reconsider

Reviewed-by: kbarrett, tschatzl

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 08:03:02 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 08:03:02 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
Message-ID: <TyXqDx77dh8SlElDMs_q8gGysVo_jqAdf4nBTE3T1_U=.ebaa85b7-eb14-44e2-be26-e47b898a001b@github.com>

On Sun, 11 Jul 2021 22:31:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3534:
> 
>> 3532:   Atomic::store(&_num_regions_failed_evacuation, 0u);
>> 3533: 
>> 3534:   wait_for_root_region_scanning();
> 
> I kind of dislike having this wait moved here into this helper function, where I feel like it's less obvious in the flow of the collection pause.  I'd rather it was still in the main body.  And it's not like there's anything gained by waiting until after the other things that precede it in this function.  It looks like it's okay to delay the wait later than its current location though; the scan is performed using the concurrent marking threads, so other parts of the setup along the way should be fine.

I came to the same conclusion and considering that waiting as a candidate for putting it into the going-to-be parallel pre-evacuation phase. Then again, it might not be useful to have both the concurrent worker threads and parallel threads working at the same time (for performance reasons only; I do not consider the potential parallel verification also using the parallel worker threads as an issue). I checked that verification does not interfere with it (i.e. verification does not care about the mark bitmap in that sense).
The only requirement I can see is that all of these root-region objects need to have their referents marked, i.e. they must not be overwritten in some way, which this place guarantees as well, and to me it seems a more fitting place.

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 08:03:01 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 08:03:01 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>
Message-ID: <S-tF7BLZhcEp8F25LgVHQ_tNS5--2EXnUmLAms_h7Ws=.96f3732e-b44d-469a-962d-8745dd18e0ef@github.com>

On Mon, 12 Jul 2021 07:15:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2990:
> 
>> 2988: }
>> 2989: 
>> 2990: void G1CollectedHeap::set_default_active_worker_threads(){
> 
> The name, `set_default_active_worker_threads`, is quite generic, suggesting it's called from multiple places. However, it's actually only for the incremental evacuation pause, right? If so, it's probably clearer to include "evacuation" in the name, IMO.

Renamed to `set_young_collection_default_active_worker_threads`.

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 08:12:03 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 08:12:03 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>
Message-ID: <uE0PtQiFlbkghqRWikcZGlUNR_kmc6WLBS-GcU4JV-o=.e7524629-d756-4e12-823b-57a1e50f2aa0@github.com>

On Mon, 12 Jul 2021 07:18:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3851:
> 
>> 3849:   prepare_tlabs_for_mutator();
>> 3850: 
>> 3851:   gc_epilogue(false);
> 
> I wonder if `gc_epilogue` could be made more explicit about what it includes, like its neighbors.

Not sure what you expect here. The only change (similar to `gc_prologue`) is to remove potentially parallelizable code (TLAB handling), and that it is now part of the "actual collection" scope. I added some comments to indicate what scope in the method is supposed to handle what.

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

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


From simonis at openjdk.java.net  Mon Jul 12 08:24:52 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 12 Jul 2021 08:24:52 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
Message-ID: <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>

On Thu, 8 Jul 2021 15:19:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

`threads_count` and `adjust_for_thread_increase` get computed in `adjust_for_thread_increase()`. That's why they are passed in by reference. I don't think it makes sense to duplicate the computation of `threads_count` and `adjust_for_thread_increase` before we log them because the next time somebody will change `adjust_for_thread_increase()`, the values will be wrong again. This error occurred in the first place because [JDK-8144527](https://bugs.openjdk.java.net/browse/JDK-8144527) has factored out the computation of `threads_count` and `adjust_for_thread_increase` into the new  `adjust_for_thread_increase()` function, but did not pass the values back for logging.

For the second fix, I don't see why assigning to 100 to `_shrink_factor` and `current_shrink_factor` should be any better? These values aren't used except for logging if `ShrinkHeapInSteps` is false. Also, the assignment of `current_shrink_factor` can't easily be moved into the if-branch because `_shrink_factor` has to be reset to 0 before we potentially expand the heap (see comment `But if we recompute size without shrinking, it goes back to 0%.`). But on heap expansion, we'll return from the method early, before even reaching the shrinking logic.

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

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


From mli at openjdk.java.net  Mon Jul 12 08:39:56 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Mon, 12 Jul 2021 08:39:56 GMT
Subject: RFR: 8269870: PS: Membar in
 PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed
In-Reply-To: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
References: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
Message-ID: <Af0-wtcAwAo2Rt7u50n9xMDrW68Yp3JlqrzsZfcsNHo=.59e018ac-66c0-4acf-9326-c1d534a7431e@github.com>

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

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

I thought it's because of some log message in PS which needs to refer to forwardee's content, and the log messages is now gone.
But let me do a more comprehensive investigation, will update later.

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 08:43:58 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 08:43:58 GMT
Subject: RFR: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <AaEHpzMGkWCw4m2I5MBSwRl9XrXw4vkE26RFuKYcRh0=.cd284e8c-6a33-4dab-9a70-d1bbfb94e810@github.com>
References: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
 <AaEHpzMGkWCw4m2I5MBSwRl9XrXw4vkE26RFuKYcRh0=.cd284e8c-6a33-4dab-9a70-d1bbfb94e810@github.com>
Message-ID: <UBMa_pYqyo0EuscOn_9L2epfZbcRzYfIt0F5Rb_qVCg=.1c44b859-7b87-4580-8385-09824d7d9ee2@github.com>

On Mon, 12 Jul 2021 07:37:43 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hello,
>> 
>>   another mess-up of mine related to dependent merge-requests: after trying to integrate I assumed everything was fine but the bot did not agree - after the push of the base change there were merge errors. I did not notice that and just deleted the branch.
>> Then I tried to resurrect it, but it did not work, after the manual merge there were tons of changes. Since I'm too afraid to mess something up, I just made a new PR. Apologies for all the reviewers to be required to look at this again. :(
>> It looks like I'm now "healed" from dependent PRs...
>> 
>> Nothing changed, really - here's the original PR request text:
>> 
>> can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
>> 
>> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
>> 
>> Testing: tier1
>> 
>> Thanks,
>>   Thomas
>
> lgtm!

Thanks @walulyai @kimbarrett for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 08:43:59 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 08:43:59 GMT
Subject: Integrated: 8269295: Verification time before/after young collection
 only covers parts of the verification
In-Reply-To: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
References: <2lLs5bJb6-DjdLYd3chy3NxcJ5JcWu1zhPyzxI67OtI=.c47f9054-4b2c-470e-b0be-a04890177c82@github.com>
Message-ID: <htf7fsR5cSsjvHB38yfN8cssDIq9RH_Qpgquqm4Vem0=.41f16fe8-32c8-445b-b059-4acd6d9bf779@github.com>

On Fri, 9 Jul 2021 15:19:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hello,
> 
>   another mess-up of mine related to dependent merge-requests: after trying to integrate I assumed everything was fine but the bot did not agree - after the push of the base change there were merge errors. I did not notice that and just deleted the branch.
> Then I tried to resurrect it, but it did not work, after the manual merge there were tons of changes. Since I'm too afraid to mess something up, I just made a new PR. Apologies for all the reviewers to be required to look at this again. :(
> It looks like I'm now "healed" from dependent PRs...
> 
> Nothing changed, really - here's the original PR request text:
> 
> can I have reviews for this change that makes "Verify Before/After GC" contain all young collection time instead only a (large) part.
> 
> This change also removed some unnecessary and unused return values. They can certainly be re-added if necessary.
> 
> Testing: tier1
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 8973867f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8973867fb9568a3a527b763c9ce10cebdfb306d0
Stats:     28 lines in 3 files changed: 12 ins; 12 del; 4 mod

8269295: Verification time before/after young collection only covers parts of the verification

Reviewed-by: kbarrett, iwalulya

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 08:46:31 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 08:46:31 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v2]
In-Reply-To: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
Message-ID: <XCJtH4GT4n_HLe8uKMsjsfaz1bQUxh1EF-P-9VUOyUM=.b1aa1245-049f-4459-aa39-e48ab7bbdb12@github.com>

> Hi all,
> 
>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

  ayang, kbarrett reviews

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4744/files
  - new: https://git.openjdk.java.net/jdk/pull/4744/files/b2837417..b8fd8e09

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

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 09:33:58 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 09:33:58 GMT
Subject: RFR: 8269870: PS: Membar in
 PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed
In-Reply-To: <Af0-wtcAwAo2Rt7u50n9xMDrW68Yp3JlqrzsZfcsNHo=.59e018ac-66c0-4acf-9326-c1d534a7431e@github.com>
References: <E5H-cthfCt-l8PuvxIFcaEia2Ng5auw0ejiBNFGMiXY=.fcb6d819-e09c-4eb7-bda4-e6eb752c5c67@github.com>
 <Af0-wtcAwAo2Rt7u50n9xMDrW68Yp3JlqrzsZfcsNHo=.59e018ac-66c0-4acf-9326-c1d534a7431e@github.com>
Message-ID: <OqmMeu9cJUsLlyNr1ZnCSwZcrUU6UrCR_PUynkQn3dU=.139ae16e-5858-4e79-9176-1a4d6daac7f0@github.com>

On Mon, 12 Jul 2021 08:36:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

> I thought it's because of some log message in PS which needs to refer to forwardee's content, and the log messages is now gone.

Those were the immediately obvious reasons why it didn't work.  But there was also discussion about the problems that could arise because the forwardee was being returned to various places that might also have problems.  And even if they didn't at the time, there was concern over the fragility that would result, as those places using the "copied" object would need to always be careful about touching the contents of the object.

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

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


From ayang at openjdk.java.net  Mon Jul 12 10:32:08 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 10:32:08 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
Message-ID: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>

Simple rename of phase{2,3,4} to something with semantic meaning.

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

Commit messages:
 - phase1-rename

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

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


From rkennke at openjdk.java.net  Mon Jul 12 10:34:07 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Jul 2021 10:34:07 GMT
Subject: RFR: 8270110: Shenandoah: Add test for JDK-8269661
In-Reply-To: <omUo7LXdRA-ZPLH9dfi-guPL7K30LT1-Uz_S5yUpVmw=.47ed7d52-c55f-47dc-ae61-0e02d02799a8@github.com>
References: <omUo7LXdRA-ZPLH9dfi-guPL7K30LT1-Uz_S5yUpVmw=.47ed7d52-c55f-47dc-ae61-0e02d02799a8@github.com>
Message-ID: <h6YNBGXpUvd-coW5TNYKvAe-RVPg7H4umsX5OXfzLY4=.f195f74f-24c1-4626-9cc8-cb76303b25dc@github.com>

On Fri, 9 Jul 2021 13:07:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to add a test for JDK-8269661. 
> 
> Currently, JDK-8269661 only affects Shenandoah GC, as it is the only GC supports object pinning and string deduplication.
> 
> Test:
> - [x] new test passes with JDK-8269661, fails after backout JDK-8269661 fix.

Marked as reviewed by rkennke (Reviewer).

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

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


From iwalulya at openjdk.java.net  Mon Jul 12 10:38:54 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 12 Jul 2021 10:38:54 GMT
Subject: RFR: 8270169: G1: Incorrect reference discovery MT degree in
 concurrent marking
In-Reply-To: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
References: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
Message-ID: <ep_XwmzuuE4SkHiZzOjiFB6yE6R3K1Q4wjChV6ku_0Y=.2ab429b9-212d-46f1-9ed9-a628a8bbc697@github.com>

On Fri, 9 Jul 2021 13:11:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of ref discovery MT degree in concurrent marking.
> 
> Test: hotspot_gc

Marked as reviewed by iwalulya (Committer).

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 10:50:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 10:50:50 GMT
Subject: RFR: 8270169: G1: Incorrect reference discovery MT degree in
 concurrent marking
In-Reply-To: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
References: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
Message-ID: <7L_bh1bhtb69kTdH0wpfl6__L-AI4dnT1zQfZpdXSFY=.ab42f6ef-ef64-41a3-9860-f39640d7aa31@github.com>

On Fri, 9 Jul 2021 13:11:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of ref discovery MT degree in concurrent marking.
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From rkennke at openjdk.java.net  Mon Jul 12 11:21:27 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Jul 2021 11:21:27 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v4]
In-Reply-To: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
Message-ID: <aG2dSMtK2b4BxIyvz60fbEx9IS2F7LXWNRMbcUJd01Y=.4a149877-94d9-4a5f-9e4c-d5c42e295791@github.com>

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Aleksey's comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4697/files
  - new: https://git.openjdk.java.net/jdk/pull/4697/files/307ce30b..3dcac72f

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

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 12:09:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 12:09:59 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v2]
In-Reply-To: <TyXqDx77dh8SlElDMs_q8gGysVo_jqAdf4nBTE3T1_U=.ebaa85b7-eb14-44e2-be26-e47b898a001b@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
 <TyXqDx77dh8SlElDMs_q8gGysVo_jqAdf4nBTE3T1_U=.ebaa85b7-eb14-44e2-be26-e47b898a001b@github.com>
Message-ID: <5Hx_AlMGK1-53XbgjGPwkbMPJT2U32KGuTA5tmWzfhQ=.b4969a31-5fb4-45d9-8ab5-9dcef4248e1e@github.com>

On Mon, 12 Jul 2021 07:58:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 3534:
>> 
>>> 3532:   Atomic::store(&_num_regions_failed_evacuation, 0u);
>>> 3533: 
>>> 3534:   wait_for_root_region_scanning();
>> 
>> I kind of dislike having this wait moved here into this helper function, where I feel like it's less obvious in the flow of the collection pause.  I'd rather it was still in the main body.  And it's not like there's anything gained by waiting until after the other things that precede it in this function.  It looks like it's okay to delay the wait later than its current location though; the scan is performed using the concurrent marking threads, so other parts of the setup along the way should be fine.
>
> I came to the same conclusion and considering that waiting as a candidate for putting it into the going-to-be parallel pre-evacuation phase. Then again, it might not be useful to have both the concurrent worker threads and parallel threads working at the same time (for performance reasons only; I do not consider the potential parallel verification also using the parallel worker threads as an issue). I checked that verification does not interfere with it (i.e. verification does not care about the mark bitmap in that sense).
> The only requirement I can see is that all of these root-region objects need to have their referents marked, i.e. they must not be overwritten in some way, which this place guarantees as well, and to me it seems a more fitting place.

A problem with moving it later to the new placement is that it's now included in the pause time, where it previously wasn't.  I'm not sure it should be included in the pause time, as it's not really part of this collection.  I also wonder if the root scanning ought to be done using the concurrent workers rather than the stw workers, as there are typically fewer of the former (required to not be more?).

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 12:20:57 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 12:20:57 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
In-Reply-To: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
Message-ID: <VFIY110BiNJdxxJdJwfcY75dwJiFWYg_TbW7-yr0d2Q=.502bf4b4-50fc-41d3-b718-1c629ad55af8@github.com>

On Mon, 12 Jul 2021 10:24:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple rename of phase{2,3,4} to something with semantic meaning.

Mostly looks good, except for a naming choice.

src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp line 83:

> 81:   ~ReferenceProcessorPhaseTimes();
> 82: 
> 83:   WorkerDataArray<double>* SoftWeakFinalRefsPhase_worker_time_sec() const { return _SoftWeakFinalRefsPhase_worker_time_sec; }

This is a weird function name.  I understand why, but I'm not convinced.  We have process_soft_weak_final_refs and the like, for example.

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

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


From zgu at openjdk.java.net  Mon Jul 12 12:26:00 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 12 Jul 2021 12:26:00 GMT
Subject: Integrated: 8270110: Shenandoah: Add test for JDK-8269661
In-Reply-To: <omUo7LXdRA-ZPLH9dfi-guPL7K30LT1-Uz_S5yUpVmw=.47ed7d52-c55f-47dc-ae61-0e02d02799a8@github.com>
References: <omUo7LXdRA-ZPLH9dfi-guPL7K30LT1-Uz_S5yUpVmw=.47ed7d52-c55f-47dc-ae61-0e02d02799a8@github.com>
Message-ID: <vFgmwC_r0ZyIpxWlAJhgOt6mnMrp1jt5bjICF4j0hZA=.6059d7f6-e35c-448c-8d48-facfb355b05f@github.com>

On Fri, 9 Jul 2021 13:07:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to add a test for JDK-8269661. 
> 
> Currently, JDK-8269661 only affects Shenandoah GC, as it is the only GC supports object pinning and string deduplication.
> 
> Test:
> - [x] new test passes with JDK-8269661, fails after backout JDK-8269661 fix.

This pull request has now been integrated.

Changeset: 548bb311
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/548bb3119cf792bb1e65e15e990a4addc9155312
Stats:     208 lines in 3 files changed: 207 ins; 0 del; 1 mod

8270110: Shenandoah: Add test for JDK-8269661

Reviewed-by: rkennke

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 13:06:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 13:06:55 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v2]
In-Reply-To: <5Hx_AlMGK1-53XbgjGPwkbMPJT2U32KGuTA5tmWzfhQ=.b4969a31-5fb4-45d9-8ab5-9dcef4248e1e@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
 <TyXqDx77dh8SlElDMs_q8gGysVo_jqAdf4nBTE3T1_U=.ebaa85b7-eb14-44e2-be26-e47b898a001b@github.com>
 <5Hx_AlMGK1-53XbgjGPwkbMPJT2U32KGuTA5tmWzfhQ=.b4969a31-5fb4-45d9-8ab5-9dcef4248e1e@github.com>
Message-ID: <3ipSn5yXqXr2-bbrrzyOX4d0B8Ns7vLULRiBGSfCFXs=.9ffe1909-0137-4ae5-bd4d-ddfce586a7fe@github.com>

On Mon, 12 Jul 2021 12:06:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I came to the same conclusion and considering that waiting as a candidate for putting it into the going-to-be parallel pre-evacuation phase. Then again, it might not be useful to have both the concurrent worker threads and parallel threads working at the same time (for performance reasons only; I do not consider the potential parallel verification also using the parallel worker threads as an issue). I checked that verification does not interfere with it (i.e. verification does not care about the mark bitmap in that sense).
>> The only requirement I can see is that all of these root-region objects need to have their referents marked, i.e. they must not be overwritten in some way, which this place guarantees as well, and to me it seems a more fitting place.
>
> A problem with moving it later to the new placement is that it's now included in the pause time, where it previously wasn't.  I'm not sure it should be included in the pause time, as it's not really part of this collection.  I also wonder if the root scanning ought to be done using the concurrent workers rather than the stw workers, as there are typically fewer of the former (required to not be more?).

It is true that it is now also included in the time used for MMU calculation (as part of the `record_collection_start/end` pair), which may a problem.

Previous gc timing also included it though, i.e. in the `note_gc_start()/print_phase_times()` pair.

I'll move it back then.

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 13:23:00 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 13:23:00 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v2]
In-Reply-To: <3ipSn5yXqXr2-bbrrzyOX4d0B8Ns7vLULRiBGSfCFXs=.9ffe1909-0137-4ae5-bd4d-ddfce586a7fe@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
 <TyXqDx77dh8SlElDMs_q8gGysVo_jqAdf4nBTE3T1_U=.ebaa85b7-eb14-44e2-be26-e47b898a001b@github.com>
 <5Hx_AlMGK1-53XbgjGPwkbMPJT2U32KGuTA5tmWzfhQ=.b4969a31-5fb4-45d9-8ab5-9dcef4248e1e@github.com>
 <3ipSn5yXqXr2-bbrrzyOX4d0B8Ns7vLULRiBGSfCFXs=.9ffe1909-0137-4ae5-bd4d-ddfce586a7fe@github.com>
Message-ID: <_aM2KlJUwJkWd7oDD9ijVVCu2WB9TiJbJh2mE4sJIog=.8cb1d397-7636-4b14-88f2-de557f83780d@github.com>

On Mon, 12 Jul 2021 13:03:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> A problem with moving it later to the new placement is that it's now included in the pause time, where it previously wasn't.  I'm not sure it should be included in the pause time, as it's not really part of this collection.  I also wonder if the root scanning ought to be done using the concurrent workers rather than the stw workers, as there are typically fewer of the former (required to not be more?).
>
> It is true that it is now also included in the time used for MMU calculation (as part of the `record_collection_start/end` pair), which may a problem.
> 
> Previous gc timing also included it though, i.e. in the `note_gc_start()/print_phase_times()` pair.
> 
> I'll move it back then.

Things are unfortunately a bit messy and confusing/confused about pause time handling; see JDK-8240779 and JDK-7178365.

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 13:51:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 13:51:22 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v3]
In-Reply-To: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
Message-ID: <6Pf1fMRhexSZEtrmbZFWtYMiCuLy3T7k9LQuEYHunK4=.046fff8a-0f0d-45dd-bbf4-dd88639ee58b@github.com>

> Hi all,
> 
>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

  Move back wait_for_root_region_scan

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4744/files
  - new: https://git.openjdk.java.net/jdk/pull/4744/files/b8fd8e09..999d66dd

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

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 13:51:24 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 13:51:24 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v3]
In-Reply-To: <_aM2KlJUwJkWd7oDD9ijVVCu2WB9TiJbJh2mE4sJIog=.8cb1d397-7636-4b14-88f2-de557f83780d@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <iZ6OTzwF_DjbDJFD9TqB6LFITMtJfqRU3h3Uc-X-xsk=.46b45c66-13c6-48f3-9de7-b864c9b68b15@github.com>
 <TyXqDx77dh8SlElDMs_q8gGysVo_jqAdf4nBTE3T1_U=.ebaa85b7-eb14-44e2-be26-e47b898a001b@github.com>
 <5Hx_AlMGK1-53XbgjGPwkbMPJT2U32KGuTA5tmWzfhQ=.b4969a31-5fb4-45d9-8ab5-9dcef4248e1e@github.com>
 <3ipSn5yXqXr2-bbrrzyOX4d0B8Ns7vLULRiBGSfCFXs=.9ffe1909-0137-4ae5-bd4d-ddfce586a7fe@github.com>
 <_aM2KlJUwJkWd7oDD9ijVVCu2WB9TiJbJh2mE4sJIog=.8cb1d397-7636-4b14-88f2-de557f83780d@github.com>
Message-ID: <x7w1bbrsA2aYhihKrhsTaPDx0a7Q9-Jb8CjBZXHX4JI=.368e84d2-79ee-4434-b9ae-29efd01ecebb@github.com>

On Mon, 12 Jul 2021 13:19:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> It is true that it is now also included in the time used for MMU calculation (as part of the `record_collection_start/end` pair), which may a problem.
>> 
>> Previous gc timing also included it though, i.e. in the `note_gc_start()/print_phase_times()` pair.
>> 
>> I'll move it back then.
>
> Things are unfortunately a bit messy and confusing/confused about pause time handling; see JDK-8240779 and JDK-7178365.

I am aware of those, but this change does not really intend to fix these issues, but hopefully not make them worse (afaict this has been achieved).

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

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


From ayang at openjdk.java.net  Mon Jul 12 14:20:56 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 14:20:56 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
In-Reply-To: <VFIY110BiNJdxxJdJwfcY75dwJiFWYg_TbW7-yr0d2Q=.502bf4b4-50fc-41d3-b718-1c629ad55af8@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
 <VFIY110BiNJdxxJdJwfcY75dwJiFWYg_TbW7-yr0d2Q=.502bf4b4-50fc-41d3-b718-1c629ad55af8@github.com>
Message-ID: <qMwEJmp3XP7KZANRFlB8L7tu20LoOecFS-RODwUEP98=.22ab3423-d3d3-47cb-b809-b20b346627d1@github.com>

On Mon, 12 Jul 2021 12:17:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Simple rename of phase{2,3,4} to something with semantic meaning.
>
> src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp line 83:
> 
>> 81:   ~ReferenceProcessorPhaseTimes();
>> 82: 
>> 83:   WorkerDataArray<double>* SoftWeakFinalRefsPhase_worker_time_sec() const { return _SoftWeakFinalRefsPhase_worker_time_sec; }
> 
> This is a weird function name.  I understand why, but I'm not convinced.  We have process_soft_weak_final_refs and the like, for example.

How about `soft_weak_final_refs_phase_worker_time_sec()`?

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

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


From iwalulya at openjdk.java.net  Mon Jul 12 14:52:13 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Mon, 12 Jul 2021 14:52:13 GMT
Subject: RFR: JDK-8264419: Remove has_max_index argument from
 G1BlockOffsetTablePart::block_at_or_preceding
Message-ID: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>

Please review this small change to remove superfluous function arguments. 

Testing: tier1

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

Commit messages:
 - hange comment
 - refactor

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

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


From ayang at openjdk.java.net  Mon Jul 12 14:55:56 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 14:55:56 GMT
Subject: RFR: JDK-8264419: Remove has_max_index argument from
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
References: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
Message-ID: <TUmj00w6aqbzMkJ_dUQEammBXo5DzluJKpcVTp9ruzw=.495859a7-0713-459b-ace1-2cb0fa644700@github.com>

On Mon, 12 Jul 2021 14:43:24 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Please review this small change to remove superfluous function arguments. 
> 
> Testing: tier1

Marked as reviewed by ayang (Committer).

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

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


From ayang at openjdk.java.net  Mon Jul 12 15:20:29 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 15:20:29 GMT
Subject: RFR: 8270187: G1: Remove ConcGCThreads constraint
Message-ID: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>

Removing `ConcGCThreads <= ParallelGCThreads` constraint for G1.

Tested: hotspot_gc with `-XX:ConcGCThreads=3 -XX:ParallelGCThreads=2`

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

Commit messages:
 - conc-constraint

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

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


From tschatzl at openjdk.java.net  Mon Jul 12 15:34:50 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 12 Jul 2021 15:34:50 GMT
Subject: RFR: JDK-8264419: Remove has_max_index argument from
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
References: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
Message-ID: <w4MANeFNWmmvHmb0EEbFLhlsNkPQIM0pOPe3H2cZuTU=.ce925585-71a9-408d-ba65-aeed6530c0db@github.com>

On Mon, 12 Jul 2021 14:43:24 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Please review this small change to remove superfluous function arguments. 
> 
> Testing: tier1

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From shade at openjdk.java.net  Mon Jul 12 16:00:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Jul 2021 16:00:53 GMT
Subject: RFR: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible [v4]
In-Reply-To: <aG2dSMtK2b4BxIyvz60fbEx9IS2F7LXWNRMbcUJd01Y=.4a149877-94d9-4a5f-9e4c-d5c42e295791@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
 <aG2dSMtK2b4BxIyvz60fbEx9IS2F7LXWNRMbcUJd01Y=.4a149877-94d9-4a5f-9e4c-d5c42e295791@github.com>
Message-ID: <S816uTnEdw06XgurXKzgZJbRsHAthi0zEwfPLxeFevw=.7bcced50-5b69-4242-b4a3-e5c11d8049f4@github.com>

On Mon, 12 Jul 2021 11:21:27 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We've observed test failures in jcstress, see:
>> https://bugs.openjdk.java.net/browse/JDK-8269897
>> 
>> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
>> 
>> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
>> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
>> 
>> Testing:
>>  - [x] the provided jcstress test
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Aleksey's comments

This still passes testing and looks fine to me.

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

Marked as reviewed by shade (Reviewer).

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


From ayang at openjdk.java.net  Mon Jul 12 18:28:55 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 18:28:55 GMT
Subject: RFR: 8270169: G1: Incorrect reference discovery MT degree in
 concurrent marking
In-Reply-To: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
References: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
Message-ID: <lOCc8qS0-Fur_Y4QtNyeNNDmqLLGJ3whqaFJ79UN5NI=.44c38489-f0d2-454f-8c6e-555efc3c6370@github.com>

On Fri, 9 Jul 2021 13:11:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of ref discovery MT degree in concurrent marking.
> 
> Test: hotspot_gc

Thanks for the review.

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

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


From ayang at openjdk.java.net  Mon Jul 12 18:28:56 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 18:28:56 GMT
Subject: Integrated: 8270169: G1: Incorrect reference discovery MT degree in
 concurrent marking
In-Reply-To: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
References: <w7q75yfZ8Rzhaz3j7D9KPAMq46gdidl1POMjlLmefqM=.c148389f-12a5-4892-91ee-56a449a38b0c@github.com>
Message-ID: <uqSsrYpKzZbVw8jGiErVbE1eFIpGDHmlLAK-Y4mDdjE=.c72d477c-1a68-4959-8446-e4fbe8dff592@github.com>

On Fri, 9 Jul 2021 13:11:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of ref discovery MT degree in concurrent marking.
> 
> Test: hotspot_gc

This pull request has now been integrated.

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

8270169: G1: Incorrect reference discovery MT degree in concurrent marking

Reviewed-by: tschatzl, iwalulya, kbarrett

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

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


From ihse at openjdk.java.net  Mon Jul 12 18:35:11 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 12 Jul 2021 18:35:11 GMT
Subject: RFR: 8270320: JDK-8270110 committed invalid copyright headers
Message-ID: <sY6WYgVwYDw-dIxic-HPaS_6Aq3b_iNCUvgovjxS_Dg=.9f4f51c1-0517-4af4-9d52-26261a059ba0@github.com>

The fix for JDK-8270110 added two new files with copyright headers that do not follow the prescribed format.

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

Commit messages:
 - 8270320: JDK-8270110 committed invalid copyright headers

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

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


From ayang at openjdk.java.net  Mon Jul 12 18:53:51 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 12 Jul 2021 18:53:51 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>
Message-ID: <ns2EfuLGZToMOaREldOKAV5Bw1x1DWFIBlXvMf8zq7s=.6282c474-42d7-4a91-af78-0edf6f89feb5@github.com>

On Mon, 12 Jul 2021 08:22:09 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> duplicate the computation of threads_count and adjust_for_thread_increase

I don't view a method call and accessing a global as much duplication. Anyway, this is subjective.

> I don't see why assigning to 100 to _shrink_factor and current_shrink_factor should be any better?

Having a logic-free (does nothing but print) logger brings less surprise. IOW, many expect a logger faithfully reflect the actual internal states with no distortion.

> These values aren't used except for logging if ShrinkHeapInSteps is false.

That's true, but I prefer that the logger doesn't know `ShrinkHeapInSteps`, and just prints `_shrink_factor` and `current_shrink_factor` as they are.

> But on heap expansion, we'll return from the method early, before even reaching the shrinking logic.

I see; thank you for pointing it out. How about sth like this?


void CardGeneration::compute_new_size() {
  ... 
  if (capacity_after_gc < minimum_desired_capacity) {
    ...
    // expanding the heap; reset shrink factor
    _shrink_factor = 0;
    return;
  }

  if (capacity_after_gc > maximum_desired_capacity) {
    ...
    if (ShrinkHeapInSteps) {
      current_shrink_factor = _shrink_factor;
      _shrink_factor = ...
    } else {
      // Shrink 100% to the desired value
      current_shrink_factor = _shrink_factor = 100;
    }
    // log internal states
  }
}

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

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


From kvn at openjdk.java.net  Mon Jul 12 18:54:01 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 12 Jul 2021 18:54:01 GMT
Subject: RFR: 8270320: JDK-8270110 committed invalid copyright headers
In-Reply-To: <sY6WYgVwYDw-dIxic-HPaS_6Aq3b_iNCUvgovjxS_Dg=.9f4f51c1-0517-4af4-9d52-26261a059ba0@github.com>
References: <sY6WYgVwYDw-dIxic-HPaS_6Aq3b_iNCUvgovjxS_Dg=.9f4f51c1-0517-4af4-9d52-26261a059ba0@github.com>
Message-ID: <IuRVp1hW7PcUYOtvDdpMERqPAvfyj6STgwjVNwFXY40=.3c715d4d-0ece-450f-a313-b37e80059c8e@github.com>

On Mon, 12 Jul 2021 18:26:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The fix for JDK-8270110 added two new files with copyright headers that do not follow the prescribed format.

Trivial.

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

Marked as reviewed by kvn (Reviewer).

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


From ihse at openjdk.java.net  Mon Jul 12 18:59:57 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 12 Jul 2021 18:59:57 GMT
Subject: Integrated: 8270320: JDK-8270110 committed invalid copyright headers
In-Reply-To: <sY6WYgVwYDw-dIxic-HPaS_6Aq3b_iNCUvgovjxS_Dg=.9f4f51c1-0517-4af4-9d52-26261a059ba0@github.com>
References: <sY6WYgVwYDw-dIxic-HPaS_6Aq3b_iNCUvgovjxS_Dg=.9f4f51c1-0517-4af4-9d52-26261a059ba0@github.com>
Message-ID: <of-FXJkyAcGtT2zPjOLxQ641qFE4GvgsAa-8J9L9an4=.052dd617-1ae5-49e8-a590-6e70d2f65e34@github.com>

On Mon, 12 Jul 2021 18:26:53 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The fix for JDK-8270110 added two new files with copyright headers that do not follow the prescribed format.

This pull request has now been integrated.

Changeset: 353e9c86
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/353e9c8607e3a433aac786bd7b818d77ff75dd11
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8270320: JDK-8270110 committed invalid copyright headers

Reviewed-by: kvn

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 22:40:54 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 22:40:54 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
In-Reply-To: <qMwEJmp3XP7KZANRFlB8L7tu20LoOecFS-RODwUEP98=.22ab3423-d3d3-47cb-b809-b20b346627d1@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
 <VFIY110BiNJdxxJdJwfcY75dwJiFWYg_TbW7-yr0d2Q=.502bf4b4-50fc-41d3-b718-1c629ad55af8@github.com>
 <qMwEJmp3XP7KZANRFlB8L7tu20LoOecFS-RODwUEP98=.22ab3423-d3d3-47cb-b809-b20b346627d1@github.com>
Message-ID: <OAbV40sqT0ZhFx1TSukIHaUcYozJ9KaaiQZSjOtjv44=.ddbe7fb4-2c5f-48ce-847b-c3119866662f@github.com>

On Mon, 12 Jul 2021 14:17:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp line 83:
>> 
>>> 81:   ~ReferenceProcessorPhaseTimes();
>>> 82: 
>>> 83:   WorkerDataArray<double>* SoftWeakFinalRefsPhase_worker_time_sec() const { return _SoftWeakFinalRefsPhase_worker_time_sec; }
>> 
>> This is a weird function name.  I understand why, but I'm not convinced.  We have process_soft_weak_final_refs and the like, for example.
>
> How about `soft_weak_final_refs_phase_worker_time_sec()`?

Yes, that's normal style.  It's quite a mouthful, but it's not like it gets written very often.  With that change, I think this PR looks good.

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

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


From kbarrett at openjdk.java.net  Mon Jul 12 22:40:53 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 12 Jul 2021 22:40:53 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
In-Reply-To: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
Message-ID: <8rszxzxlZPyTtZhqX8YjwsxPfuNeDhEezQXoBmFL8Bs=.efa7b97d-bc62-461e-871d-9822808b99e9@github.com>

On Mon, 12 Jul 2021 10:24:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple rename of phase{2,3,4} to something with semantic meaning.

Looks good after discussed function name change.

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

Marked as reviewed by kbarrett (Reviewer).

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


From lmesnik at openjdk.java.net  Tue Jul 13 02:10:13 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 13 Jul 2021 02:10:13 GMT
Subject: RFR: 8270336: [TESTBUG] Fix initialization in NonbranchyTree
Message-ID: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>

The nsk.share.gc.NonbranchyTree might call initTree() twice and incorrectly reports branchiness in the case of IllegalArgumentException(...).

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

Commit messages:
 - 8270336: [TESTBUG] Fix initialization in NonbranchyTree

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

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


From simonis at openjdk.java.net  Tue Jul 13 06:19:52 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Tue, 13 Jul 2021 06:19:52 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <ns2EfuLGZToMOaREldOKAV5Bw1x1DWFIBlXvMf8zq7s=.6282c474-42d7-4a91-af78-0edf6f89feb5@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>
 <ns2EfuLGZToMOaREldOKAV5Bw1x1DWFIBlXvMf8zq7s=.6282c474-42d7-4a91-af78-0edf6f89feb5@github.com>
Message-ID: <qhfJdAtGbLEBogCMlWR0n2e-qzxXc8HTDWikWmstouE=.e733711a-e43d-41c2-a211-376afb257ad9@github.com>

On Mon, 12 Jul 2021 18:50:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> `threads_count` and `adjust_for_thread_increase` get computed in `adjust_for_thread_increase()`. That's why they are passed in by reference. I don't think it makes sense to duplicate the computation of `threads_count` and `adjust_for_thread_increase` before we log them because the next time somebody will change `adjust_for_thread_increase()`, the values will be wrong again. This error occurred in the first place because [JDK-8144527](https://bugs.openjdk.java.net/browse/JDK-8144527) has factored out the computation of `threads_count` and `adjust_for_thread_increase` into the new  `adjust_for_thread_increase()` function, but did not pass the values back for logging.
>> 
>> For the second fix, I don't see why assigning to 100 to `_shrink_factor` and `current_shrink_factor` should be any better? These values aren't used except for logging if `ShrinkHeapInSteps` is false. Also, the assignment of `current_shrink_factor` can't easily be moved into the if-branch because `_shrink_factor` has to be reset to 0 before we potentially expand the heap (see comment `But if we recompute size without shrinking, it goes back to 0%.`). But on heap expansion, we'll return from the method early, before even reaching the shrinking logic.
>
>> duplicate the computation of threads_count and adjust_for_thread_increase
> 
> I don't view a method call and accessing a global as much duplication. Anyway, this is subjective.
> 
>> I don't see why assigning to 100 to _shrink_factor and current_shrink_factor should be any better?
> 
> Having a logic-free (does nothing but print) logger brings less surprise. IOW, many expect a logger faithfully reflect the actual internal states with no distortion.
> 
>> These values aren't used except for logging if ShrinkHeapInSteps is false.
> 
> That's true, but I prefer that the logger doesn't know `ShrinkHeapInSteps`, and just prints `_shrink_factor` and `current_shrink_factor` as they are.
> 
>> But on heap expansion, we'll return from the method early, before even reaching the shrinking logic.
> 
> I see; thank you for pointing it out. How about sth like this?
> 
> 
> void CardGeneration::compute_new_size() {
>   ... 
>   if (capacity_after_gc < minimum_desired_capacity) {
>     ...
>     // expanding the heap; reset shrink factor
>     _shrink_factor = 0;
>     return;
>   }
> 
>   if (capacity_after_gc > maximum_desired_capacity) {
>     ...
>     if (ShrinkHeapInSteps) {
>       current_shrink_factor = _shrink_factor;
>       _shrink_factor = ...
>     } else {
>       // Shrink 100% to the desired value
>       current_shrink_factor = _shrink_factor = 100;
>     }
>     // log internal states
>   }
> }

@albertnetymk  your latest proposal is still changing the current semantics. Before, the shrink factor was reset on every invocation of `CardGeneration::compute_new_size()`. With your proposal, it will only be reset if we expand the heap.

My patch is really just a trivial fix of some logging errors. I'm not against changing or improving it, but before I introduce any behavioral changes, I'd like to hear a second opinion.

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

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


From tschatzl at openjdk.java.net  Tue Jul 13 07:34:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 07:34:53 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
In-Reply-To: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
Message-ID: <DMbWTvaMRpoZHFWeSvIYUYhf10719f_pbpoVPgsooEg=.3559f962-7dec-4a99-9c87-06a9dd476c50@github.com>

On Mon, 12 Jul 2021 10:24:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple rename of phase{2,3,4} to something with semantic meaning.

Lgtm apart from that naming issue.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Jul 13 07:34:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 07:34:53 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
In-Reply-To: <OAbV40sqT0ZhFx1TSukIHaUcYozJ9KaaiQZSjOtjv44=.ddbe7fb4-2c5f-48ce-847b-c3119866662f@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
 <VFIY110BiNJdxxJdJwfcY75dwJiFWYg_TbW7-yr0d2Q=.502bf4b4-50fc-41d3-b718-1c629ad55af8@github.com>
 <qMwEJmp3XP7KZANRFlB8L7tu20LoOecFS-RODwUEP98=.22ab3423-d3d3-47cb-b809-b20b346627d1@github.com>
 <OAbV40sqT0ZhFx1TSukIHaUcYozJ9KaaiQZSjOtjv44=.ddbe7fb4-2c5f-48ce-847b-c3119866662f@github.com>
Message-ID: <Mlr55_0-Psx_O3KM_aHd4rJTqh7V1nBJEJAYHURsuy8=.0eee058d-5d3d-48ae-870a-64dcd89e8bec@github.com>

On Mon, 12 Jul 2021 22:37:44 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> How about `soft_weak_final_refs_phase_worker_time_sec()`?
>
> Yes, that's normal style.  It's quite a mouthful, but it's not like it gets written very often.  With that change, I think this PR looks good.

Agree with that.

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

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


From thomas.schatzl at oracle.com  Tue Jul 13 07:52:55 2021
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 13 Jul 2021 09:52:55 +0200
Subject: Status of JEP-8204088/JDK-8236073
In-Reply-To: <35ff0404-9cb0-f9bf-0d37-2c3d7b4a0f67@oracle.com>
References: <CACz-JM7_rm9-Lvh+OfvCptp8Tfc=R-7vxrsAwyoukR6TaLP-qg@mail.gmail.com>
 <84ee0b72-ffd8-3e2a-0461-a5a9d2c7e31b@oracle.com>
 <CACz-JM7d4HGtRjaykXHF1yi3VjMxw7=8WSSbbA6XYY3JV5LvnQ@mail.gmail.com>
 <CACz-JM6Ljo0NsMqzzZ0+0N6eP6=Z8=espQiJB4SmQNw646UW4w@mail.gmail.com>
 <3694c54c-9bf5-9c5a-ada1-8f1d7bf737a1@oracle.com>
 <CACz-JM5cywv3+SgkCAiUWayPVvC3B3pS=oWhua-9_iNbciTmOQ@mail.gmail.com>
 <CACz-JM4-hNEcKt6ngOu4C_kqUfzfch6k9tKosN5Q_xzQy+m-nQ@mail.gmail.com>
 <1119e172-3f29-5616-d3d8-a542b15fdf65@oracle.com>
 <CA+w6HxYfLQfObQozpro57tuVLc2LfHpYY0XHcb-eUhEFEnpbPA@mail.gmail.com>
 <79b3df05-4e79-420f-f105-b6d11c26dfc1@oracle.com>
 <CACz-JM7dZdFMMC2EZGFyFL3BD5WwmHi6c6UOVntYOH8arntgMQ@mail.gmail.com>
 <02e32674-5095-ee6d-2d8a-2cb7d0f1a1e5@oracle.com>
 <CA+w6HxaYCrRt9VjMyNzQZBUpvFZdsK89iwyzw4yjbEebfhQyVA@mail.gmail.com>
 <35ff0404-9cb0-f9bf-0d37-2c3d7b4a0f67@oracle.com>
Message-ID: <939f9a95-9cd2-72b5-6972-99a651eb6e47@oracle.com>

Hi all,

On 21.06.21 13:40, Thomas Schatzl wrote:
> Hi,
> 
[...]>
> Another reason to not immediately jump on it is that while I can see 
> your point, first I would prefer to have the current issues fixed :)
   fwiw, I updated the open repo with the JDK-8236073* changes to latest 
and also fixed a calculation bug when shrinking.

https://github.com/tschatzl/jdk/tree/8238687-investigate-memory-uncommit-during-young-gc2

We still need to look at and investigate out-of-box performance changes 
because of this.

Sorry for doing a force push. I'll try to remember to do "normal" merges 
in the future if that is more convenient to you.

Thanks,
   Thomas


From iwalulya at openjdk.java.net  Tue Jul 13 08:30:22 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 13 Jul 2021 08:30:22 GMT
Subject: RFR: JDK-8264419: Remove has_max_index argument from
 G1BlockOffsetTablePart::block_at_or_preceding [v2]
In-Reply-To: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
References: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
Message-ID: <8M9fTkiIIlDMOAOJzDuh7OFPjQ2YZBzLt9jYMZ1DO-Y=.a941574b-9cfd-45be-ac78-aa98086608e2@github.com>

> Please review this small change to remove superfluous function arguments. 
> 
> Testing: tier1

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

 - Merge branch 'JDK-8264908_bot_range_check' of https://github.com/walulyai/jdk into JDK-8264908_bot_range_check
 - update copyright year
 - change comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4755/files
  - new: https://git.openjdk.java.net/jdk/pull/4755/files/c70417bb..b874f108

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

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

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


From kbarrett at openjdk.java.net  Tue Jul 13 08:42:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 13 Jul 2021 08:42:55 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v3]
In-Reply-To: <6Pf1fMRhexSZEtrmbZFWtYMiCuLy3T7k9LQuEYHunK4=.046fff8a-0f0d-45dd-bbf4-dd88639ee58b@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <6Pf1fMRhexSZEtrmbZFWtYMiCuLy3T7k9LQuEYHunK4=.046fff8a-0f0d-45dd-bbf4-dd88639ee58b@github.com>
Message-ID: <bc-P7x1xYE3qVGwmA13rci_bG13P3yli8hRkXcqBSs8=.aea9c819-fcb1-456e-9fd0-bb2c1a4f1d5d@github.com>

On Mon, 12 Jul 2021 13:51:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move back wait_for_root_region_scan

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Tue Jul 13 09:10:55 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 09:10:55 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
Message-ID: <fe8pmXG0y9fYcpke3V22YtVEhRTK6BrjT75BqjWAAEY=.06f0f715-5cb1-453a-9851-ff28963d6c10@github.com>

On Thu, 8 Jul 2021 15:19:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

I would prefer to not change semantics for heap sizing without lots of testing, and discussing the results. People have come to expect particular behavior, and actually "decaying" the shrink factor on every `CardGeneration::compute_new_size()` call makes sense. This makes shrinking the heap more slowly and less surprising. Consider the situation when you have the following sequence of shrink (s), no change (n) heap changes:

s - s - s - n - n - ... lots of n ... - n - s

On the last s, the GC would shrink 100% of the suggested value, which is kind of surprising given that the many "no-changes" gcs that would have indicated the application is kind of stable now (or you started another round in your benchmark). Generally it is also a good idea to be very reluctant with heap decreases as it typically has a significant performance impact during further operation. Too much heap shrinking tends to also just cause the next gc(s) to increase the heap again, i.e. ending up in wasted cpu time :)

Fwiw, for this issue, I would split `adjust_for_thread_increase` into two methods: one calculating the `thread_increase_size`, and the original `adjust_for_thread_increase` take that value as a parameter. 

Repeating the calculation at the logging as suggested by @albertnetymk gives different results on boundary conditions (i.e. the overflow checks are missing. Strangely on any overflow condition, `thread_increase_size` does not factor in at all into the `desired_new_size`. I think this is a bug; my preferred alternative would be to maximize the `thread_increase_size` to just not overflow instead - but that is another issue(!)). Another reason why I would prefer to separate the calculation of that value from the calculation of the desired_new_size is that these seem to logically be two separate steps, so that makes sense anyway imho.

I agree with @albertnetymk that it is preferable to not have the conditions in the log message to make them as simple as possible - so I would probably just set `current_shrink_factor` and `_shrink_factor` to 100 at the top of `CardGeneration::compute_new_size` if `ShrinkHeapInSteps` is false. In addition to that probably put these variable declarations at the start of the shrinking calculations block, somewhere close to

size_t shrink_bytes = 0;

Calling `Threads::number_of_non_daemon_threads` another time for the log message does not seem to be a problem, but if you wanted, that `calculate_thread_increase_size()` could also return the thread count used for the calculation.

Of course, I did not run and test my suggestions.

Three people, three opinions, but maybe there's a middle ground to be found somewhere :p

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

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


From ayang at openjdk.java.net  Tue Jul 13 09:11:22 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 13 Jul 2021 09:11:22 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
 [v2]
In-Reply-To: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
Message-ID: <DQ6JRiJyOV_hNIodVEO7UjImeHssI1evIEwULZYt-uA=.295a33be-c7df-4a27-ba57-2f497440d877@github.com>

> Simple rename of phase{2,3,4} to something with semantic meaning.

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

  rename method name

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4752/files
  - new: https://git.openjdk.java.net/jdk/pull/4752/files/49a4e277..42f38910

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

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

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


From ayang at openjdk.java.net  Tue Jul 13 09:47:01 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 13 Jul 2021 09:47:01 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <qhfJdAtGbLEBogCMlWR0n2e-qzxXc8HTDWikWmstouE=.e733711a-e43d-41c2-a211-376afb257ad9@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>
 <ns2EfuLGZToMOaREldOKAV5Bw1x1DWFIBlXvMf8zq7s=.6282c474-42d7-4a91-af78-0edf6f89feb5@github.com>
 <qhfJdAtGbLEBogCMlWR0n2e-qzxXc8HTDWikWmstouE=.e733711a-e43d-41c2-a211-376afb257ad9@github.com>
Message-ID: <iLh6JS4xunfsO0VWk114SWyCZ2WERNBedEBizA0CgiQ=.7e0473f3-5f47-4bb1-bd9a-9f8dd0f63751@github.com>

On Tue, 13 Jul 2021 06:16:32 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Before, the shrink factor was reset on every invocation of CardGeneration::compute_new_size(). With your proposal, it will only be reset if we expand the heap.

Indeed, my suggestion is flawed.

> "decaying" the shrink factor on every CardGeneration::compute_new_size() call makes sense.

Agree.

> so I would probably just set current_shrink_factor and _shrink_factor to 100 at the top of CardGeneration::compute_new_size if ShrinkHeapInSteps is false

Sounds good to me.

Re `NewSizeThreadIncrease`, what's the motivation for having it (used only by Serial) in the first place? Going through the git-log, I can only find the overflow-fix from JDK-8144527.

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

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


From ayang at openjdk.java.net  Tue Jul 13 10:40:57 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 13 Jul 2021 10:40:57 GMT
Subject: Integrated: 8270282: Semantically rename reference processing
 subphases
In-Reply-To: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
Message-ID: <VkKESQphHmr5F6UAkrPa_t4VcZatGNw-TKBv18JO9bE=.7a0d251b-bcbb-4dfc-a85f-62baaf330147@github.com>

On Mon, 12 Jul 2021 10:24:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple rename of phase{2,3,4} to something with semantic meaning.

This pull request has now been integrated.

Changeset: 565ec851
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/565ec8518ba971fc8103e74f810f1e79e05ea1a1
Stats:     85 lines in 4 files changed: 0 ins; 1 del; 84 mod

8270282: Semantically rename reference processing subphases

Reviewed-by: kbarrett, tschatzl

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

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


From ayang at openjdk.java.net  Tue Jul 13 10:40:57 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 13 Jul 2021 10:40:57 GMT
Subject: RFR: 8270282: Semantically rename reference processing subphases
 [v2]
In-Reply-To: <DQ6JRiJyOV_hNIodVEO7UjImeHssI1evIEwULZYt-uA=.295a33be-c7df-4a27-ba57-2f497440d877@github.com>
References: <fEGsh8GZGTLCTE2U7-MFp2zPyZm3ks2cwuYIY7dw9jk=.ee906f9b-9f6b-4038-bfb4-ce6843b38cae@github.com>
 <DQ6JRiJyOV_hNIodVEO7UjImeHssI1evIEwULZYt-uA=.295a33be-c7df-4a27-ba57-2f497440d877@github.com>
Message-ID: <23yosETqQt0gA9gA9tlXfIb90j22pEbTqkvmFHANm1o=.7a82976b-e82e-47c7-99fc-35789e228505@github.com>

On Tue, 13 Jul 2021 09:11:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple rename of phase{2,3,4} to something with semantic meaning.
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename method name

Thanks for the review.

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

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


From tschatzl at openjdk.java.net  Tue Jul 13 11:30:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 11:30:07 GMT
Subject: Integrated: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper
In-Reply-To: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
Message-ID: <Cjtflm9gAKygvuFrUaDHg5Mx6Pcp8fiF9Uu0ir1E5Ew=.89995dec-f2ff-40c4-862b-73c1b108105d@github.com>

On Fri, 9 Jul 2021 14:40:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for this change that factors out a few methods from `do_collection_pause_at_safepoint_helper` and reshuffles code from `gc_prologue`/`gc_epilogue` to be able to put those into parallel phase(s) later.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 375fc2a2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/375fc2a2b29c454b36d3ae068a080b28f6ec04e9
Stats:     214 lines in 3 files changed: 110 ins; 81 del; 23 mod

8270009: Factor out and shuffle methods in G1CollectedHeap::do_collection_pause_at_safepoint_helper

Reviewed-by: kbarrett, ayang

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

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


From tschatzl at openjdk.java.net  Tue Jul 13 11:30:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 11:30:07 GMT
Subject: RFR: 8270009: Factor out and shuffle methods in
 G1CollectedHeap::do_collection_pause_at_safepoint_helper [v3]
In-Reply-To: <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>
References: <irccSX2iDkgOSJq_9k1b3TPUnV21tqBoJLQeiH_h-Pg=.fa998652-1876-4093-bc7d-48f4f6a7e6d7@github.com>
 <MSdBwqUOuHN0chk4Ggu21tudb6XbTXKbYKKFzcsWhLQ=.db9a4b44-e2f1-431d-a0d1-b61732d35f95@github.com>
Message-ID: <o29xsVq2XdTYXdIfvVF0Atd5rYKk5mJoWoIKSX-4mWs=.d00c1b4a-4e30-40ba-b88d-d2533041c30b@github.com>

On Mon, 12 Jul 2021 07:20:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move back wait_for_root_region_scan
>
> Only minor comments regarding certain names.

Thanks @albertnetymk @kimbarrett for your reviews.

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

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


From rkennke at openjdk.java.net  Tue Jul 13 13:33:59 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 13 Jul 2021 13:33:59 GMT
Subject: Integrated: 8269897: Shenandoah: Resolve UNKNOWN access strength,
 where possible
In-Reply-To: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
References: <5zmnbK6-6Co7oRsmFUdv5PAWxXWxnH_1EcxzWyD98KQ=.3e58011d-8fff-4998-9678-f65be97dee54@github.com>
Message-ID: <S4XDjs9iMsLPWAFkeagKQ3HnMhOUkk7UK_1yfDyWvsc=.78903c8d-2e8a-4988-91e7-b336eb114da1@github.com>

On Tue, 6 Jul 2021 19:00:59 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We've observed test failures in jcstress, see:
> https://bugs.openjdk.java.net/browse/JDK-8269897
> 
> We used to treat UNKNOWN reference accesses like weak accesses. UNKNOWN is used for Unsafe, reflection and JNI accesses, where it cannot be determined at compilation-time if we are accessing a regular field or a Reflection.referent field. The rationale for treating UNKNOWN as weak was that if the reference is a regular reference, then the value would be strongly reachable anyway, and only if it is a referent field would reachability matter. However, it turns out that this assumption is wrong: the test shows that a reference that is only weakly reachable can be legitimately written into a field, thus resurrecting the reference, and when that weakly reachable reference is loaded, it would be (wrongly) filtered as NULL.
> 
> A fix is to treat UNKNOWN accesses as strong. Accessing Reference.referent via reflection, JNI or Unsafe is Bad Idea anyway.
> This test shows the problem with CAS, but I believe it affects all accesses via reflection, JNI, etc.
> 
> Testing:
>  - [x] the provided jcstress test
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1

This pull request has now been integrated.

Changeset: 7ac08161
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ac08161a8b2080ed054bc00a30d6f694ece4df3
Stats:     116 lines in 3 files changed: 49 ins; 33 del; 34 mod

8269897: Shenandoah: Resolve UNKNOWN access strength, where possible

Reviewed-by: shade

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

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


From tschatzl at openjdk.java.net  Tue Jul 13 13:59:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 13:59:06 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing
Message-ID: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>

Hi all,

  can I get reviews for some further cleanup of the young collection code:
- adding some more scoped objects (verification, gc pause timing)
- some naming, minor related code movement

Thanks,
  Thomas

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

Commit messages:
 - Initial implementation: further refactoring

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

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


From vlivanov at openjdk.java.net  Tue Jul 13 14:03:56 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Jul 2021 14:03:56 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>

On Fri, 25 Jun 2021 17:38:32 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

Looks good.

src/hotspot/cpu/x86/frame_x86.cpp line 356:

> 354: }
> 355: 
> 356: OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const {

It makes sense to assert that `frame` refers to optimized entry frame (`assert(frame->is_optimized_entry_frame(), "wrong frame");`.

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

> 1126: 
> 1127:  private:
> 1128:   DEBUG_ONLY(void verify_frame_info();)

If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as:

assert(verify_frame_info(), "unexpected frame info");

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

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Tue Jul 13 15:01:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Jul 2021 15:01:57 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
In-Reply-To: <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
Message-ID: <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>

On Tue, 13 Jul 2021 13:52:18 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> src/hotspot/cpu/x86/frame_x86.cpp line 356:
> 
>> 354: }
>> 355: 
>> 356: OptimizedEntryBlob::FrameData* OptimizedEntryBlob::frame_data_for_frame(const frame& frame) const {
> 
> It makes sense to assert that `frame` refers to optimized entry frame (`assert(frame->is_optimized_entry_frame(), "wrong frame");`.

Good idea. Thanks

> src/hotspot/share/runtime/thread.hpp line 1128:
> 
>> 1126: 
>> 1127:  private:
>> 1128:   DEBUG_ONLY(void verify_frame_info();)
> 
> If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as:
> 
> assert(verify_frame_info(), "unexpected frame info");

Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Tue Jul 13 15:16:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 13 Jul 2021 15:16:26 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Assert frame is correct type in frame_data_for_frame

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/149/files
  - new: https://git.openjdk.java.net/jdk17/pull/149/files/c90416f5..211bf316

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

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From tschatzl at openjdk.java.net  Tue Jul 13 16:07:23 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 13 Jul 2021 16:07:23 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
Message-ID: <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>

> Hi all,
> 
>   can I get reviews for some further cleanup of the young collection code:
> - adding some more scoped objects (verification, gc pause timing)
> - some naming, minor related code movement
> 
> Thanks,
>   Thomas

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

  Fix test because of slightly different log message order

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4768/files
  - new: https://git.openjdk.java.net/jdk/pull/4768/files/c321d385..7730aa6d

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

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

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


From vlivanov at openjdk.java.net  Tue Jul 13 17:09:12 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Jul 2021 17:09:12 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <DlbU1RvRgWn5eDTYXKRHRek6xO41mHz0qm5A0YqecBo=.8082071a-7309-40e1-afd8-4cf4d7b8858d@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
 <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>
 <DlbU1RvRgWn5eDTYXKRHRek6xO41mHz0qm5A0YqecBo=.8082071a-7309-40e1-afd8-4cf4d7b8858d@github.com>
Message-ID: <uXN7rpU_bJywhFrrHhPJsEkpwGOSHjCiHDh5IJUqJlM=.32f02c37-a936-44b6-8c4e-92e0d39f492e@github.com>

On Tue, 13 Jul 2021 17:05:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).
>
> You can keep the assert inside `verify_frame_info()` which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) )

FTR I'm fine with it either way.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From vlivanov at openjdk.java.net  Tue Jul 13 17:09:12 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Tue, 13 Jul 2021 17:09:12 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <-CKmdxtDz9PebGwjDU6XEUMukYMC9CKmW2rhm6xZKWM=.8a88e29e-7b17-4647-9848-7a5bd2927fef@github.com>
 <COfhH43wnMDmJRyZMfM1HGsmw13KyRoJnI1petdtAFU=.c4aaf2d9-abd9-4f5d-ac85-d92ea92c1f98@github.com>
Message-ID: <DlbU1RvRgWn5eDTYXKRHRek6xO41mHz0qm5A0YqecBo=.8082071a-7309-40e1-afd8-4cf4d7b8858d@github.com>

On Tue, 13 Jul 2021 14:59:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.hpp line 1128:
>> 
>>> 1126: 
>>> 1127:  private:
>>> 1128:   DEBUG_ONLY(void verify_frame_info();)
>> 
>> If you declare `verify_frame_info` as returning a `bool` (and just put a `return true;` at the end of `JavaThread::verify_frame_info()`), you can call it as:
>> 
>> assert(verify_frame_info(), "unexpected frame info");
>
> Thanks for the suggestion. I'd like to keep it the way it is though, so that the assert message contains the `has_last_frame` & `java_call_counter` values. (this was one of the reason I did this refactor as well, since the assert I was hitting out of those 3 didn't contain that info).

You can keep the assert inside `verify_frame_info()` which dumps additional data. (Yes, it's a bit confusing: assert inside an assert :-) )

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From ayang at openjdk.java.net  Tue Jul 13 18:25:09 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 13 Jul 2021 18:25:09 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
Message-ID: <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>

On Tue, 13 Jul 2021 16:07:23 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for some further cleanup of the young collection code:
>> - adding some more scoped objects (verification, gc pause timing)
>> - some naming, minor related code movement
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix test because of slightly different log message order

Changes requested by ayang (Committer).

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

> 520: 
> 521: void G1GCPhaseTimes::print() {
> 522:   if (_cur_verify_before_time_ms > 0.0) {

Is this `if` just checking whether verification is enabled or not? If so, can `VerifyBeforeGC` be used? Otherwise, it's unclear to me why we are comparing it with `0.0`.

src/hotspot/share/gc/g1/g1Policy.hpp line 305:

> 303: 
> 304:   void note_young_gc_pause_start();
> 305:   void note_young_gc_pause_end();

It's not obvious to me if there's a diff btw `young_gc_pause` and  `young_collection`, or what the diff is. I think having some comments for these two pairs of methods would make it easier to understand.

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

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


From dholmes at openjdk.java.net  Wed Jul 14 01:01:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Jul 2021 01:01:15 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
Message-ID: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>

On Tue, 13 Jul 2021 15:16:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Assert frame is correct type in frame_data_for_frame

Hi Jorn,

I can't comment on all the details here - especially in the x86_64 upcall handler code. The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?

Some minor comments and queries below (mostly issues with existing code that you copied).

Thanks,
David

src/hotspot/share/prims/universalUpcallHandler.cpp line 76:

> 74: 
> 75: // modelled after JavaCallWrapper::JavaCallWrapper
> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {

This should return JavaThread not Thread.

src/hotspot/share/prims/universalUpcallHandler.cpp line 77:

> 75: // modelled after JavaCallWrapper::JavaCallWrapper
> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
> 77:   JavaThread* thread = maybe_attach_and_get_thread(&context->should_detach)->as_Java_thread();

Nit: if `maybe_attach_and_get_thread` has to return a JavaThread it should be typed to return a JavaThread.

src/hotspot/share/prims/universalUpcallHandler.cpp line 86:

> 84:   context->new_handles = JNIHandleBlock::allocate_block(thread);
> 85: 
> 86:   // After this, we are official in Java Code. This needs to be done before we change any of the thread local

typo: s/official/officially/
(I see this was copied from Javacalls)

src/hotspot/share/prims/universalUpcallHandler.cpp line 92:

> 90:   // Make sure that we handle asynchronous stops and suspends _before_ we clear all thread state
> 91:   // in OptimizedEntryBlob::FrameData. This way, we can decide if we need to do any pd actions
> 92:   // to prepare for stop/suspend (flush register windows on sparcs, cache sp, or other state).

No sparcs any more (again I see this was copied from Javacalls)

src/hotspot/share/prims/universalUpcallHandler.cpp line 114:

> 112:   thread->set_active_handles(context->new_handles);     // install new handle block and reset Java frame linkage
> 113: 
> 114:   assert (thread->thread_state() != _thread_in_native, "cannot set native pc to NULL");

You transitioned to _thread_in_Java above so how can you possibly have changed state again ?? (okay again copied from javaCalls ...)

src/hotspot/share/prims/universalUpcallHandler.cpp line 117:

> 115: 
> 116:   // clear any pending exception in thread (native calls start with no exception pending)
> 117:   if(clear_pending_exception) {

Nit: space after 'if'

src/hotspot/share/prims/universalUpcallHandler.cpp line 121:

> 119:   }
> 120: 
> 121:   MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));

Not clear why this is needed? JavaCallWrapper doesn't use it.

src/hotspot/share/prims/universalUpcallHandler.cpp line 146:

> 144:   // Do this after the transition because this allows us to put an assert
> 145:   // the Java->native transition which checks to see that stack is not walkable
> 146:   // on sparc/ia64 which will catch violations of the reseting of last_Java_frame

Again archaic comment copied across :)

src/hotspot/share/runtime/thread.cpp line 1972:

> 1970:          (has_last_Java_frame() && java_call_counter() > 0),
> 1971:          "unexpected frame info: has_last_frame=%d, java_call_counter=%d",
> 1972:          has_last_Java_frame(), java_call_counter());

I see this was relocated code, but as has_last_java_frame() returns bool, it shouldn't be treated as an int without a cast (or better use %s and report true or false).

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From dholmes at openjdk.java.net  Wed Jul 14 01:01:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 14 Jul 2021 01:01:16 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
Message-ID: <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>

On Fri, 25 Jun 2021 21:04:27 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Assert frame is correct type in frame_data_for_frame
>
> src/hotspot/share/runtime/safepoint.cpp line 931:
> 
>> 929:     // See if return type is an oop.
>> 930:     bool return_oop = nm->method()->is_returning_oop();
>> 931:     HandleMark hm(self);
> 
> I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).

How does native code reach a safepoint polling point?

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From tschatzl at openjdk.java.net  Wed Jul 14 07:42:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 07:42:12 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
 <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
Message-ID: <gBskNejyHTQzpEHwF8lQapCdHGlcf7dOdvZh-meAPgU=.cf0f1734-f2b5-4aa5-8335-7d4da951f30b@github.com>

On Tue, 13 Jul 2021 18:21:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test because of slightly different log message order
>
> src/hotspot/share/gc/g1/g1Policy.hpp line 305:
> 
>> 303: 
>> 304:   void note_young_gc_pause_start();
>> 305:   void note_young_gc_pause_end();
> 
> It's not obvious to me if there's a diff btw `young_gc_pause` and  `young_collection`, or what the diff is. I think having some comments for these two pairs of methods would make it easier to understand.

Added comments. `gc_pause` is the whole pause, `collection` is about just the collection part (as defined by the inner scope of the `do_collection_pause_at_safepoint_helper`). Feel free to suggest better naming.

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 07:48:12 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 07:48:12 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
 <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
Message-ID: <bGu0aZpW7s3Ypkonosyjl5HXtjN1P01CKlm-HQC26E4=.6def2ff2-e502-4677-9cf2-7ba98af29d5a@github.com>

On Tue, 13 Jul 2021 18:15:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix test because of slightly different log message order
>
> src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp line 522:
> 
>> 520: 
>> 521: void G1GCPhaseTimes::print() {
>> 522:   if (_cur_verify_before_time_ms > 0.0) {
> 
> Is this `if` just checking whether verification is enabled or not? If so, can `VerifyBeforeGC` be used? Otherwise, it's unclear to me why we are comparing it with `0.0`.

The `if` checks whether any verification work has been done (it will be > 0.0 if it has been set) in this pause. We can't just use `VerifyBefore/AfterGC` because verification before/after does not always run for all young gc pauses (see `VerifyGCType`).
If we want to change this (existing) behavior to like always print the time if the flag is enabled I would suggest to file another CR instead of hiding it here (I can do all that and the associated work if that is desired).

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 07:48:13 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 07:48:13 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <gBskNejyHTQzpEHwF8lQapCdHGlcf7dOdvZh-meAPgU=.cf0f1734-f2b5-4aa5-8335-7d4da951f30b@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
 <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
 <gBskNejyHTQzpEHwF8lQapCdHGlcf7dOdvZh-meAPgU=.cf0f1734-f2b5-4aa5-8335-7d4da951f30b@github.com>
Message-ID: <rEIK7ov5jbLcYBIXaDg82ytRUgQPLko_xcD_VbmAyIc=.b97d045d-b390-42f6-8a52-8b6ddc9a38a4@github.com>

On Wed, 14 Jul 2021 07:39:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1Policy.hpp line 305:
>> 
>>> 303: 
>>> 304:   void note_young_gc_pause_start();
>>> 305:   void note_young_gc_pause_end();
>> 
>> It's not obvious to me if there's a diff btw `young_gc_pause` and  `young_collection`, or what the diff is. I think having some comments for these two pairs of methods would make it easier to understand.
>
> Added comments. `gc_pause` is the whole pause, `collection` is about just the collection part (as defined by the inner scope of the `do_collection_pause_at_safepoint_helper`). Feel free to suggest better naming.

Maybe something like `record_young_collection_work_start`; another question is whether we should keep the `note_` prefix for the pause or change it to `record_` as well as it seems quite common.

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 07:57:16 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 07:57:16 GMT
Subject: RFR: JDK-8264419: Remove has_max_index argument from
 G1BlockOffsetTablePart::block_at_or_preceding [v2]
In-Reply-To: <TUmj00w6aqbzMkJ_dUQEammBXo5DzluJKpcVTp9ruzw=.495859a7-0713-459b-ace1-2cb0fa644700@github.com>
References: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
 <TUmj00w6aqbzMkJ_dUQEammBXo5DzluJKpcVTp9ruzw=.495859a7-0713-459b-ace1-2cb0fa644700@github.com>
Message-ID: <ZZJeGy4UFNoqQ9cnSWsIWbIxBsFWEdywWkVrnBEDmEQ=.c045cd7d-3c22-4529-b7ad-b54bd49a73f6@github.com>

On Mon, 12 Jul 2021 14:52:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8264908_bot_range_check' of https://github.com/walulyai/jdk into JDK-8264908_bot_range_check
>>  - update copyright year
>>  - change comment
>
> Marked as reviewed by ayang (Committer).

Thanks @albertnetymk and @tschatzl for the reviews

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 07:57:17 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 07:57:17 GMT
Subject: Integrated: JDK-8264419: Remove has_max_index argument from
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
References: <UhGSwP3P86IPKwOO-V3_RiuuHz8q2c-81cWr3afcBUE=.aa689072-b699-425f-82a9-4605a271518c@github.com>
Message-ID: <gwF_WARwyLLdlk6uuSrSllWL2XkvQnf88S4SSrANXuM=.2ddf357d-518c-448c-b5bf-e9b4db8cdf19@github.com>

On Mon, 12 Jul 2021 14:43:24 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Please review this small change to remove superfluous function arguments. 
> 
> Testing: tier1

This pull request has now been integrated.

Changeset: b6d76538
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b6d765386ec38d83a092ebf8dc109370f74e314d
Stats:     16 lines in 2 files changed: 0 ins; 7 del; 9 mod

8264419: Remove has_max_index argument from G1BlockOffsetTablePart::block_at_or_preceding

Reviewed-by: ayang, tschatzl

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

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


From ayang at openjdk.java.net  Wed Jul 14 08:10:12 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 08:10:12 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <bGu0aZpW7s3Ypkonosyjl5HXtjN1P01CKlm-HQC26E4=.6def2ff2-e502-4677-9cf2-7ba98af29d5a@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
 <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
 <bGu0aZpW7s3Ypkonosyjl5HXtjN1P01CKlm-HQC26E4=.6def2ff2-e502-4677-9cf2-7ba98af29d5a@github.com>
Message-ID: <rL2wO-rrUMsYNy7s00Nb-YooZalNcCnPT7gJySOvTXA=.bfa17e16-1460-490e-b37a-952a0f8c0dc4@github.com>

On Wed, 14 Jul 2021 07:43:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> We can't just use VerifyBefore/AfterGC because...

I see; thank you for the explanation.

> If we want to change this (existing) behavior to like always print the time if the flag is enabled

Either that or just put some comment there, since in what situation the condition is true is not obvious. Ofc, this is very subjective.

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

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


From simonis at openjdk.java.net  Wed Jul 14 08:12:33 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Jul 2021 08:12:33 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging [v2]
In-Reply-To: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
Message-ID: <FYmaBvSJCAV35YkJiV4AJooNL-uMHlVYPNm2waKAOGs=.c3eaecd0-5f8d-47cd-a7b6-d983b5ae6d4d@github.com>

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

Volker Simonis 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:

  8270100: Fix some inaccurate GC logging

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4727/files
  - new: https://git.openjdk.java.net/jdk/pull/4727/files/dcb1f71e..afef6ad4

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

  Stats: 53 lines in 4 files changed: 20 ins; 9 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4727.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4727/head:pull/4727

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


From simonis at openjdk.java.net  Wed Jul 14 08:22:16 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Jul 2021 08:22:16 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <iLh6JS4xunfsO0VWk114SWyCZ2WERNBedEBizA0CgiQ=.7e0473f3-5f47-4bb1-bd9a-9f8dd0f63751@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>
 <ns2EfuLGZToMOaREldOKAV5Bw1x1DWFIBlXvMf8zq7s=.6282c474-42d7-4a91-af78-0edf6f89feb5@github.com>
 <qhfJdAtGbLEBogCMlWR0n2e-qzxXc8HTDWikWmstouE=.e733711a-e43d-41c2-a211-376afb257ad9@github.com>
 <iLh6JS4xunfsO0VWk114SWyCZ2WERNBedEBizA0CgiQ=.7e0473f3-5f47-4bb1-bd9a-9f8dd0f63751@github.com>
Message-ID: <bnvB6mS5DaXyGQpfTilefZ2Zh2UhC0olEKfdx7-CNLA=.63f356b1-628e-4574-b20b-5421ef090249@github.com>

On Tue, 13 Jul 2021 09:40:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk  your latest proposal is still changing the current semantics. Before, the shrink factor was reset on every invocation of `CardGeneration::compute_new_size()`. With your proposal, it will only be reset if we expand the heap.
>> 
>> My patch is really just a trivial fix of some logging errors. I'm not against changing or improving it, but before I introduce any behavioral changes, I'd like to hear a second opinion.
>
>> Before, the shrink factor was reset on every invocation of CardGeneration::compute_new_size(). With your proposal, it will only be reset if we expand the heap.
> 
> Indeed, my suggestion is flawed.
> 
>> "decaying" the shrink factor on every CardGeneration::compute_new_size() call makes sense.
> 
> Agree.
> 
>> so I would probably just set current_shrink_factor and _shrink_factor to 100 at the top of CardGeneration::compute_new_size if ShrinkHeapInSteps is false
> 
> Sounds good to me.
> 
> Re `NewSizeThreadIncrease`, what's the motivation for having it (used only by Serial) in the first place? Going through the git-log, I can only find the overflow-fix from JDK-8144527.

@albertnetymk, @tschatzl thanks for your feedback. From what I understand we all agree that this change should only fix the reported GC logging issues without changing the semantics or behavior of the underlying GC algorithm. My new version of the fix tries to achieve exactly this based on your recommendations:

- I've introduced a new helper function `calculate_thread_increase_size()` which takes the number of threads as an argument and returns the `thread_increase_size` which is then passed to `calculate_thread_increase_size()`.
- For the shrink factor I now set `_shrink_factor` to 100 right in the constructor if `ShrinkHeapInSteps` is not set and never change it. Notice that  `ShrinkHeapInSteps` is not manageable, so this should be fine. If  `ShrinkHeapInSteps` is true, `_shrink_factor` will be reset to zero at every invocation of `CardGeneration::compute_new_size()` just as before the change.
 
 With these changes the logging issues are fixed without any change in functionality.

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 08:29:31 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 08:29:31 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v3]
In-Reply-To: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
Message-ID: <c13bQlh0shEsQ9Vc0y1OM0jAUZhGUA8Sowf7-0rPGCo=.fe79e0de-7d87-4e07-8185-7ce73466e934@github.com>

> Hi all,
> 
>   can I get reviews for some further cleanup of the young collection code:
> - adding some more scoped objects (verification, gc pause timing)
> - some naming, minor related code movement
> 
> Thanks,
>   Thomas

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

  ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4768/files
  - new: https://git.openjdk.java.net/jdk/pull/4768/files/7730aa6d..b9b53f8d

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

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 08:29:31 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 08:29:31 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v2]
In-Reply-To: <rEIK7ov5jbLcYBIXaDg82ytRUgQPLko_xcD_VbmAyIc=.b97d045d-b390-42f6-8a52-8b6ddc9a38a4@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <RQNHZAqEAt2xp_LlLrvLcfubUJey1lCXVLZe2IDe7TU=.2ed3d37f-ad6e-4796-8ef7-c7ede7d95cdf@github.com>
 <GU2rJJE3M-GOP3lWP7lBoOgoMXhb5ny2pTWyAG4f4c8=.81f529ac-480f-469a-9440-fed932636a64@github.com>
 <gBskNejyHTQzpEHwF8lQapCdHGlcf7dOdvZh-meAPgU=.cf0f1734-f2b5-4aa5-8335-7d4da951f30b@github.com>
 <rEIK7ov5jbLcYBIXaDg82ytRUgQPLko_xcD_VbmAyIc=.b97d045d-b390-42f6-8a52-8b6ddc9a38a4@github.com>
Message-ID: <USpy8tgXYDaSxAIYX5yKXhG92iUP4p1IQLejdkrQZfI=.58c28637-8679-42dc-bc04-6949a5aae4fd@github.com>

On Wed, 14 Jul 2021 07:44:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Added comments. `gc_pause` is the whole pause, `collection` is about just the collection part (as defined by the inner scope of the `do_collection_pause_at_safepoint_helper`). Feel free to suggest better naming.
>
> Maybe something like `record_young_collection_work_start`; another question is whether we should keep the `note_` prefix for the pause or change it to `record_` as well as it seems quite common.

I suggest we change to record_

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

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


From ayang at openjdk.java.net  Wed Jul 14 08:42:14 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 08:42:14 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v3]
In-Reply-To: <c13bQlh0shEsQ9Vc0y1OM0jAUZhGUA8Sowf7-0rPGCo=.fe79e0de-7d87-4e07-8185-7ce73466e934@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <c13bQlh0shEsQ9Vc0y1OM0jAUZhGUA8Sowf7-0rPGCo=.fe79e0de-7d87-4e07-8185-7ce73466e934@github.com>
Message-ID: <4t1Whwpn4BrA-Mv_OX8ZcjIwCnACh4vNy5LfoP-q28I=.1d928934-59ef-4a45-aa15-4f8308802c37@github.com>

On Wed, 14 Jul 2021 08:29:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for some further cleanup of the young collection code:
>> - adding some more scoped objects (verification, gc pause timing)
>> - some naming, minor related code movement
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Marked as reviewed by ayang (Committer).

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 09:08:38 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 09:08:38 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v4]
In-Reply-To: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
Message-ID: <BmURyBWwpP4mHix1EhCKINPquiGNt4jLMRQwpbjMY7M=.777e83b2-2aa6-465a-ac99-690ed87e96a8@github.com>

> Hi all,
> 
>   can I get reviews for some further cleanup of the young collection code:
> - adding some more scoped objects (verification, gc pause timing)
> - some naming, minor related code movement
> 
> Thanks,
>   Thomas

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

  Change note_ to record_

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4768/files
  - new: https://git.openjdk.java.net/jdk/pull/4768/files/b9b53f8d..b6be6fc5

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

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 09:08:38 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 09:08:38 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v4]
In-Reply-To: <BmURyBWwpP4mHix1EhCKINPquiGNt4jLMRQwpbjMY7M=.777e83b2-2aa6-465a-ac99-690ed87e96a8@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <BmURyBWwpP4mHix1EhCKINPquiGNt4jLMRQwpbjMY7M=.777e83b2-2aa6-465a-ac99-690ed87e96a8@github.com>
Message-ID: <GOLXn4oUH96NdEzVbznSm6Bk113EBU41chq1lBiq4tE=.b3b75b29-09fc-48e1-be5e-5c5f33d837de@github.com>

On Wed, 14 Jul 2021 09:04:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for some further cleanup of the young collection code:
>> - adding some more scoped objects (verification, gc pause timing)
>> - some naming, minor related code movement
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change note_ to record_

lgtm!

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

Marked as reviewed by iwalulya (Committer).

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


From ayang at openjdk.java.net  Wed Jul 14 09:16:15 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 09:16:15 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging [v2]
In-Reply-To: <FYmaBvSJCAV35YkJiV4AJooNL-uMHlVYPNm2waKAOGs=.c3eaecd0-5f8d-47cd-a7b6-d983b5ae6d4d@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <FYmaBvSJCAV35YkJiV4AJooNL-uMHlVYPNm2waKAOGs=.c3eaecd0-5f8d-47cd-a7b6-d983b5ae6d4d@github.com>
Message-ID: <x_Wxv2U1S5ip2eiqXDk42DnQm6j96l8ji0zsJLixtg4=.31a5169d-c7ab-4fed-93c6-f691badda893@github.com>

On Wed, 14 Jul 2021 08:12:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
>> 
>> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
>> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
>> 
>> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
>> 
>> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
>> 
>> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
>> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
>> 
>> 
>> The fix is trivial.
>
> Volker Simonis has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by ayang (Committer).

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 09:34:30 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 09:34:30 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding
Message-ID: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>

Hi all,

Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 

Testing: Tier 1-3

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

Commit messages:
 - refactor G1BlockOffsetTablePart::block_at_or_preceding to add assert precondition

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 11:21:13 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 11:21:13 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging [v2]
In-Reply-To: <FYmaBvSJCAV35YkJiV4AJooNL-uMHlVYPNm2waKAOGs=.c3eaecd0-5f8d-47cd-a7b6-d983b5ae6d4d@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <FYmaBvSJCAV35YkJiV4AJooNL-uMHlVYPNm2waKAOGs=.c3eaecd0-5f8d-47cd-a7b6-d983b5ae6d4d@github.com>
Message-ID: <nYob47-OCJe0k5qxnkZT3GFJiiKz3mE2qE4mT5wHOxk=.ff64b666-3fb9-4626-8a9e-26edca6c0286@github.com>

On Wed, 14 Jul 2021 08:12:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
>> 
>> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
>> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
>> 
>> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
>> 
>> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
>> 
>> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
>> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
>> 
>> 
>> The fix is trivial.
>
> Volker Simonis 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:
> 
>   8270100: Fix some inaccurate GC logging

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 11:33:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 11:33:20 GMT
Subject: RFR: 8270455: Remove unused JFR tracer related code in G1CollectedHeap
Message-ID: <O0m_Z2eXcuuZVnsWbUVCs9HvoTDDjR8Z6SjBlqobWis=.334447a3-14e1-4137-8162-e0ac550a8f10@github.com>

Hi,

  please review this unused code deletion.

Testing: local build.

Thanks,
  Thomas

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

Commit messages:
 - Remove unused code

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

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


From ayang at openjdk.java.net  Wed Jul 14 11:46:10 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 11:46:10 GMT
Subject: RFR: 8270455: Remove unused JFR tracer related code in
 G1CollectedHeap
In-Reply-To: <O0m_Z2eXcuuZVnsWbUVCs9HvoTDDjR8Z6SjBlqobWis=.334447a3-14e1-4137-8162-e0ac550a8f10@github.com>
References: <O0m_Z2eXcuuZVnsWbUVCs9HvoTDDjR8Z6SjBlqobWis=.334447a3-14e1-4137-8162-e0ac550a8f10@github.com>
Message-ID: <mum5Dj3kNzGu_0ELaAMAToLNo1sqGc6gY4scmmA7GHI=.87fc6fe4-22d0-4ee1-b095-eaedb8854a07@github.com>

On Wed, 14 Jul 2021 11:25:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   please review this unused code deletion.
> 
> Testing: local build.
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Committer).

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

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


From ayang at openjdk.java.net  Wed Jul 14 12:30:11 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 12:30:11 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
Message-ID: <IKLwNEjD93QC_UfD-VEjZcMn6WzaqHLwSlDx3ReGAfc=.3c12485b-3e22-48fa-b481-9fa418569811@github.com>

On Wed, 14 Jul 2021 09:26:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
> 
> Testing: Tier 1-3

Re `if (addr >= _hr->bottom() && addr < _hr->top()) {`, I don't think we ever pass `addr` outside `[bottom, top)`, so I suggest restore the original code and change this to an assert in another PR.

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 12:33:11 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 12:33:11 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <IKLwNEjD93QC_UfD-VEjZcMn6WzaqHLwSlDx3ReGAfc=.3c12485b-3e22-48fa-b481-9fa418569811@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <IKLwNEjD93QC_UfD-VEjZcMn6WzaqHLwSlDx3ReGAfc=.3c12485b-3e22-48fa-b481-9fa418569811@github.com>
Message-ID: <Rldf5Eohx-xJGT91Pg1-aO0NJfU6CWKyCwwoJZCgtD4=.9f1b7d48-bf10-42e4-baec-11b84acf106f@github.com>

On Wed, 14 Jul 2021 12:27:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Re `if (addr >= _hr->bottom() && addr < _hr->top()) {`, I don't think we ever pass `addr` outside `[bottom, top)`, so I suggest restore the original code and change this to an assert in another PR.

Thanks, will do that.

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 12:38:33 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 12:38:33 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v2]
In-Reply-To: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
Message-ID: <3vfTZbjINu057ASBHdZSbkfQW5bqUa7HGr-IAtA8ZvY=.62f41a8e-dbe2-4bdc-b2b1-04fd68748ba7@github.com>

> Hi all,
> 
> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
> 
> Testing: Tier 1-3

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

  @albert suggested changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4775/files
  - new: https://git.openjdk.java.net/jdk/pull/4775/files/ea6c0c3c..96ff7958

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

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 12:58:37 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 12:58:37 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
Message-ID: <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>

> Hi all,
> 
> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
> 
> Testing: Tier 1-3

Ivan Walulya 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:

  @albertnetymk suggested changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4775/files
  - new: https://git.openjdk.java.net/jdk/pull/4775/files/96ff7958..1d71c8cb

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

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

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


From ayang at openjdk.java.net  Wed Jul 14 12:58:37 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 12:58:37 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
Message-ID: <9IRUDIHkE59li5OeDHtrJQ2O54nn-mieB0gNObWbF9E=.4a99f04e-0e16-46ff-a4c4-caaabf070441@github.com>

On Wed, 14 Jul 2021 12:47:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya 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:
> 
>   @albertnetymk suggested changes

Marked as reviewed by ayang (Committer).

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 14:17:18 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 14:17:18 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
Message-ID: <8KcyklGYPHNsFKFvj6SD2oy309QoGWB_Nc5GeZ83I_0=.6a0bb917-bdc0-4cdb-b759-bb2b56ae53b4@github.com>

On Wed, 14 Jul 2021 12:58:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya 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.

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

> 117:   size_t index = _bot->index_for(addr);
> 118:   // We must make sure that the offset table entry we use is valid.
> 119:   assert(index < _next_offset_index, "Precondition");

I feel a bit uneasy that the caller (`block_start`) allows more than the callee (values `< _hr->end()`), but this is probably the change that is supposed to be coming?
Looks good, but I would have preferred the original change or the upcoming change with some asserts included.

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 14:23:10 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 14:23:10 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <8KcyklGYPHNsFKFvj6SD2oy309QoGWB_Nc5GeZ83I_0=.6a0bb917-bdc0-4cdb-b759-bb2b56ae53b4@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
 <8KcyklGYPHNsFKFvj6SD2oy309QoGWB_Nc5GeZ83I_0=.6a0bb917-bdc0-4cdb-b759-bb2b56ae53b4@github.com>
Message-ID: <8FO47aDkX2iqRAfUbzTfxnB05MbcY_PA2jWXtp5IdZc=.19836bbc-ac3a-43b6-9cfb-0fb681837a54@github.com>

On Wed, 14 Jul 2021 14:13:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Ivan Walulya 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.
>
> src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 119:
> 
>> 117:   size_t index = _bot->index_for(addr);
>> 118:   // We must make sure that the offset table entry we use is valid.
>> 119:   assert(index < _next_offset_index, "Precondition");
> 
> I feel a bit uneasy that the caller (`block_start`) allows more than the callee (values `< _hr->end()`), but this is probably the change that is supposed to be coming?
> Looks good, but I would have preferred the original change or the upcoming change with some asserts included.

I can add the deferred change, instead of splitting it off into a separate PR.

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

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


From ayang at openjdk.java.net  Wed Jul 14 14:42:09 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 14 Jul 2021 14:42:09 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <8FO47aDkX2iqRAfUbzTfxnB05MbcY_PA2jWXtp5IdZc=.19836bbc-ac3a-43b6-9cfb-0fb681837a54@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
 <8KcyklGYPHNsFKFvj6SD2oy309QoGWB_Nc5GeZ83I_0=.6a0bb917-bdc0-4cdb-b759-bb2b56ae53b4@github.com>
 <8FO47aDkX2iqRAfUbzTfxnB05MbcY_PA2jWXtp5IdZc=.19836bbc-ac3a-43b6-9cfb-0fb681837a54@github.com>
Message-ID: <XWrGboA-x-48wkJqbVixXRxecz7BUOsPAoBbczDrcfg=.94c51963-17a0-4201-95cd-8b73af89e714@github.com>

On Wed, 14 Jul 2021 14:19:51 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp line 119:
>> 
>>> 117:   size_t index = _bot->index_for(addr);
>>> 118:   // We must make sure that the offset table entry we use is valid.
>>> 119:   assert(index < _next_offset_index, "Precondition");
>> 
>> I feel a bit uneasy that the caller (`block_start`) allows more than the callee (values `< _hr->end()`), but this is probably the change that is supposed to be coming?
>> Looks good, but I would have preferred the original change or the upcoming change with some asserts included.
>
> I can add the deferred change, instead of splitting it off into a separate PR.

> the caller (block_start) allows more than the callee (values < _hr->end())

That path should never be taken, so I am not worried about. I suggested putting that in another PR since those assertions are not obvious from the current ticket title. Anyway, this is subjective.

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 15:15:16 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 15:15:16 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
Message-ID: <-IbiYlA-ir4scLY6h_ljlu4jJt5HwIq0EReg9EsTi0s=.77832747-b733-4f66-9322-8e3f1bece49c@github.com>

On Wed, 14 Jul 2021 12:58:37 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
>> 
>> Testing: Tier 1-3
>
> Ivan Walulya 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:
> 
>   @albertnetymk suggested changes

Marked as reviewed by tschatzl (Reviewer).

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 15:15:16 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 15:15:16 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding [v3]
In-Reply-To: <XWrGboA-x-48wkJqbVixXRxecz7BUOsPAoBbczDrcfg=.94c51963-17a0-4201-95cd-8b73af89e714@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <Vz0RIwlNSVsmfwMZ1hqfRY1mgaHVR7_usRQLbM-D8UM=.c13bf6f4-250b-4ca6-8f56-7eb5b943d1d9@github.com>
 <8KcyklGYPHNsFKFvj6SD2oy309QoGWB_Nc5GeZ83I_0=.6a0bb917-bdc0-4cdb-b759-bb2b56ae53b4@github.com>
 <8FO47aDkX2iqRAfUbzTfxnB05MbcY_PA2jWXtp5IdZc=.19836bbc-ac3a-43b6-9cfb-0fb681837a54@github.com>
 <XWrGboA-x-48wkJqbVixXRxecz7BUOsPAoBbczDrcfg=.94c51963-17a0-4201-95cd-8b73af89e714@github.com>
Message-ID: <SL9iHmoAe73RwMPvGtGSzpvFdpqqOIfwshJhQlmQ6fg=.07f7343f-1f31-46b7-ac56-b204a5ab3650@github.com>

On Wed, 14 Jul 2021 14:38:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I can add the deferred change, instead of splitting it off into a separate PR.
>
>> the caller (block_start) allows more than the callee (values < _hr->end())
> 
> That path should never be taken, so I am not worried about. I suggested putting that in another PR since those assertions are not obvious from the current ticket title. Anyway, this is subjective.

@albertnetymk : I know. Still it seems something is missing to me, but that's subjective. Let's just defer it.

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

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


From tschatzl at openjdk.java.net  Wed Jul 14 15:33:21 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 14 Jul 2021 15:33:21 GMT
Subject: RFR: 8270475: Remove unused G1STWDrainQueueClosure
Message-ID: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>

Hi all,

  can I have reviews for this removal of unused code?

Testing: local compilation

Thanks,
  Thomas

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

Commit messages:
 - Remove G1STWDrainQueueClosure

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

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


From iwalulya at openjdk.java.net  Wed Jul 14 15:48:11 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Wed, 14 Jul 2021 15:48:11 GMT
Subject: RFR: 8270475: Remove unused G1STWDrainQueueClosure
In-Reply-To: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
References: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
Message-ID: <F3wj8mH4DzXrhfQRMeUDJuO_bsFQvy8LS37lrjbJ7ok=.8ee9bc8d-6e86-4cdc-a69c-c8e77688f7c6@github.com>

On Wed, 14 Jul 2021 15:25:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this removal of unused code?
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Committer).

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

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


From simonis at openjdk.java.net  Wed Jul 14 17:42:12 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Jul 2021 17:42:12 GMT
Subject: RFR: 8270100: Fix some inaccurate GC logging
In-Reply-To: <iLh6JS4xunfsO0VWk114SWyCZ2WERNBedEBizA0CgiQ=.7e0473f3-5f47-4bb1-bd9a-9f8dd0f63751@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
 <xzMMTRV7nRHXqLvGWSY7ll1EzuCka3xb50s8OjdLwpw=.9a39a740-d4fb-4c43-a39d-80ca0ac9aac3@github.com>
 <ns2EfuLGZToMOaREldOKAV5Bw1x1DWFIBlXvMf8zq7s=.6282c474-42d7-4a91-af78-0edf6f89feb5@github.com>
 <qhfJdAtGbLEBogCMlWR0n2e-qzxXc8HTDWikWmstouE=.e733711a-e43d-41c2-a211-376afb257ad9@github.com>
 <iLh6JS4xunfsO0VWk114SWyCZ2WERNBedEBizA0CgiQ=.7e0473f3-5f47-4bb1-bd9a-9f8dd0f63751@github.com>
Message-ID: <2EOHX8u29rWuolfH9WM00QKUd0n5R7sP8LFncwLi8OA=.4697abb4-8b12-44f4-b5a6-36c0ca0445de@github.com>

On Tue, 13 Jul 2021 09:40:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> @albertnetymk  your latest proposal is still changing the current semantics. Before, the shrink factor was reset on every invocation of `CardGeneration::compute_new_size()`. With your proposal, it will only be reset if we expand the heap.
>> 
>> My patch is really just a trivial fix of some logging errors. I'm not against changing or improving it, but before I introduce any behavioral changes, I'd like to hear a second opinion.
>
>> Before, the shrink factor was reset on every invocation of CardGeneration::compute_new_size(). With your proposal, it will only be reset if we expand the heap.
> 
> Indeed, my suggestion is flawed.
> 
>> "decaying" the shrink factor on every CardGeneration::compute_new_size() call makes sense.
> 
> Agree.
> 
>> so I would probably just set current_shrink_factor and _shrink_factor to 100 at the top of CardGeneration::compute_new_size if ShrinkHeapInSteps is false
> 
> Sounds good to me.
> 
> Re `NewSizeThreadIncrease`, what's the motivation for having it (used only by Serial) in the first place? Going through the git-log, I can only find the overflow-fix from JDK-8144527.

Thanks for the reviews @albertnetymk, @tschatzl!

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

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


From simonis at openjdk.java.net  Wed Jul 14 17:42:12 2021
From: simonis at openjdk.java.net (Volker Simonis)
Date: Wed, 14 Jul 2021 17:42:12 GMT
Subject: Integrated: 8270100: Fix some inaccurate GC logging
In-Reply-To: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
References: <wxFe5nDVmyZZbGPYmpwurDI2KebOAk7zq8uHRvTb94c=.cbe5d13e-8c40-47c0-bddf-f580a4d84d01@github.com>
Message-ID: <XDEzoOThv6H-i8EI6ZdfLVTwMab2JSOiS9OTyDJ7sk4=.55e3eff4-5e6a-4465-a22f-534c200e4e31@github.com>

On Thu, 8 Jul 2021 15:19:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

This pull request has now been integrated.

Changeset: fb86d13e
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fb86d13ec44f4c8bb933fe16673dabce785d2e05
Stats:     46 lines in 4 files changed: 22 ins; 8 del; 16 mod

8270100: Fix some inaccurate GC logging

Reviewed-by: ayang, tschatzl

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

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


From kbarrett at openjdk.java.net  Thu Jul 15 06:58:43 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Jul 2021 06:58:43 GMT
Subject: RFR: 8269032: Stringdedup tests are failing if the ergonomically
 select GC does not support it [v2]
In-Reply-To: <gob-32HZdZzd85x_uuzyveMWhQiAXgpQ1sOSGX6Zptc=.fdb3478b-1089-4c14-8c64-6c7fa3060f40@github.com>
References: <gob-32HZdZzd85x_uuzyveMWhQiAXgpQ1sOSGX6Zptc=.fdb3478b-1089-4c14-8c64-6c7fa3060f40@github.com>
Message-ID: <dUXcz3fFAv6t8nW2qtNOOEXn4ZcuVBBLUxd7xL1ToOM=.f336efa3-02e2-47a3-a0a5-da81b0f4d80c@github.com>

> Please review this change to the string deduplication tests' handling of an
> ergonomically chosen GC.  They were assuming G1 would be chosen in that
> case, but that's wrong of course.  The test machine might not be a server
> class machine, or G1 might not be included in the build.
> 
> Each test now has a second test declaration comment for handling the case
> where no GC is specified by the jtreg invocation.  This second declaration
> will force the use of G1 by the test if G1 is supported by the VM.
> 
> I looked into trying to be more clever and selecting a different GC if G1 is
> not supported by the VM, but that ended up making the tests a lot more
> messy, and doesn't seem like that important a use-case at this time.  A
> better long-term solution would be to make all the GCs (except Epsilon)
> support string deduplication, so we don't care which GC gets ergonomically
> chosen.  But that's not happening today.
> 
> Testing:
> Ran the string deduplication tests with various configurations: (1)
> explicitly use G1 (2) no explicit GC, (3) no explicit GC with
> -XX:+NeverActAsServerClassMachine.

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

  separate test class per gc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4603/files
  - new: https://git.openjdk.java.net/jdk/pull/4603/files/fa6a21bf..7d1db0e4

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

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

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


From kbarrett at openjdk.java.net  Thu Jul 15 07:03:09 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Jul 2021 07:03:09 GMT
Subject: RFR: 8270475: Remove unused G1STWDrainQueueClosure
In-Reply-To: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
References: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
Message-ID: <6OQ8k2nbG1BgQAQQ-yPxfniF23N8VfTvpbE_CK-Tu8E=.789eadad-eb28-4cf0-8ffc-80db51ec858c@github.com>

On Wed, 14 Jul 2021 15:25:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this removal of unused code?
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Thu Jul 15 07:04:15 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Jul 2021 07:04:15 GMT
Subject: RFR: 8269032: Stringdedup tests are failing if the ergonomically
 select GC does not support it [v2]
In-Reply-To: <1SjAn8ckeeHdYoPXBY_ILllsF5IypGxkdxq6DRqWZso=.da526856-2d5c-4226-9c68-8029f165c01b@github.com>
References: <gob-32HZdZzd85x_uuzyveMWhQiAXgpQ1sOSGX6Zptc=.fdb3478b-1089-4c14-8c64-6c7fa3060f40@github.com>
 <wJVsSjHSA3wVFfG98grOH00D0f0q3YY2GDPcTdCUDW0=.3e55bf4f-ca57-4de1-abc2-c17f5f5428d6@github.com>
 <913Oe37_H9mrQHhxdABCj2OTftRSsCQxmdx8xIczOlI=.e198c019-cd37-4560-a78c-cc65d7fc527a@github.com>
 <WD03XSveS-CJoB1wPxv_dutWqpKm1Ac9ZBig085PyOo=.60e6d935-7eb4-4690-8b64-95cdebc8cfda@github.com>
 <EZR9dr9GpC92ZnSI15Es152yq8SJMfbX1mktobQpOcs=.8dae53af-48f7-4434-89af-0c7fba1fd465@github.com>
 <1SjAn8ckeeHdYoPXBY_ILllsF5IypGxkdxq6DRqWZso=.da526856-2d5c-4226-9c68-8029f165c01b@github.com>
Message-ID: <2YXoDC4aCvbhbrJmpvRnGRWvW60HdczwDwpy559qrPE=.e873c7eb-fab5-483b-abe9-6565f6902dba@github.com>

On Wed, 30 Jun 2021 12:34:23 GMT, Per Liden <pliden at openjdk.org> wrote:

>> That's an approach that I had looked at but decided not to take.
>> 
>> It involves having a near duplicated `@test` block for each GC that supports
>> deduplication, at least until they all do (other than Epsilon).
>> 
>> I think it wastes testing resources. Each testing configuration that allows
>> ergonomic GC selection will run these tests for every supporting and
>> included GC.  Individually it's not terrible, but this sort of thing adds up.
>
> I don't think that's a problem you should attempt solve in this PR. It's a much wider problem, affects many more tests and I don't think there's necessarily consensus on what should happen if you run a test and don't explicitly set a GC. At the moment, tests in this category typically run with all GCs, and that's so far been what to expect. I suggest we continue to follow our current model for stringdedup tests until there's consensus on what a new model should look like, and only then start to move tests in a new direction. Even if the current model is sub-optimal and messy, introducing a new type of behavior for these tests seems to just add to the mess, and there's at least some value in having tests behave the same way.
> 
> If we want to move in the direction where running a test without specifying a GC will run it once with the ergonomically selected GC, then it might be that simply altering the meaning of `vm.gc.XXX` to "XXX is supported and selected (explicitly or ergonomically)" is enough. Of course, it's tricky to clearly see that all use cases are covered, so something like this will need more careful investigation.

After thinking about it for a while, I've decided to go with Per's suggestion. I don't really like the duplication of `@test` blocks, but I don't like any of the other options either.

Tested by locally (linux-x64) configuring with Shenandoah included and running the gc/stringdedup tests with
(1) no additional options,
(2) -XX:+NeverActAsServerClassMachine,
(3) -XX:+UseG1GC,
(4) -XX:+UseShenandoahGC
and verifying the expected tests were run.

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

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


From kbarrett at openjdk.java.net  Thu Jul 15 07:19:16 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Jul 2021 07:19:16 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v4]
In-Reply-To: <BmURyBWwpP4mHix1EhCKINPquiGNt4jLMRQwpbjMY7M=.777e83b2-2aa6-465a-ac99-690ed87e96a8@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <BmURyBWwpP4mHix1EhCKINPquiGNt4jLMRQwpbjMY7M=.777e83b2-2aa6-465a-ac99-690ed87e96a8@github.com>
Message-ID: <RhJfHCOsJx9WzSpBEKx2Eo6d_TN5nCvSiY_nrfekgEw=.f70c0db0-49ff-4f7e-a68e-cb25d78cbf74@github.com>

On Wed, 14 Jul 2021 09:08:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for some further cleanup of the young collection code:
>> - adding some more scoped objects (verification, gc pause timing)
>> - some naming, minor related code movement
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change note_ to record_

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1Policy.cpp line 635:

> 633:   G1GCPhaseTimes* p = phase_times();
> 634: 
> 635:   double start_time_s = phase_times()->cur_collection_start_sec();

I dislike this change of nomenclature to use `_s` suffix instead of `_sec` suffix to indicate units of seconds.  The latter is in wide use in GC code.

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

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


From tschatzl at openjdk.java.net  Thu Jul 15 07:51:35 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 15 Jul 2021 07:51:35 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v5]
In-Reply-To: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
Message-ID: <XL1Y3yWBCBJeVHNKDhJRK9YMeIqC_OY-BN3CIYTVzL0=.017841b1-d408-46ab-a1dd-33756ef2f29f@github.com>

> Hi all,
> 
>   can I get reviews for some further cleanup of the young collection code:
> - adding some more scoped objects (verification, gc pause timing)
> - some naming, minor related code movement
> 
> Thanks,
>   Thomas

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

  kbarrett review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4768/files
  - new: https://git.openjdk.java.net/jdk/pull/4768/files/b6be6fc5..86dfe715

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

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

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


From kbarrett at openjdk.java.net  Thu Jul 15 08:11:17 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 15 Jul 2021 08:11:17 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v5]
In-Reply-To: <XL1Y3yWBCBJeVHNKDhJRK9YMeIqC_OY-BN3CIYTVzL0=.017841b1-d408-46ab-a1dd-33756ef2f29f@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <XL1Y3yWBCBJeVHNKDhJRK9YMeIqC_OY-BN3CIYTVzL0=.017841b1-d408-46ab-a1dd-33756ef2f29f@github.com>
Message-ID: <7hzTXv-rf_bfWGDvwFdaxVtv4P6dis1iCKa-XugSsas=.14114f3d-7b77-471e-a374-05d242689a5a@github.com>

On Thu, 15 Jul 2021 07:51:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for some further cleanup of the young collection code:
>> - adding some more scoped objects (verification, gc pause timing)
>> - some naming, minor related code movement
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Jul 15 08:14:21 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 15 Jul 2021 08:14:21 GMT
Subject: RFR: 8270475: Remove unused G1STWDrainQueueClosure
In-Reply-To: <F3wj8mH4DzXrhfQRMeUDJuO_bsFQvy8LS37lrjbJ7ok=.8ee9bc8d-6e86-4cdc-a69c-c8e77688f7c6@github.com>
References: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
 <F3wj8mH4DzXrhfQRMeUDJuO_bsFQvy8LS37lrjbJ7ok=.8ee9bc8d-6e86-4cdc-a69c-c8e77688f7c6@github.com>
Message-ID: <dusv-AtXhqQSdOGqdtGryk0NG7JJ8YvTbRqLiF8UvgU=.211efd36-9c6a-456e-999c-3b8ecd68676c@github.com>

On Wed, 14 Jul 2021 15:45:02 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this removal of unused code?
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by iwalulya (Committer).

Thanks @walulyai @kimbarrett for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Jul 15 08:14:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 15 Jul 2021 08:14:22 GMT
Subject: Integrated: 8270475: Remove unused G1STWDrainQueueClosure
In-Reply-To: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
References: <IbyOv9FLP6LwfeI9mxyFu-ewST57chbnqgtxKMqhqNA=.77c3a0e0-7ffb-4544-a305-0ecfc74d62fd@github.com>
Message-ID: <TSZXeeFqgJZuc9iZIT3NIoDa815uGsQLzTLtBHGB4KY=.26b98a15-ddbd-4d7e-b02c-d96cd71a47b1@github.com>

On Wed, 14 Jul 2021 15:25:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this removal of unused code?
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

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

8270475: Remove unused G1STWDrainQueueClosure

Reviewed-by: iwalulya, kbarrett

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

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


From tschatzl at openjdk.java.net  Thu Jul 15 08:16:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 15 Jul 2021 08:16:22 GMT
Subject: RFR: 8270014: Add scoped objects for g1 young gc verification and
 young gc internal timing [v3]
In-Reply-To: <4t1Whwpn4BrA-Mv_OX8ZcjIwCnACh4vNy5LfoP-q28I=.1d928934-59ef-4a45-aa15-4f8308802c37@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
 <c13bQlh0shEsQ9Vc0y1OM0jAUZhGUA8Sowf7-0rPGCo=.fe79e0de-7d87-4e07-8185-7ce73466e934@github.com>
 <4t1Whwpn4BrA-Mv_OX8ZcjIwCnACh4vNy5LfoP-q28I=.1d928934-59ef-4a45-aa15-4f8308802c37@github.com>
Message-ID: <FtccD92GBSYkMbx08ed708nYn0hApCeJcqEO0pBm72c=.c46cf11a-7fdc-4328-bf57-1ffa564588e4@github.com>

On Wed, 14 Jul 2021 08:39:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks @albertnetymk @walulyai @kimbarrett for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Jul 15 08:16:22 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 15 Jul 2021 08:16:22 GMT
Subject: Integrated: 8270014: Add scoped objects for g1 young gc verification
 and young gc internal timing
In-Reply-To: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
References: <n4zYej_Ex75Fa7gXxvzjdGfS6MJrYYbTWUpna5a5rpA=.9b2048b0-4772-40ac-be90-f5581dbcc916@github.com>
Message-ID: <5VSFCd9ldeYegcLiyeB8_rn_tEqYey--OggegEcPaSo=.73ffa801-1556-4337-a1cb-f7e101adf2f7@github.com>

On Tue, 13 Jul 2021 13:51:27 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I get reviews for some further cleanup of the young collection code:
> - adding some more scoped objects (verification, gc pause timing)
> - some naming, minor related code movement
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 7a89ffed
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7a89ffeddd9d68a823e29943cdaa2232bb04bb45
Stats:     88 lines in 7 files changed: 42 ins; 12 del; 34 mod

8270014: Add scoped objects for g1 young gc verification and young gc internal timing

Reviewed-by: ayang, iwalulya, kbarrett

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

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


From iwalulya at openjdk.java.net  Thu Jul 15 08:53:15 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 15 Jul 2021 08:53:15 GMT
Subject: RFR: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <IKLwNEjD93QC_UfD-VEjZcMn6WzaqHLwSlDx3ReGAfc=.3c12485b-3e22-48fa-b481-9fa418569811@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
 <IKLwNEjD93QC_UfD-VEjZcMn6WzaqHLwSlDx3ReGAfc=.3c12485b-3e22-48fa-b481-9fa418569811@github.com>
Message-ID: <iwffnzum5POEI8LPAlzf_a_sEIqYEufqJy2XZMfXslY=.4176b8f6-d890-4119-86dc-8ade63dd1957@github.com>

On Wed, 14 Jul 2021 12:27:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
>> 
>> Testing: Tier 1-3
>
> Re `if (addr >= _hr->bottom() && addr < _hr->top()) {`, I don't think we ever pass `addr` outside `[bottom, top)`, so I suggest restore the original code and change this to an assert in another PR.

Thanks @albertnetymk and @tschatzl for the reviews!

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

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


From iwalulya at openjdk.java.net  Thu Jul 15 08:53:16 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 15 Jul 2021 08:53:16 GMT
Subject: Integrated: 8264908: Investigate adding BOT range check in
 G1BlockOffsetTablePart::block_at_or_preceding
In-Reply-To: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
References: <OU-S4cA1qI9eb13cNAjEZMMMighCfaQ-JN3g3HsF-0Y=.a6c22027-c84f-4134-b287-4d83b3faede4@github.com>
Message-ID: <eQTgKT8BVUsXZtFnNyfsJjucXurMg9BzZ7IicQz-Nu8=.ea7d9c39-6a86-4def-999b-993f30f67c11@github.com>

On Wed, 14 Jul 2021 09:26:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this cleanup change to add an assert to G1BlockOffsetTablePart::block_at_or_preceding. Additionally, remove code that attempts to read beyond the _next_offset_index threshold. 
> 
> Testing: Tier 1-3

This pull request has now been integrated.

Changeset: 99d7f9a7
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99d7f9a772ee3e6f9721e8bff95df553e6a04747
Stats:     58 lines in 2 files changed: 0 ins; 56 del; 2 mod

8264908: Investigate adding BOT range check in G1BlockOffsetTablePart::block_at_or_preceding

Reviewed-by: ayang, tschatzl

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

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


From jvernee at openjdk.java.net  Thu Jul 15 10:50:36 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 10:50:36 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
Message-ID: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com>

On Wed, 14 Jul 2021 00:24:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Assert frame is correct type in frame_data_for_frame
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 86:
> 
>> 84:   context->new_handles = JNIHandleBlock::allocate_block(thread);
>> 85: 
>> 86:   // After this, we are official in Java Code. This needs to be done before we change any of the thread local
> 
> typo: s/official/officially/
> (I see this was copied from Javacalls)

Thanks, I wasn't sure whether to leave the comments in or not.

> src/hotspot/share/prims/universalUpcallHandler.cpp line 114:
> 
>> 112:   thread->set_active_handles(context->new_handles);     // install new handle block and reset Java frame linkage
>> 113: 
>> 114:   assert (thread->thread_state() != _thread_in_native, "cannot set native pc to NULL");
> 
> You transitioned to _thread_in_Java above so how can you possibly have changed state again ?? (okay again copied from javaCalls ...)

Yeah, it seemed paranoid to me as well. I'll remove this

> src/hotspot/share/prims/universalUpcallHandler.cpp line 121:
> 
>> 119:   }
>> 120: 
>> 121:   MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));
> 
> Not clear why this is needed? JavaCallWrapper doesn't use it.

I took this from JavaCallWrapper. Seems to have been added in 17 for the mach aarch64 port: https://github.com/openjdk/jdk17/blame/a32d2eefea12771522b942b32985df0fe50119e8/src/hotspot/share/runtime/javaCalls.cpp#L112

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Thu Jul 15 11:06:13 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 11:06:13 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
 <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>
Message-ID: <hBpL8Lz9hRJ3_Ee8ZhpfyxI3qLSya9yMTRo2fRI6Zdo=.c50761ec-0fb8-45c1-a6f7-99ba2c408512@github.com>

On Wed, 14 Jul 2021 00:50:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepoint.cpp line 931:
>> 
>>> 929:     // See if return type is an oop.
>>> 930:     bool return_oop = nm->method()->is_returning_oop();
>>> 931:     HandleMark hm(self);
>> 
>> I was seeing an `assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark` when the existing code allocates the Handle for `return_value` in the code down below. It seems to be a simple case of a missing handle mark, so I've added it here. (looking at the stack trace in the error log, the caller frame is native code, so I don't think we can expect the caller to have a HandleMark).
>
> How does native code reach a safepoint polling point?

The stack trace looks like this:


Current thread (0x000002a2489f0b50):  JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]

Stack: [0x000000d9e0500000,0x000000d9e0600000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xae6651]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
V  [jvm.dll+0xda3f25]  VMError::report+0x1005  (vmError.cpp:739)
V  [jvm.dll+0xda58ae]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
V  [jvm.dll+0xda5fe4]  VMError::report_and_die+0x64  (vmError.cpp:1330)
V  [jvm.dll+0x4ceca7]  report_vm_error+0xb7  (debug.cpp:282)
V  [jvm.dll+0x6511be]  HandleArea::allocate_handle+0x3e  (handles.cpp:35)
V  [jvm.dll+0xb8e334]  ThreadSafepointState::handle_polling_page_exception+0x314  (safepoint.cpp:939)
C  0x000002a035d8caa7

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v  ~SafepointBlob
J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
v  ~BufferBlob::m?Y?????G?


So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?).

FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff)

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From github.com+39413832+weixlu at openjdk.java.net  Thu Jul 15 12:04:22 2021
From: github.com+39413832+weixlu at openjdk.java.net (Lu Xiaowei)
Date: Thu, 15 Jul 2021 12:04:22 GMT
Subject: RFR: 8270347: ZGC: Adopt release-acquire ordering for forwarding
 table access
Message-ID: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>

ZGC forwarding table records entries to track the destination of object relocation. Currently, the entry insertion (ZForwarding::insert()) adopts memory_order_conservative to guarantee that (1) the object copy always happens before the installation of forwardee, and (2) the other thread that accesses the same entry (ZForwarding::at() with load_acquire semantic) is able to access the correct contents of the forwarded object.

Let us consider memory_order_release for the entry insertion in ZForwarding::insert(). Pairing with the entry access in ZForwarding::at(), the forwarding table adopts release-acquire memory ordering. The two statements we mentioned above can also be guaranteed by the release-acquire ordering.

We performed an experiment on benchmark SPECjvm2008.sunflow on AArch64. The concurrent relocation time is listed below. The optimized version results in shorter average concurrent relocation time. Furthermore, it could benefit the throughput of ZGC.

$ grep "[50]00.*Phase: Concurrent Relocate" optimized.log
[500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.006 / 4.449         4.041 / 5.361         4.041 / 5.361         4.041 / 5.361       ms
[1000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.512 / 5.278         4.213 / 5.278         4.146 / 5.361         4.146 / 5.361       ms
[1500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.831 / 5.524         4.446 / 5.584         4.253 / 5.584         4.253 / 5.584       ms
[2000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.037 / 4.649         4.391 / 5.524         4.281 / 5.584         4.281 / 5.584       ms
[2500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.256 / 4.568         4.198 / 5.022         4.265 / 5.584         4.265 / 5.584       ms
[3000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.032 / 4.424         3.810 / 24.709        4.173 / 24.709        4.173 / 24.709      ms
[3500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.740 / 4.598         3.304 / 4.872         4.050 / 24.709        4.050 / 24.709      ms

$ grep "[50]00.*Phase: Concurrent Relocate" baseline.log
[500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.634 / 5.191         4.425 / 5.490         4.425 / 5.490         4.425 / 5.490       ms
[1000.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.177 / 4.731         4.414 / 5.543         4.400 / 5.543         4.400 / 5.543       ms
[1500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.560 / 4.894         4.441 / 5.543         4.427 / 5.543         4.427 / 5.543       ms
[2000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.509 / 5.100         4.591 / 5.739         4.468 / 5.739         4.468 / 5.739       ms
[2500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.543 / 5.533         4.685 / 5.762         4.511 / 5.762         4.511 / 5.762       ms
[3000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.423 / 4.834         4.635 / 5.895         4.530 / 5.895         4.530 / 5.895       ms
[3500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.152 / 5.243         4.313 / 24.341        4.493 / 24.341        4.493 / 24.341      ms

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

Commit messages:
 - 8270347: ZGC: Adopt release-acquire ordering for forwarding table access

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

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


From github.com+7947546+tanghaoth90 at openjdk.java.net  Thu Jul 15 12:04:22 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Thu, 15 Jul 2021 12:04:22 GMT
Subject: RFR: 8270347: ZGC: Adopt release-acquire ordering for forwarding
 table access
In-Reply-To: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>
References: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>
Message-ID: <kOh-RMdSexPxwFicwR4j_2IOnkMyVHPZANwuuaDj1co=.d36f7999-1524-4a9f-ad59-7cad856455cc@github.com>

On Tue, 13 Jul 2021 06:52:56 GMT, Lu Xiaowei <github.com+39413832+weixlu at openjdk.org> wrote:

> ZGC forwarding table records entries to track the destination of object relocation. Currently, the entry insertion (ZForwarding::insert()) adopts memory_order_conservative to guarantee that (1) the object copy always happens before the installation of forwardee, and (2) the other thread that accesses the same entry (ZForwarding::at() with load_acquire semantic) is able to access the correct contents of the forwarded object.
> 
> Let us consider memory_order_release for the entry insertion in ZForwarding::insert(). Pairing with the entry access in ZForwarding::at(), the forwarding table adopts release-acquire memory ordering. The two statements we mentioned above can also be guaranteed by the release-acquire ordering.
> 
> We performed an experiment on benchmark SPECjvm2008.sunflow on AArch64. The concurrent relocation time is listed below. The optimized version results in shorter average concurrent relocation time. Furthermore, it could benefit the throughput of ZGC.
> 
> $ grep "[50]00.*Phase: Concurrent Relocate" optimized.log
> [500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.006 / 4.449         4.041 / 5.361         4.041 / 5.361         4.041 / 5.361       ms
> [1000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.512 / 5.278         4.213 / 5.278         4.146 / 5.361         4.146 / 5.361       ms
> [1500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.831 / 5.524         4.446 / 5.584         4.253 / 5.584         4.253 / 5.584       ms
> [2000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.037 / 4.649         4.391 / 5.524         4.281 / 5.584         4.281 / 5.584       ms
> [2500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.256 / 4.568         4.198 / 5.022         4.265 / 5.584         4.265 / 5.584       ms
> [3000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.032 / 4.424         3.810 / 24.709        4.173 / 24.709        4.173 / 24.709      ms
> [3500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.740 / 4.598         3.304 / 4.872         4.050 / 24.709        4.050 / 24.709      ms
> 
> $ grep "[50]00.*Phase: Concurrent Relocate" baseline.log
> [500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.634 / 5.191         4.425 / 5.490         4.425 / 5.490         4.425 / 5.490       ms
> [1000.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.177 / 4.731         4.414 / 5.543         4.400 / 5.543         4.400 / 5.543       ms
> [1500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.560 / 4.894         4.441 / 5.543         4.427 / 5.543         4.427 / 5.543       ms
> [2000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.509 / 5.100         4.591 / 5.739         4.468 / 5.739         4.468 / 5.739       ms
> [2500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.543 / 5.533         4.685 / 5.762         4.511 / 5.762         4.511 / 5.762       ms
> [3000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.423 / 4.834         4.635 / 5.895         4.530 / 5.895         4.530 / 5.895       ms
> [3500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.152 / 5.243         4.313 / 24.341        4.493 / 24.341        4.493 / 24.341      ms

https://github.com/openjdk/jdk/pull/4597 implements memory_order_release for AArch64. We think this could benefit ZGC as well.

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

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


From jvernee at openjdk.java.net  Thu Jul 15 12:29:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 12:29:26 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
Message-ID: <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>

On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Assert frame is correct type in frame_data_for_frame
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 76:
> 
>> 74: 
>> 75: // modelled after JavaCallWrapper::JavaCallWrapper
>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
> 
> This should return JavaThread not Thread.

Thanks.

I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:


Subclass
+---
| {Subclass vtable pointer}
| +--- (base class Super)
| | {Super vtable pointer}
| +---
+---


So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.

But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:


class SuperA {
public:
    virtual void foo();
};

class SuperB {
public:
    virtual void bar();
};

class Sub : public SuperA, public SuperB {
public:
    virtual void baz();
};


Results in:


class Sub	size(16):
	+---
 0	| +--- (base class SuperA)
 0	| | {vfptr}
	| +---
 8	| +--- (base class SuperB)
 8	| | {vfptr}
	| +---
	+---

Sub::$vftable at SuperA@:
	| &Sub_meta
	|  0
 0	| &SuperA::foo 
 1	| &Sub::baz 

Sub::$vftable at SuperB@:
	| -8
 0	| &SuperB::bar 

Sub::baz this adjustor: 0


(https://godbolt.org/z/rq9bT8d9d)

It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).

The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Thu Jul 15 12:41:33 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 12:41:33 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
Message-ID: <GOiAjpKpXbCkdLtC_GBmF_SEp4DeVDGP3xj_utAXX8Y=.62bc8742-4b72-4474-97b0-b42dab69854e@github.com>

On Wed, 14 Jul 2021 00:58:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The mapping to JavaCallWrapper seems reasonable but there are a few differences that I'm now assuming stem from the fact upcalls start _thread_in_native while JCW starts from _thread_in_vm?

The main difference stems from the fact that, since these upcalls can come from non-JNI native code, we can not assume that the thread is already attached to the VM, so we do that on the fly instead, and we detach the thread again after the upcall (if needed). Those are what the call to `maybe_attach_and_get_thread` at the start of `on_entry`, and `detach_thread` call at the end of `on_exit` are for.

The other thing is that there is no stack watermark check at the end of `on_exit`. This check is guarded by a check if the thread has any pending exceptions in `JavaCallWrapper`, but since a panama upcall is not allowed to throw any exceptions, I've changed that to an `assert` that checks that there are no pending exceptions at that point instead.

The last thing is that we transition directly from `_thread_in_native` to `_thread_in_Java`, which changes some of the thread transition code.

Other than that, I've tried to mimic what `JavaCallWrapper` does as closely as possible.

Is there anything else that looks different?

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Thu Jul 15 12:47:22 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 12:47:22 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
Message-ID: <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>

On Thu, 15 Jul 2021 12:25:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/prims/universalUpcallHandler.cpp line 76:
>> 
>>> 74: 
>>> 75: // modelled after JavaCallWrapper::JavaCallWrapper
>>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
>> 
>> This should return JavaThread not Thread.
>
> Thanks.
> 
> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:
> 
> 
> Subclass
> +---
> | {Subclass vtable pointer}
> | +--- (base class Super)
> | | {Super vtable pointer}
> | +---
> +---
> 
> 
> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.
> 
> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:
> 
> 
> class SuperA {
> public:
>     virtual void foo();
> };
> 
> class SuperB {
> public:
>     virtual void bar();
> };
> 
> class Sub : public SuperA, public SuperB {
> public:
>     virtual void baz();
> };
> 
> 
> Results in:
> 
> 
> class Sub	size(16):
> 	+---
>  0	| +--- (base class SuperA)
>  0	| | {vfptr}
> 	| +---
>  8	| +--- (base class SuperB)
>  8	| | {vfptr}
> 	| +---
> 	+---
> 
> Sub::$vftable at SuperA@:
> 	| &Sub_meta
> 	|  0
>  0	| &SuperA::foo 
>  1	| &Sub::baz 
> 
> Sub::$vftable at SuperB@:
> 	| -8
>  0	| &SuperB::bar 
> 
> Sub::baz this adjustor: 0
> 
> 
> (https://godbolt.org/z/1665fWzff)
> 
> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).
> 
> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).

Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From david.holmes at oracle.com  Thu Jul 15 12:54:39 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 15 Jul 2021 22:54:39 +1000
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
Message-ID: <ec1abc84-4aff-e8c4-9574-ab788a66c8e9@oracle.com>

On 15/07/2021 10:29 pm, Jorn Vernee wrote:
> On Wed, 14 Jul 2021 00:47:47 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Assert frame is correct type in frame_data_for_frame
>>
>> src/hotspot/share/prims/universalUpcallHandler.cpp line 76:
>>
>>> 74:
>>> 75: // modelled after JavaCallWrapper::JavaCallWrapper
>>> 76: Thread* ProgrammableUpcallHandler::on_entry(OptimizedEntryBlob::FrameData* context) {
>>
>> This should return JavaThread not Thread.
> 
> Thanks.
> 
> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:

Wow! Okay I've never seen anyone query this before. AFAIK whatever we 
store in r15_thread is required to be a correct pointer to the current 
thread object whatever its exact subtype may be. The returned pointer 
has to work correctly for virtual functions and can't be a "sliced" 
Thread instead of the real type. So as far as I know this "just works" 
and I think we'd be in big trouble if it didn't work.

But I don't deal with the under-the-covers parts of the C++ compiler.

David
-----

> 
> Subclass
> +---
> | {Subclass vtable pointer}
> | +--- (base class Super)
> | | {Super vtable pointer}
> | +---
> +---
> 
> 
> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.
> 
> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:
> 
> 
> class SuperA {
> public:
>      virtual void foo();
> };
> 
> class SuperB {
> public:
>      virtual void bar();
> };
> 
> class Sub : public SuperA, public SuperB {
> public:
>      virtual void baz();
> };
> 
> 
> Results in:
> 
> 
> class Sub	size(16):
> 	+---
>   0	| +--- (base class SuperA)
>   0	| | {vfptr}
> 	| +---
>   8	| +--- (base class SuperB)
>   8	| | {vfptr}
> 	| +---
> 	+---
> 
> Sub::$vftable at SuperA@:
> 	| &Sub_meta
> 	|  0
>   0	| &SuperA::foo
>   1	| &Sub::baz
> 
> Sub::$vftable at SuperB@:
> 	| -8
>   0	| &SuperB::bar
> 
> Sub::baz this adjustor: 0
> 
> 
> (https://godbolt.org/z/rq9bT8d9d)
> 
> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).
> 
> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/149
> 


From iwalulya at openjdk.java.net  Thu Jul 15 13:51:22 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 15 Jul 2021 13:51:22 GMT
Subject: RFR: 8270540 G1: Refactor range checking in
 G1BlockOffsetTablePart::block_start* to asserts
Message-ID: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>

Hi all,

Please review this clean-up to replace range checking with asserts. 

Testing: tier 1-3

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

Commit messages:
 - change to asserts

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

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


From ayang at openjdk.java.net  Thu Jul 15 13:51:22 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 15 Jul 2021 13:51:22 GMT
Subject: RFR: 8270540 G1: Refactor range checking in
 G1BlockOffsetTablePart::block_start* to asserts
In-Reply-To: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
References: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
Message-ID: <iskELjBs3a0a-fK0SoiqoPKti6_Sh9n_80aF9TnFg7w=.131fbdcc-76c2-4def-8513-4a7a343de47b@github.com>

On Thu, 15 Jul 2021 13:45:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this clean-up to replace range checking with asserts. 
> 
> Testing: tier 1-3

Marked as reviewed by ayang (Committer).

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

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


From tschatzl at openjdk.java.net  Thu Jul 15 14:57:17 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 15 Jul 2021 14:57:17 GMT
Subject: RFR: 8270540 G1: Refactor range checking in
 G1BlockOffsetTablePart::block_start* to asserts
In-Reply-To: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
References: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
Message-ID: <WLLR8h_9lMzO9rdEa-_eQPPIbAhc76_IMcPd44WQ4M0=.c3cae2d8-b571-460c-8ba2-3db4fdad8d54@github.com>

On Thu, 15 Jul 2021 13:45:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this clean-up to replace range checking with asserts. 
> 
> Testing: tier 1-3

Marked as reviewed by tschatzl (Reviewer).

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

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


From jvernee at openjdk.java.net  Thu Jul 15 15:54:50 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 15:54:50 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Address David's review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/149/files
  - new: https://git.openjdk.java.net/jdk17/pull/149/files/211bf316..128f48db

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

  Stats: 20 lines in 3 files changed: 0 ins; 8 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Thu Jul 15 15:58:16 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 15 Jul 2021 15:58:16 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
Message-ID: <gS2RQY1pwpR8BoC-CjliHSmmsB4UjYNTgXyFEbnKyqs=.64a2c2bc-cf70-4137-baf1-b044dab087a6@github.com>

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's review comments

David, I've addressed your review comments.

For now I went with changing the return type of `on_entry` to `JavaThread*`, assuming the potential pointer conversion is not an issue. 

I tried for a while to implement a static assert to check that `Thread*` is trivial convertible to `JavaThread*` as well, but couldn't find a way to do that at compile time, so left it for now. It looks like C++ 20 has a type trait to check this: https://en.cppreference.com/w/cpp/types/is_pointer_interconvertible_base_of (I think this does what we want). I thought maybe we could just mimic the reference implementation, but looking at for instance the MSVC STL implementation, this type trait is implemented as a compiler intrinsic, so I think we'll have to wait until we are on C++ 20 before adding such a static assert.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From dholmes at openjdk.java.net  Thu Jul 15 23:00:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 15 Jul 2021 23:00:29 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <hBpL8Lz9hRJ3_Ee8ZhpfyxI3qLSya9yMTRo2fRI6Zdo=.c50761ec-0fb8-45c1-a6f7-99ba2c408512@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <ebTR3Fg3FnrWIJX847RkbgTBN0Ma9rWbdyVR8WR0dhs=.349b6255-e6c7-46d8-b2df-8cd4d4dd13e8@github.com>
 <VW5GuwT6ccFopn__J_mIvIBaso53uR8i81DtuEh2AuM=.a5adb7ea-7a24-41d5-a1d0-cd972792dad6@github.com>
 <hBpL8Lz9hRJ3_Ee8ZhpfyxI3qLSya9yMTRo2fRI6Zdo=.c50761ec-0fb8-45c1-a6f7-99ba2c408512@github.com>
Message-ID: <r8EZ6JV8KgMt8OkTXblKPfHum4Dp4rjohVIDKYety08=.4d8ff226-ee1d-4a68-b296-3f033a316466@github.com>

On Thu, 15 Jul 2021 11:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> How does native code reach a safepoint polling point?
>
> The stack trace looks like this:
> 
> 
> Current thread (0x000002a2489f0b50):  JavaThread "Thread-4551" [_thread_in_Java, id=24920, stack(0x000000d9e0500000,0x000000d9e0600000)]
> 
> Stack: [0x000000d9e0500000,0x000000d9e0600000]
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [jvm.dll+0xae6651]  os::platform_print_native_stack+0xf1  (os_windows_x86.cpp:235)
> V  [jvm.dll+0xda3f25]  VMError::report+0x1005  (vmError.cpp:739)
> V  [jvm.dll+0xda58ae]  VMError::report_and_die+0x7fe  (vmError.cpp:1549)
> V  [jvm.dll+0xda5fe4]  VMError::report_and_die+0x64  (vmError.cpp:1330)
> V  [jvm.dll+0x4ceca7]  report_vm_error+0xb7  (debug.cpp:282)
> V  [jvm.dll+0x6511be]  HandleArea::allocate_handle+0x3e  (handles.cpp:35)
> V  [jvm.dll+0xb8e334]  ThreadSafepointState::handle_polling_page_exception+0x314  (safepoint.cpp:939)
> C  0x000002a035d8caa7
> 
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> v  ~SafepointBlob
> J 639 c1 java.lang.invoke.LambdaForm$MH+0x000000080101b800.invoke(Ljava/lang/Object;)V java.base at 18-internal (87 bytes) @ 0x000002a03635f7b4 [0x000002a03635f4a0+0x0000000000000314]
> J 620 c1 java.lang.invoke.LambdaForm$MH+0x0000000801018c00.invoke(Ljava/lang/Object;)V java.base at 18-internal (37 bytes) @ 0x000002a036353e0c [0x000002a036353720+0x00000000000006ec]
> v  ~BufferBlob::m?Y?????G?
> 
> 
> So I think the 'native code' is something being called by the safepoint blob, but I'm not sure why it's marked with a `C` instead of `V` in the stack trace (maybe just a stack unwind failure?).
> 
> FWIW, this part has already been fixed as part of: https://github.com/openjdk/jdk17/pull/173 (not sure why it still shows up in the diff)

Okay so we're not actually _thread_in_native it is just a chunk of VM generated code. Something still seems off to me about the need for the HandleMark but that isn't your problem.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From kvn at openjdk.java.net  Thu Jul 15 23:47:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 15 Jul 2021 23:47:17 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
 <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>
Message-ID: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com>

On Thu, 15 Jul 2021 12:44:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Thanks.
>> 
>> I've been careful here to return a `Thread*` since the result is stored in `r15_thread` and I thought converting between sub and super types could potentially result in different pointers due to the way super types are laid out within a subtype. I thought it worked like this:
>> 
>> 
>> Subclass
>> +---
>> | {Subclass vtable pointer}
>> | +--- (base class Super)
>> | | {Super vtable pointer}
>> | +---
>> +---
>> 
>> 
>> So, I thought plainly using a `JavaThread*` in generated machine code where a `Thread*` was expected could cause trouble, since the pointer needs to be offset for the type conversion.
>> 
>> But now that I'm looking at some cases with compiler explorer, the pointer offset only seems to be needed when using multiple inheritance, for instance:
>> 
>> 
>> class SuperA {
>> public:
>>     virtual void foo();
>> };
>> 
>> class SuperB {
>> public:
>>     virtual void bar();
>> };
>> 
>> class Sub : public SuperA, public SuperB {
>> public:
>>     virtual void baz();
>> };
>> 
>> 
>> Results in:
>> 
>> 
>> class Sub	size(16):
>> 	+---
>>  0	| +--- (base class SuperA)
>>  0	| | {vfptr}
>> 	| +---
>>  8	| +--- (base class SuperB)
>>  8	| | {vfptr}
>> 	| +---
>> 	+---
>> 
>> Sub::$vftable at SuperA@:
>> 	| &Sub_meta
>> 	|  0
>>  0	| &SuperA::foo 
>>  1	| &Sub::baz 
>> 
>> Sub::$vftable at SuperB@:
>> 	| -8
>>  0	| &SuperB::bar 
>> 
>> Sub::baz this adjustor: 0
>> 
>> 
>> (https://godbolt.org/z/1665fWzff)
>> 
>> It seems that the sub type just reuses the vtable pointer of the first super type (probably to avoid having to do this pointer offsetting). Though, converting between `SuperB*` and `Sub*` would require offsetting the pointer. I'm still not sure this is guaranteed to work like this with all compilers though (the example is with MSVC, which has options to dump class layouts).
>> 
>> The result of `on_entry` is stored in `r15_thread`, so I guess I'm wondering if it's safe to store a `JavaThread*` instead of a `Thread*` in `r15`, and other code, which may expect `r15` to hold a `Thread*`, is guaranteed to keep working? (FWIW, after changing the return type to `JavaThread*` the tests that exercise this code still pass on Windows with MSVC, and on WSL Linux with GCC).
>
> Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff

@JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have **one** vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different.

The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers.

R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread*

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From dholmes at openjdk.java.net  Fri Jul 16 02:10:23 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 02:10:23 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <66vtM23dULcHDhjAYzZipQHy0KQHxwNKleKJIUlFnDo=.fe454def-a1a6-4475-94c2-06e85eea53e9@github.com>
Message-ID: <5BzyK6iLhqUQVIm9F6SH-Y3s5ykFtys605qqLvVbJs0=.62fdab67-7716-4f9a-9a25-19052f55da52@github.com>

On Thu, 15 Jul 2021 10:47:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/share/prims/universalUpcallHandler.cpp line 121:
>> 
>>> 119:   }
>>> 120: 
>>> 121:   MACOS_AARCH64_ONLY(thread->enable_wx(WXExec));
>> 
>> Not clear why this is needed? JavaCallWrapper doesn't use it.
>
> I took this from JavaCallWrapper. Seems to have been added in 17 for the mach aarch64 port: https://github.com/openjdk/jdk17/blame/a32d2eefea12771522b942b32985df0fe50119e8/src/hotspot/share/runtime/javaCalls.cpp#L112

Sorry not sure what I was looking at when I didn't see this.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From dholmes at openjdk.java.net  Fri Jul 16 02:20:16 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 16 Jul 2021 02:20:16 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
Message-ID: <wqxaxlrKcv8j9N9q2ncHtucCsYGRV4aO6hII4fJHPRU=.23d6e58f-dfd8-4336-b427-7d085f742199@github.com>

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's review comments

Thanks for the updates.

Minor comments below.

David

src/hotspot/share/prims/universalUpcallHandler.cpp line 62:

> 60:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);
> 61:     *should_detach = true;
> 62:     thread = Thread::current();

You could use JavaThread::current() here and avoid the later conversions.

src/hotspot/share/prims/universalUpcallHandler.cpp line 138:

> 136:   debug_only(thread->dec_java_call_counter());
> 137: 
> 138:   // Old thread-local info. has been restored. We are not back in native code.

Pre-existing: I think "not" should be "now".

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/149


From eosterlund at openjdk.java.net  Fri Jul 16 08:46:51 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 16 Jul 2021 08:46:51 GMT
Subject: RFR: 8270347: ZGC: Adopt release-acquire ordering for forwarding
 table access
In-Reply-To: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>
References: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>
Message-ID: <tKljc_J760-PUwfjkTxjYG_1r0DN0_BjnNsuATghdRc=.1700c6a6-e440-41e9-b2ec-63575b63cc08@github.com>

On Tue, 13 Jul 2021 06:52:56 GMT, Lu Xiaowei <github.com+39413832+weixlu at openjdk.org> wrote:

> ZGC forwarding table records entries to track the destination of object relocation. Currently, the entry insertion (ZForwarding::insert()) adopts memory_order_conservative to guarantee that (1) the object copy always happens before the installation of forwardee, and (2) the other thread that accesses the same entry (ZForwarding::at() with load_acquire semantic) is able to access the correct contents of the forwarded object.
> 
> Let us consider memory_order_release for the entry insertion in ZForwarding::insert(). Pairing with the entry access in ZForwarding::at(), the forwarding table adopts release-acquire memory ordering. The two statements we mentioned above can also be guaranteed by the release-acquire ordering.
> 
> We performed an experiment on benchmark SPECjvm2008.sunflow on AArch64. The concurrent relocation time is listed below. The optimized version results in shorter average concurrent relocation time. Furthermore, it could benefit the throughput of ZGC.
> 
> $ grep "[50]00.*Phase: Concurrent Relocate" optimized.log
> [500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.006 / 4.449         4.041 / 5.361         4.041 / 5.361         4.041 / 5.361       ms
> [1000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.512 / 5.278         4.213 / 5.278         4.146 / 5.361         4.146 / 5.361       ms
> [1500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.831 / 5.524         4.446 / 5.584         4.253 / 5.584         4.253 / 5.584       ms
> [2000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.037 / 4.649         4.391 / 5.524         4.281 / 5.584         4.281 / 5.584       ms
> [2500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.256 / 4.568         4.198 / 5.022         4.265 / 5.584         4.265 / 5.584       ms
> [3000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.032 / 4.424         3.810 / 24.709        4.173 / 24.709        4.173 / 24.709      ms
> [3500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.740 / 4.598         3.304 / 4.872         4.050 / 24.709        4.050 / 24.709      ms
> 
> $ grep "[50]00.*Phase: Concurrent Relocate" baseline.log
> [500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.634 / 5.191         4.425 / 5.490         4.425 / 5.490         4.425 / 5.490       ms
> [1000.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.177 / 4.731         4.414 / 5.543         4.400 / 5.543         4.400 / 5.543       ms
> [1500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.560 / 4.894         4.441 / 5.543         4.427 / 5.543         4.427 / 5.543       ms
> [2000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.509 / 5.100         4.591 / 5.739         4.468 / 5.739         4.468 / 5.739       ms
> [2500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.543 / 5.533         4.685 / 5.762         4.511 / 5.762         4.511 / 5.762       ms
> [3000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.423 / 4.834         4.635 / 5.895         4.530 / 5.895         4.530 / 5.895       ms
> [3500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.152 / 5.243         4.313 / 24.341        4.493 / 24.341        4.493 / 24.341      ms

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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


From jvernee at openjdk.java.net  Fri Jul 16 11:55:58 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 11:55:58 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v2]
In-Reply-To: <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <o-O6F0omoRjgCjD28Ir79_QYw2xdT_1SlIu2h0eLqH0=.a9e4053d-4464-40de-94df-39fc98e4eaaf@github.com>
 <e7gBayKnokRzWTDb2LQFrP8eikV-UrRN_Y0JGCzY55w=.962eb647-c232-47b5-95c2-4844d8a36204@github.com>
 <fyyuRO2J0ekD3Y5aSd96rGzJDImawCygjqtMXRB1EA0=.0105932c-1d93-4287-8df7-30b1fd6b3090@github.com>
 <iFQizlIjNo63-wowvyQkjsPBmY--Rgy1pWhEN94GuUw=.b0d3f899-b665-427a-ae1c-65bd3b7c7721@github.com>
 <4q2WY6-y3tV9zRqLlR6mWPhwd-nQ-Ai0JCxqA16taXE=.05ff5f90-2ace-470a-b237-30c6b97055f9@github.com>
Message-ID: <EtP70HnhABN0Q6AGxupeyWh0NOzoPawVxO6lDLAVajU=.2f8ba88a-033d-404c-ac82-94835d8aaf2b@github.com>

On Thu, 15 Jul 2021 23:43:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Sorry, I sent the wrong godbolt link: https://godbolt.org/z/1665fWzff
>
> @JornVernee I have small correct to your comment. We use simple inheritance for Thread subclasses. Their instances have **one** vtbl pointer at the same offset as in base class. But this pointer will point to separate vtable for each subclass (and base class). The layout (sequence) of methods pointers in vtable is the same in base class and subclasses. But subclass specific methods pointers will be different.
> 
> The only issue is that you have to make sure to cast passed object pointer to correct subclass (or base class). Otherwise you will get incorrect vtable and incorrect virtual methods pointers.
> 
> R15 is used by our JIT compiled code and Interpreter code which are executed only in JavaThread so the pinter it contains is JavaThread*

Thanks Vladimir. This also matches what I was seeing in compiler explorer, but I wasn't sure if we could assume it always worked like that with every C++ compiler.

It sound like R15 is expected to hold a `JavaThread*` though, so making the return type of `on_entry` be `JavaThread*` as David suggested seems correct.

Thanks

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Fri Jul 16 11:55:57 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 11:55:57 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <wqxaxlrKcv8j9N9q2ncHtucCsYGRV4aO6hII4fJHPRU=.23d6e58f-dfd8-4336-b427-7d085f742199@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
 <wqxaxlrKcv8j9N9q2ncHtucCsYGRV4aO6hII4fJHPRU=.23d6e58f-dfd8-4336-b427-7d085f742199@github.com>
Message-ID: <KTrEVoMDKBIJdbmWMZyraQef5u-VVg0BTwZn-E_gAi8=.bda8a353-92be-400d-84c0-31beb8415cf6@github.com>

On Fri, 16 Jul 2021 02:12:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address David's review comments
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 62:
> 
>> 60:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);
>> 61:     *should_detach = true;
>> 62:     thread = Thread::current();
> 
> You could use JavaThread::current() here and avoid the later conversions.

Ok. The variable is initially initialized (hah) using `Thread::current_or_null()` and there was no equivalent that does that for `JavaThread`. I can add something like that though.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From iwalulya at openjdk.java.net  Fri Jul 16 12:03:55 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 16 Jul 2021 12:03:55 GMT
Subject: RFR: 8270540 G1: Refactor range checking in
 G1BlockOffsetTablePart::block_start* to asserts
In-Reply-To: <iskELjBs3a0a-fK0SoiqoPKti6_Sh9n_80aF9TnFg7w=.131fbdcc-76c2-4def-8513-4a7a343de47b@github.com>
References: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
 <iskELjBs3a0a-fK0SoiqoPKti6_Sh9n_80aF9TnFg7w=.131fbdcc-76c2-4def-8513-4a7a343de47b@github.com>
Message-ID: <DAofECchDVN0zQIzWZf7qhgK0Y78YY8yHRoOzeg-WZI=.c2503726-16e7-4072-8a97-e303698e62fa@github.com>

On Thu, 15 Jul 2021 13:45:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this clean-up to replace range checking with asserts. 
>> 
>> Testing: tier 1-3
>
> Marked as reviewed by ayang (Committer).

Thanks @albertnetymk  and @tschatzl  for your reviews

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

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


From iwalulya at openjdk.java.net  Fri Jul 16 12:03:56 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Fri, 16 Jul 2021 12:03:56 GMT
Subject: Integrated: 8270540 G1: Refactor range checking in
 G1BlockOffsetTablePart::block_start* to asserts
In-Reply-To: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
References: <310ODZxIMZQnuAo3wfoLi_0WmJzM3IKptJjbTA6RJRY=.2f9e2ae5-941b-42bb-9330-7ea68ad644cd@github.com>
Message-ID: <Eq3-rpuHkSFTtL6pQMWCp484j9o08WbTWG5g1C72nOI=.081fafaf-0fff-409d-8d67-fb2bb3181eda@github.com>

On Thu, 15 Jul 2021 13:45:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this clean-up to replace range checking with asserts. 
> 
> Testing: tier 1-3

This pull request has now been integrated.

Changeset: 1d8d72d2
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1d8d72d2c24764ab32741dd5220a6c1a980656e2
Stats:     13 lines in 1 file changed: 0 ins; 6 del; 7 mod

8270540: G1: Refactor range checking in G1BlockOffsetTablePart::block_start* to asserts

Reviewed-by: ayang, tschatzl

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

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


From jvernee at openjdk.java.net  Fri Jul 16 14:38:35 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 14:38:35 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v4]
In-Reply-To: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
Message-ID: <sZ-6K79A6wl2BweSBsqsFjfoYQmNNRJf2fzV63rOpmE=.95db31cd-ae7c-40d4-a199-90ea2dc61eaf@github.com>

> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
> 
> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
> 
> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
> 
> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
> 
> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Address more review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/149/files
  - new: https://git.openjdk.java.net/jdk17/pull/149/files/128f48db..60bc5564

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

  Stats: 17 lines in 3 files changed: 7 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/149/head:pull/149

PR: https://git.openjdk.java.net/jdk17/pull/149


From jvernee at openjdk.java.net  Fri Jul 16 14:38:37 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 16 Jul 2021 14:38:37 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v3]
In-Reply-To: <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <cavIUnm5LQtMXdPpG2WUo3pYBB2rs7MVe-l_T5tHnWo=.2215f2d8-f8ef-4f59-b0a0-61aed83af110@github.com>
Message-ID: <lNrc6ixlZvbTZR30xVAURpwAzV-ewfjOlFKy69ps2cQ=.51965554-d3db-42be-bba1-72cd256ca616@github.com>

On Thu, 15 Jul 2021 15:54:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address David's review comments

I've addressed the new review comments, changing some `Thread*` to `JavaThread*`, removing now redundant casts, and finally noticed that the `Thread*` being passed to `ProgrammableUpcallHandle::detach_thread` was not being used, and it was always detaching the current thread instead. This in itself is fine, but then there's no need for the parameter, so I've dropped that.

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

PR: https://git.openjdk.java.net/jdk17/pull/149


From dholmes at openjdk.java.net  Sat Jul 17 00:37:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 17 Jul 2021 00:37:59 GMT
Subject: [jdk17] RFR: 8269240:
 java/foreign/stackwalk/TestAsyncStackWalk.java test failed with concurrent GC
 [v4]
In-Reply-To: <sZ-6K79A6wl2BweSBsqsFjfoYQmNNRJf2fzV63rOpmE=.95db31cd-ae7c-40d4-a199-90ea2dc61eaf@github.com>
References: <PqFCdTWCSge_X14Rc5aNAo2pr5uliZ9jT0iYltvef3g=.7467c1a4-ad15-48a3-a495-75b655acf69c@github.com>
 <sZ-6K79A6wl2BweSBsqsFjfoYQmNNRJf2fzV63rOpmE=.95db31cd-ae7c-40d4-a199-90ea2dc61eaf@github.com>
Message-ID: <u4O0lg5nYU9K0BfwcintajLEBtCZvujBSXvtCNNd4io=.197fa775-1174-4921-a8cb-d64f66f71bea@github.com>

On Fri, 16 Jul 2021 14:38:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch rewrites the prologue and epilogue of panama upcalls, in order to fix the test failure from the title.
>> 
>> Previously, we did a call to potentially attach the current thread to the VM, and then afterwards did the same suspend and stack reguard checks that we do on the back-edge of a native downcall. Then, on the back edge of the upcall we did another conditional call to detach the thread.
>> 
>> The suspend and reguard checks on the front-edge are incorrect, so I've changed the 2 calls to mimic what is done by JavaCallWrapper instead (with attach and detach included), and removed the old suspend and stack reguard checks.
>> 
>> FWIW, this removes the JavaFrameAnchor save/restore MacroAssembler code. This is now written in C++. Also, MacroAssembler code was added to save/restore the result of the upcall around the call on the back-edge, which was previously missing. Since the new code allocates a handle block as well, I've added handling for those oops to frame & OptimizedUpcallBlob.
>> 
>> Testing: local running of `jdk_foreign` on Windows and Linux (WSL). Tier 1-3
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address more review comments

Updates look good.

Thanks,
David

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

> 1425:   static inline JavaThread* current();
> 1426:   // Returns the current thread as a JavaThread, or NULL if not attached
> 1427:   static inline JavaThread* current_or_null();

I hadn't intended to suggest the introduction of this method, but I see now how my comment led to it. It is fine.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/149


From kbarrett at openjdk.java.net  Sun Jul 18 14:22:06 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 18 Jul 2021 14:22:06 GMT
Subject: RFR: 8270455: Remove unused JFR tracer related code in
 G1CollectedHeap
In-Reply-To: <O0m_Z2eXcuuZVnsWbUVCs9HvoTDDjR8Z6SjBlqobWis=.334447a3-14e1-4137-8162-e0ac550a8f10@github.com>
References: <O0m_Z2eXcuuZVnsWbUVCs9HvoTDDjR8Z6SjBlqobWis=.334447a3-14e1-4137-8162-e0ac550a8f10@github.com>
Message-ID: <mxW9ovjEF1ryDwtA1Ajv-E8IaSw8qO6b6pxlW629By4=.7c1351ce-4a2b-4e9f-b675-0670fe026598@github.com>

On Wed, 14 Jul 2021 11:25:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   please review this unused code deletion.
> 
> Testing: local build.
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Sun Jul 18 14:41:00 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 18 Jul 2021 14:41:00 GMT
Subject: RFR: 8270187: G1: Remove ConcGCThreads constraint
In-Reply-To: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>
References: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>
Message-ID: <4PRr92sANKjdCu_rFovUZAA2AlEquF3wpFhO3s7DbM4=.3e268a02-6aac-490f-96ed-b6fd25bd65da@github.com>

On Mon, 12 Jul 2021 15:09:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing `ConcGCThreads <= ParallelGCThreads` constraint for G1.
> 
> Tested: hotspot_gc with `-XX:ConcGCThreads=3 -XX:ParallelGCThreads=2`

This looks good. I can't think of anywhere else that needed adjusting; ReferenceProcessor already deals with this. But I'd like additional testing to be done before this change is committed, to avoid any surprises.

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Sun Jul 18 15:08:12 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 18 Jul 2021 15:08:12 GMT
Subject: RFR: 8270869: G1ServiceThread may not terminate
Message-ID: <kavoBiFcRV3pB2IDUGMxf1CftSOX9G4wXhZK6JXaCvs=.dbeccc6e-1725-4bb4-8df9-97ef56f8101d@github.com>

Please review this fix of a rare race in G1ServiceThread termination that
can lead to the thread not terminating in a timely manner.

Testing:
mach5 tier1

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

Commit messages:
 - fix race

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

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


From ayang at openjdk.java.net  Sun Jul 18 16:52:55 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Sun, 18 Jul 2021 16:52:55 GMT
Subject: RFR: 8270869: G1ServiceThread may not terminate
In-Reply-To: <kavoBiFcRV3pB2IDUGMxf1CftSOX9G4wXhZK6JXaCvs=.dbeccc6e-1725-4bb4-8df9-97ef56f8101d@github.com>
References: <kavoBiFcRV3pB2IDUGMxf1CftSOX9G4wXhZK6JXaCvs=.dbeccc6e-1725-4bb4-8df9-97ef56f8101d@github.com>
Message-ID: <uXvTz5WPrAZ72ESBz0jEYG94sdZP--wEbW1LysCJrY4=.3279a800-956a-40c6-858f-439523f8b142@github.com>

On Sun, 18 Jul 2021 15:00:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of a rare race in G1ServiceThread termination that
> can lead to the thread not terminating in a timely manner.
> 
> Testing:
> mach5 tier1

Only a minor comment on the style; I think not using `else-if` is clearer: the early-return handles the exiting condition, and the other two cases depend on the task queue state.

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

Marked as reviewed by ayang (Committer).

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


From github.com+7947546+tanghaoth90 at openjdk.java.net  Mon Jul 19 02:55:59 2021
From: github.com+7947546+tanghaoth90 at openjdk.java.net (Hao Tang)
Date: Mon, 19 Jul 2021 02:55:59 GMT
Subject: RFR: 8270347: ZGC: Adopt release-acquire ordering for forwarding
 table access
In-Reply-To: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>
References: <XijE-mf_TFN3J4dFKE1qTP85Rb59ZANck9wMqnQdSy8=.3df261c2-8090-498b-b1e4-3dd276d53c33@github.com>
Message-ID: <tKkr7Udbk8Gzb4pfEGooSI_9ZYydWlQ8DzQTi2aWRQY=.1bb364cc-8dab-41dd-913a-cafa0acc5ced@github.com>

On Tue, 13 Jul 2021 06:52:56 GMT, Lu Xiaowei <github.com+39413832+weixlu at openjdk.org> wrote:

> ZGC forwarding table records entries to track the destination of object relocation. Currently, the entry insertion (ZForwarding::insert()) adopts memory_order_conservative to guarantee that (1) the object copy always happens before the installation of forwardee, and (2) the other thread that accesses the same entry (ZForwarding::at() with load_acquire semantic) is able to access the correct contents of the forwarded object.
> 
> Let us consider memory_order_release for the entry insertion in ZForwarding::insert(). Pairing with the entry access in ZForwarding::at(), the forwarding table adopts release-acquire memory ordering. The two statements we mentioned above can also be guaranteed by the release-acquire ordering.
> 
> We performed an experiment on benchmark SPECjvm2008.sunflow on AArch64. The concurrent relocation time is listed below. The optimized version results in shorter average concurrent relocation time. Furthermore, it could benefit the throughput of ZGC.
> 
> $ grep "[50]00.*Phase: Concurrent Relocate" optimized.log
> [500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.006 / 4.449         4.041 / 5.361         4.041 / 5.361         4.041 / 5.361       ms
> [1000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.512 / 5.278         4.213 / 5.278         4.146 / 5.361         4.146 / 5.361       ms
> [1500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.831 / 5.524         4.446 / 5.584         4.253 / 5.584         4.253 / 5.584       ms
> [2000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.037 / 4.649         4.391 / 5.524         4.281 / 5.584         4.281 / 5.584       ms
> [2500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.256 / 4.568         4.198 / 5.022         4.265 / 5.584         4.265 / 5.584       ms
> [3000.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.032 / 4.424         3.810 / 24.709        4.173 / 24.709        4.173 / 24.709      ms
> [3500.506s][info][gc,stats    ]       Phase: Concurrent Relocate                           3.740 / 4.598         3.304 / 4.872         4.050 / 24.709        4.050 / 24.709      ms
> 
> $ grep "[50]00.*Phase: Concurrent Relocate" baseline.log
> [500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.634 / 5.191         4.425 / 5.490         4.425 / 5.490         4.425 / 5.490       ms
> [1000.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.177 / 4.731         4.414 / 5.543         4.400 / 5.543         4.400 / 5.543       ms
> [1500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.560 / 4.894         4.441 / 5.543         4.427 / 5.543         4.427 / 5.543       ms
> [2000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.509 / 5.100         4.591 / 5.739         4.468 / 5.739         4.468 / 5.739       ms
> [2500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.543 / 5.533         4.685 / 5.762         4.511 / 5.762         4.511 / 5.762       ms
> [3000.546s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.423 / 4.834         4.635 / 5.895         4.530 / 5.895         4.530 / 5.895       ms
> [3500.545s][info][gc,stats    ]       Phase: Concurrent Relocate                           4.152 / 5.243         4.313 / 24.341        4.493 / 24.341        4.493 / 24.341      ms

Hi, it seems that a non-trivial patch requires at least two reviewers. @pliden would you please review this patch?

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

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


From tschatzl at openjdk.java.net  Mon Jul 19 07:26:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 19 Jul 2021 07:26:57 GMT
Subject: RFR: 8269032: Stringdedup tests are failing if the ergonomically
 select GC does not support it [v2]
In-Reply-To: <dUXcz3fFAv6t8nW2qtNOOEXn4ZcuVBBLUxd7xL1ToOM=.f336efa3-02e2-47a3-a0a5-da81b0f4d80c@github.com>
References: <gob-32HZdZzd85x_uuzyveMWhQiAXgpQ1sOSGX6Zptc=.fdb3478b-1089-4c14-8c64-6c7fa3060f40@github.com>
 <dUXcz3fFAv6t8nW2qtNOOEXn4ZcuVBBLUxd7xL1ToOM=.f336efa3-02e2-47a3-a0a5-da81b0f4d80c@github.com>
Message-ID: <16QGqZt-zZA5ZxolJ79urj0JY9zqEPqJYVTX9VFQ0V0=.7f44b822-8070-4a20-bf31-a12ce76386d2@github.com>

On Thu, 15 Jul 2021 06:58:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the string deduplication tests' handling of an
>> ergonomically chosen GC.  They were assuming G1 would be chosen in that
>> case, but that's wrong of course.  The test machine might not be a server
>> class machine, or G1 might not be included in the build.
>> 
>> Each test now has a second test declaration comment for handling the case
>> where no GC is specified by the jtreg invocation.  This second declaration
>> will force the use of G1 by the test if G1 is supported by the VM.
>> 
>> I looked into trying to be more clever and selecting a different GC if G1 is
>> not supported by the VM, but that ended up making the tests a lot more
>> messy, and doesn't seem like that important a use-case at this time.  A
>> better long-term solution would be to make all the GCs (except Epsilon)
>> support string deduplication, so we don't care which GC gets ergonomically
>> chosen.  But that's not happening today.
>> 
>> Testing:
>> Ran the string deduplication tests with various configurations: (1)
>> explicitly use G1 (2) no explicit GC, (3) no explicit GC with
>> -XX:+NeverActAsServerClassMachine.
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate test class per gc

Still good.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Mon Jul 19 08:54:53 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 19 Jul 2021 08:54:53 GMT
Subject: RFR: 8270455: Remove unused JFR tracer related code in
 G1CollectedHeap
In-Reply-To: <mum5Dj3kNzGu_0ELaAMAToLNo1sqGc6gY4scmmA7GHI=.87fc6fe4-22d0-4ee1-b095-eaedb8854a07@github.com>
References: <O0m_Z2eXcuuZVnsWbUVCs9HvoTDDjR8Z6SjBlqobWis=.334447a3-14e1-4137-8162-e0ac550a8f10@github.com>
 <mum5Dj3kNzGu_0ELaAMAToLNo1sqGc6gY4scmmA7GHI=.87fc6fe4-22d0-4ee1-b095-eaedb8854a07@github.com>
Message-ID: <LXm7p4DE5XKYCwDYG0lV_GpusfDM6hSfGGHSKhLZ9UY=.a1ac9bb1-3a3f-4453-80be-611b26409242@github.com>

On Wed, 14 Jul 2021 11:43:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi,
>> 
>>   please review this unused code deletion.
>> 
>> Testing: local build.
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Committer).

Thanks @albertnetymk @kimbarrett for your reviews.

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

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


From tschatzl at openjdk.java.net  Mon Jul 19 08:57:46 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 19 Jul 2021 08:57:46 GMT
Subject: RFR: 8270869: G1ServiceThread may not terminate
In-Reply-To: <kavoBiFcRV3pB2IDUGMxf1CftSOX9G4wXhZK6JXaCvs=.dbeccc6e-1725-4bb4-8df9-97ef56f8101d@github.com>
References: <kavoBiFcRV3pB2IDUGMxf1CftSOX9G4wXhZK6JXaCvs=.dbeccc6e-1725-4bb4-8df9-97ef56f8101d@github.com>
Message-ID: <xZG0M87-y4alIzVkf2glE6cgZUUtH-UKgCGI6Kn-rMI=.537b0841-c043-4b1f-af8c-56b3c9df1357@github.com>

On Sun, 18 Jul 2021 15:00:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this fix of a rare race in G1ServiceThread termination that
> can lead to the thread not terminating in a timely manner.
> 
> Testing:
> mach5 tier1

Looks good, same comment about the use of the `else if`, but I'm good either way.

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

Marked as reviewed by tschatzl (Reviewer).

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


From rbruno at gsd.inesc-id.pt  Tue Jul 20 13:34:16 2021
From: rbruno at gsd.inesc-id.pt (Rodrigo Bruno)
Date: Tue, 20 Jul 2021 14:34:16 +0100
Subject: hotspot-gc-dev Digest, Vol 168, Issue 38
In-Reply-To: <mailman.41.1624276762.20809.hotspot-gc-dev@openjdk.java.net>
References: <mailman.41.1624276762.20809.hotspot-gc-dev@openjdk.java.net>
Message-ID: <CADy33kBHZHfTt5a40YAY8s=FsSeryp=rS0Zy5D_MeoDWc0RLCw@mail.gmail.com>

Dear Jonathan, Thomas, and Man,

(regarding Status of JEP-8204088/JDK-8236073)

Ruslan and I have been following this thread and agree with the points
raised by Jonathan and Man. From our perspective, JVM heaps need to be
elastic to adapt to the available memory. Containers and VMs can already
increase/decrease the available memory on the fly but JVM heaps can't adapt
to it.

We believe that having a manageable flag to regulate the maximum memory
(such as CurrentMaxHeapSize) is the way to go. The SoftMaxHeapSize helps
but may fail to prevent OOMs that might happen if the GC expands the heap
too aggressively past the soft limit. Having external components such as a
Java agent to manage the memory limit does not solve the issue as the
memory can still grow beyond SoftMaxHeapSize.

Just for completeness, a prototype of CurrentMaxHeapSize is available here
http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/. The idea was that users
can set -Xmx to a very high value (maximum memory available locally) and
then control the current limit via a manageable JVM flag
(CurrentMaxHeapSize) that would enforce the memory utilization. This new
(hard) limit would not have an impact on existing GC heap sizing heuristics
IMHO.

Jonathan and Man, would the CurrentMaxHeapSize be helpful? Thomas, do you
think the proposed patch is feasible in terms of its design and
implementation? We are open to suggestions/feedback about the patch and on
how to make merging it possible.

Best,
rodrigo

<hotspot-gc-dev-request at openjdk.java.net> escreveu no dia segunda,
21/06/2021 ?(s) 13:00:

> Send hotspot-gc-dev mailing list submissions to
>         hotspot-gc-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-dev
> or, via email, send a message with subject or body 'help' to
>         hotspot-gc-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         hotspot-gc-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-gc-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: RFR: 8268458: Add verification type for evacuation
>       failures (Thomas Schatzl)
>    2. Integrated: 8268952: Automatically update heap sizes in
>       G1MonitoringScope (Thomas Schatzl)
>    3. Re: RFR: 8269077: TestSystemGC uses "require vm.gc.G1" for
>       large pages subtest (Thomas Schatzl)
>    4. Integrated: 8268458: Add verification type for evacuation
>       failures (Thomas Schatzl)
>    5. Re: RFR: 8268952: Automatically update heap sizes in
>       G1MonitoringScope (Thomas Schatzl)
>    6. Re: Status of JEP-8204088/JDK-8236073 (Thomas Schatzl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 21 Jun 2021 11:12:28 GMT
> From: Thomas Schatzl <tschatzl at openjdk.java.net>
> To: <hotspot-gc-dev at openjdk.java.net>
> Subject: Re: RFR: 8268458: Add verification type for evacuation
>         failures
> Message-ID:
>         <PjXEe8uwc9uV0Kf2Nk_Pc5Ts81e5jFdCrDx9G6RzdY0=.
> 78e83bfe-0814-487d-a599-3494f8d54a61 at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Sat, 19 Jun 2021 05:59:10 GMT, Kim Barrett <kbarrett at openjdk.org>
> wrote:
>
> >> Hi all,
> >>
> >>   can I have reviews for this change that adds a new verification type
> (argument for `-XX:VerifyGCType` for G1) that only enables verification
> after an evacuation failure?
> >>
> >> The reasons is that time and time again we have issues with evacuation
> failure as it's by far not tested as much as regular collection, and
> reproducing issues then is often hampered by that there is no way to just
> verify after verification failure. Enabling it just for all young
> collections is possible, but typically does not help much.
> >>
> >> Fwiw, this change requires a small semantics change in how the current
> `VerifyGCType` is compared to the one stored as active (i.e. in
> `G1HeapVerifier::_enabled_verification_types`). Since the situations that
> can be enabled are not distinct any more (any young gc can have an
> evacuation failure), the existing check for a given set bit in
> `G1HeapVerifier::should_verify()` does not work any more.
> >>
> >> This also means that the previous assumption that
> `G1VerifyType::G1VerifyAll` is not the same as all flags enabled can not be
> checked any more. I do not think this is any loss in functionality (see the
> gtests for removed checks).
> >>
> >> The same functionality could also have been implemented by injecting
> all of the young gen type bits into the existing `type` on evacuation
> failure at the cost of remembering that the user selected evacuation
> failures for evacuation somewhere else. Not sure if that would be simpler.
> >>
> >> Testing: tier1-2 (still running), updated test
> >>
> >> Thanks,
> >>   Thomas
> >
> > Looks good.
> >
> > G1VerifyType seems poorly named.  The name suggests a single value, but
> it's really a selection bitmask.  Perhaps a followup RFE?
>
> Thanks @kimbarrett @walulyai for your reviews.
>
> Integrate
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4473
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Jun 2021 11:14:31 GMT
> From: Thomas Schatzl <tschatzl at openjdk.java.net>
> To: <hotspot-gc-dev at openjdk.java.net>
> Subject: Integrated: 8268952: Automatically update heap sizes in
>         G1MonitoringScope
> Message-ID:
>         <fSA_-ASTWNVcGC7cu3p6Y1v5yi4W09h0Sqk1KbpuDVY=.
> ec5157ea-f99d-4b08-b177-1df95d782cab at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, 18 Jun 2021 12:06:33 GMT, Thomas Schatzl <tschatzl at openjdk.org>
> wrote:
>
> > Hi,
> >
> >   can I have reviews to factor out the call to
> `G1MonitoringScope::update_sizes()` into the destructor of that class?
> Currently all users seem to call this manually close to the end of the
> scope `G1MonitoringScope` is in.
> >
> > Testing: tier1-5
> >
> > Thanks,
> >   Thomas
>
> This pull request has now been integrated.
>
> Changeset: a58c477c
> Author:    Thomas Schatzl <tschatzl at openjdk.org>
> URL:
> https://git.openjdk.java.net/jdk/commit/a58c477c49ca595c65f7a2fca2512ff2adea99be
> Stats:     18 lines in 4 files changed: 7 ins; 11 del; 0 mod
>
> 8268952: Automatically update heap sizes in G1MonitoringScope
>
> Reviewed-by: kbarrett, iwalulya
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4529
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 21 Jun 2021 11:15:31 GMT
> From: Thomas Schatzl <tschatzl at openjdk.java.net>
> To: <hotspot-gc-dev at openjdk.java.net>
> Subject: Re: RFR: 8269077: TestSystemGC uses "require vm.gc.G1" for
>         large pages subtest
> Message-ID:
>         <w7vkMF1CB4GNdzU2UxYsihH1UJkqQ9otEwslM0V4BAk=.
> b08378d1-d9ab-457e-9929-1116ad970de4 at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Mon, 21 Jun 2021 10:17:38 GMT, Stefan Karlsson <stefank at openjdk.org>
> wrote:
>
> > The invocation that runs with large pages are guarded with `@require
> vm.gc.G1` and doesn't explicitly state that G1 should be used.
> >
> > This means two things:
> > 1) We are not running the large pages subtest when other GCs are
> specified
> > 2) Under some circumstances another GC is ergonomically selected and we
> run the test with that GC even though the test was guarded by `@require
> vm.gc.G1`.
> >
> > I propose that we move the subtest to its own run section, without any
> requirement about the used GC.
>
> Lgtm.
>
> -------------
>
> Marked as reviewed by tschatzl (Reviewer).
>
> PR: https://git.openjdk.java.net/jdk/pull/4538
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 21 Jun 2021 11:15:37 GMT
> From: Thomas Schatzl <tschatzl at openjdk.java.net>
> To: <hotspot-gc-dev at openjdk.java.net>
> Subject: Integrated: 8268458: Add verification type for evacuation
>         failures
> Message-ID:
>         <irqmUxOC0igK_mbCrrDOUK4xhryOVNEng7fu-STo554=.
> b3f3bb60-c523-491e-abcb-0bf27b88e60a at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, 11 Jun 2021 12:23:30 GMT, Thomas Schatzl <tschatzl at openjdk.org>
> wrote:
>
> > Hi all,
> >
> >   can I have reviews for this change that adds a new verification type
> (argument for `-XX:VerifyGCType` for G1) that only enables verification
> after an evacuation failure?
> >
> > The reasons is that time and time again we have issues with evacuation
> failure as it's by far not tested as much as regular collection, and
> reproducing issues then is often hampered by that there is no way to just
> verify after verification failure. Enabling it just for all young
> collections is possible, but typically does not help much.
> >
> > Fwiw, this change requires a small semantics change in how the current
> `VerifyGCType` is compared to the one stored as active (i.e. in
> `G1HeapVerifier::_enabled_verification_types`). Since the situations that
> can be enabled are not distinct any more (any young gc can have an
> evacuation failure), the existing check for a given set bit in
> `G1HeapVerifier::should_verify()` does not work any more.
> >
> > This also means that the previous assumption that
> `G1VerifyType::G1VerifyAll` is not the same as all flags enabled can not be
> checked any more. I do not think this is any loss in functionality (see the
> gtests for removed checks).
> >
> > The same functionality could also have been implemented by injecting all
> of the young gen type bits into the existing `type` on evacuation failure
> at the cost of remembering that the user selected evacuation failures for
> evacuation somewhere else. Not sure if that would be simpler.
> >
> > Testing: tier1-2 (still running), updated test
> >
> > Thanks,
> >   Thomas
>
> This pull request has now been integrated.
>
> Changeset: cd20c019
> Author:    Thomas Schatzl <tschatzl at openjdk.org>
> URL:
> https://git.openjdk.java.net/jdk/commit/cd20c01942dd8559a31e51ef2a595c6eba44b8ad
> Stats:     58 lines in 6 files changed: 46 ins; 5 del; 7 mod
>
> 8268458: Add verification type for evacuation failures
>
> Reviewed-by: kbarrett, iwalulya
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4473
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 21 Jun 2021 11:14:30 GMT
> From: Thomas Schatzl <tschatzl at openjdk.java.net>
> To: <hotspot-gc-dev at openjdk.java.net>
> Subject: Re: RFR: 8268952: Automatically update heap sizes in
>         G1MonitoringScope
> Message-ID:
>         <76o4isNx_5_nPB1qE7HLq5Dr3RDqV8llyYosEGADRNU=.
> 19e05f27-e7dd-4c39-ac52-2aca954d72e3 at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Sat, 19 Jun 2021 05:48:38 GMT, Kim Barrett <kbarrett at openjdk.org>
> wrote:
>
> >> Hi,
> >>
> >>   can I have reviews to factor out the call to
> `G1MonitoringScope::update_sizes()` into the destructor of that class?
> Currently all users seem to call this manually close to the end of the
> scope `G1MonitoringScope` is in.
> >>
> >> Testing: tier1-5
> >>
> >> Thanks,
> >>   Thomas
> >
> > Looks good.
>
> Thanks @kimbarrett @walulyai for your reviews.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/4529
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 21 Jun 2021 13:40:23 +0200
> From: Thomas Schatzl <thomas.schatzl at oracle.com>
> To: Man Cao <manc at google.com>
> Cc: Jonathan Joo <jonathanjoo at google.com>, hotspot-gc-dev
>         <hotspot-gc-dev at openjdk.java.net>, Java Platform Team
>         <java-platform-team at google.com>
> Subject: Re: Status of JEP-8204088/JDK-8236073
> Message-ID: <35ff0404-9cb0-f9bf-0d37-2c3d7b4a0f67 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
>
> On 15.06.21 21:45, Man Cao wrote:
> > Hi all,
> >
> > Thank you for the feedback!
> >
> [...]>
> > The problem we are trying to solve for the "Container RAM limit is
> > fixed" case,
> > is actually orthogonal to the relationship between the two flags.
> > Basically, we need a flag that can be adjusted dynamically (i.e.
> > "manageable" in HotSpot).
>
> I think something like GCTimeRatio could be made manageable and it would
> be useful to do so. That came up internally in some discussions already
> a fair amount of time ago afair, but with the current heap sizing broken
> it's just one more (small) todo...
>
> > Then we can make either a JVM feature, or a non-JVM approach such as via
> > an agent,
> > to automatically set either?GCTimeRatio/GCCpuPercentage
> > or?SoftMaxHeapSize/CurrentMaxHeapSize
> > based on the container RAM usage/limit ratio.
> >
> > Assuming using the GCCpuPercentage and CurrentMaxHeapSize flag names,
> > suppose we have a
> > JVM feature -XX:+StriveToStayWithinContainerRAMLimit, its behavior could
> be:
> > - If container RAM usage/limit ratio is below 90%, nothing needs to be
> > done and just use
> >  ? the default values for?GCCpuPercentage and?CurrentMaxHeapSize.
> > - If container RAM usage/limit ratio is 90%-95%, it could start trying
> > to reduce the heap size,
> >  ? either by increasing?GCCpuPercentage, or shrinking?CurrentMaxHeapSize.
> > - If container?RAM usage/limit ratio is above 95%, it could try even
> > harder by further increasing
> >  ? GCCpuPercentage or shrinking?CurrentMaxHeapSize.
> > In the above cases, there will be a limit on how
> > far?-XX:+StriveToStayWithinContainerRAMLimit
> > could increase?GCCpuPercentage or shrink?CurrentMaxHeapSize.
> > We don't want to cause GC thrashing, as it is better to be killed by the
> > container manager and
> > restart the program, than to be stuck in GC thrashing. We could rely on
> > UseGCOverheadLimit
> > (JDK-8212084) for this purpose as well.
> >
> > I'm not sure if we could make GCCpuPercentage manageable, but
> > CurrentMaxHeapSize will definitely be manageable. If
> > GCCpuPercentage is manageable, then
> -XX:+StriveToStayWithinContainerRAMLimit
> > could be built solely by changing GCCpuPercentage, without relying on
> > setting?CurrentMaxHeapSize.
>
> My general opinion about these kind of fairly complex heuristics not
> directly related how the VM should operate "right now" is to try to keep
> them outside the VM :) This heuristic in particular would need to know
> the container RAM limit (ok, that one the VM knows already) and in
> particular its own total RAM usage which is not the case today.
>
> Both variables seem to be something that is very easily (and probably
> better) determined by some outside entity and any response to that could
> be more flexibly managed there at first glance; similar external agents
> tend to be running anyway already somewhere for container/VM management
> too.
>
> Another reason to not immediately jump on it is that while I can see
> your point, first I would prefer to have the current issues fixed :)
>
> >
> > For getting CPU usage
> >  > The problem is that apart from internal prototypes we never got around
> >  > to add that. There's JDK-8027759 (and one more I think) though, even
> >  > with a very very old patch.
> >  >
> >  > Another issue related to getting cpu usage I remember is support on
> some
> >  > systems, and it may be spotty on others (i.e. granularity wise).
> >  >
> >  > Do you have any experience on that outside of Linux?
> >
> > Great point. I haven't thought of this problem yet.
> > https://github.com/caoman/jdk/tree/G1ThreadsCPUTime
> > contains a patch on how
> > we get the CPU times.
> > I see os::is_thread_cpu_time_supported() could return false on Windows
> > and BSD.
> > We will dig further to see how this could be implemented for these OSes.
>
> Having looked a bit about that, OSX should be fairly easy (thread_info()
> call), but probably unsupportable on Windows: its getThreadTimes() seems
> to be unusable and the only way there.
>
> Thomas
>
>
> End of hotspot-gc-dev Digest, Vol 168, Issue 38
> ***********************************************
>


-- 
rodrigo-bruno.github.io


From kbarrett at openjdk.java.net  Thu Jul 22 04:11:45 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 22 Jul 2021 04:11:45 GMT
Subject: RFR: 8270336: [TESTBUG] Fix initialization in NonbranchyTree
In-Reply-To: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
References: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
Message-ID: <FRcJgsBusZ3QWt3qNDlxvvlBW6NgpkYDJJXxbDT4o50=.92e8bf3b-253a-4af7-84c7-ddd5c0c55ec3@github.com>

On Tue, 13 Jul 2021 02:02:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.gc.NonbranchyTree might call initTree() twice and incorrectly reports branchiness in the case of IllegalArgumentException(...).

One trivial grammar fix for a pre-existing problem in an error message.  Otherwise looks good.

test/hotspot/jtreg/vmTestbase/nsk/share/gc/NonbranchyTree.java line 71:

> 69:         if ((branchiness >= 1) || (branchiness <= 0)) {
> 70:             throw new IllegalArgumentException("Illegal value of branchiness: "
> 71:                     + branchiness + ", must be at greater than 0 and less than 1.");

s/be at/b/

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

Marked as reviewed by kbarrett (Reviewer).

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


From kbarrett at openjdk.java.net  Thu Jul 22 04:22:46 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 22 Jul 2021 04:22:46 GMT
Subject: RFR: 8270961: [TESTBUG] Move GotWrongOOMEException into
 vm.share.gc package
In-Reply-To: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
References: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
Message-ID: <QCzFwZCNnJqAXK-wYhU6RaN6RvyFO-KJekvsKM0C_YI=.96bb6054-1cea-48cd-ae3e-5a2b737ea38d@github.com>

On Tue, 20 Jul 2021 19:26:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The small refactoring which consolidates shared code in the shared library. Make project more IDE-friendly.

Some minor commenting issues, but otherwise looks good.

test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/StressHierarchyBaseClass.java line 117:

> 115:              * We pass test in this case as this breaks test logic. We have dedicated test configurations
> 116:              * for OOME:heap provoking class unloading, that why we are not missing test coverage here.
> 117:              */

This comment is unnecessary, as it adds nothing over the log message that follows.

test/hotspot/jtreg/vmTestbase/vm/share/gc/HeapOOMEException.java line 26:

> 24: 
> 25: /**
> 26:  * This class is used to differ OOME in metaspace and heap when trigger class unloading.

That doesn't scan so well.  Perhaps something like
"This class is used to distinguish between OOME in metaspace and OOME in heap when triggering class unloading."

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

Marked as reviewed by kbarrett (Reviewer).

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


From lmesnik at openjdk.java.net  Thu Jul 22 04:36:17 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 04:36:17 GMT
Subject: RFR: 8270336: [TESTBUG] Fix initialization in NonbranchyTree [v2]
In-Reply-To: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
References: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
Message-ID: <kqtSnFlnHzk10IwzaV_1XAqTq2M2NGhiemb5Uk_sByo=.88d67f1c-3c50-410c-9b4b-540a1792b28b@github.com>

> The nsk.share.gc.NonbranchyTree might call initTree() twice and incorrectly reports branchiness in the case of IllegalArgumentException(...).

Leonid Mesnik 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:

 - fixed typo
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8270336
 - 8270336: [TESTBUG] Fix initialization in NonbranchyTree

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4761/files
  - new: https://git.openjdk.java.net/jdk/pull/4761/files/4782c3f1..ea166692

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

  Stats: 5276 lines in 207 files changed: 3289 ins; 1015 del; 972 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4761.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4761/head:pull/4761

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


From lmesnik at openjdk.java.net  Thu Jul 22 04:41:20 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 04:41:20 GMT
Subject: RFR: 8270961: [TESTBUG] Move GotWrongOOMEException into
 vm.share.gc package [v2]
In-Reply-To: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
References: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
Message-ID: <fUtwVzGJnNE0QCtL0XoyxODEKR5fDaoaNSj90PuHoIs=.a3a45f79-68c0-41f9-b619-a9c2b3c04a19@github.com>

> The small refactoring which consolidates shared code in the shared library. Make project more IDE-friendly.

Leonid Mesnik 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:

 - fixed after Kim's comments.
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8270961
 - fixed log string.
 - import fix.
 - 8270961

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4844/files
  - new: https://git.openjdk.java.net/jdk/pull/4844/files/990bff2f..70e726f3

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

  Stats: 1509 lines in 67 files changed: 998 ins; 186 del; 325 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4844.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4844/head:pull/4844

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


From lmesnik at openjdk.java.net  Thu Jul 22 04:41:25 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 04:41:25 GMT
Subject: RFR: 8270961: [TESTBUG] Move GotWrongOOMEException into
 vm.share.gc package [v2]
In-Reply-To: <QCzFwZCNnJqAXK-wYhU6RaN6RvyFO-KJekvsKM0C_YI=.96bb6054-1cea-48cd-ae3e-5a2b737ea38d@github.com>
References: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
 <QCzFwZCNnJqAXK-wYhU6RaN6RvyFO-KJekvsKM0C_YI=.96bb6054-1cea-48cd-ae3e-5a2b737ea38d@github.com>
Message-ID: <V4GyIAvKsKMXDRJTE95W5-pswnoRYuDhg3Fnr0O6qa0=.ccb7d7fa-968e-4e88-a09e-1bfe8293e4c4@github.com>

On Thu, 22 Jul 2021 04:13:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Leonid Mesnik 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:
>> 
>>  - fixed after Kim's comments.
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8270961
>>  - fixed log string.
>>  - import fix.
>>  - 8270961
>
> test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/StressHierarchyBaseClass.java line 117:
> 
>> 115:              * We pass test in this case as this breaks test logic. We have dedicated test configurations
>> 116:              * for OOME:heap provoking class unloading, that why we are not missing test coverage here.
>> 117:              */
> 
> This comment is unnecessary, as it adds nothing over the log message that follows.

Thanks! I just moved it and missed that is the same as the log message.

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 07:21:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 07:21:51 GMT
Subject: RFR: 8270336: [TESTBUG] Fix initialization in NonbranchyTree [v2]
In-Reply-To: <kqtSnFlnHzk10IwzaV_1XAqTq2M2NGhiemb5Uk_sByo=.88d67f1c-3c50-410c-9b4b-540a1792b28b@github.com>
References: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
 <kqtSnFlnHzk10IwzaV_1XAqTq2M2NGhiemb5Uk_sByo=.88d67f1c-3c50-410c-9b4b-540a1792b28b@github.com>
Message-ID: <bDR7hUvllykn0b8n67nYO_rVODB8RavHj-mGBaIXV04=.f4e5bbdf-598a-4302-8370-49105e19d57f@github.com>

On Thu, 22 Jul 2021 04:36:17 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The nsk.share.gc.NonbranchyTree might call initTree() twice and incorrectly reports branchiness in the case of IllegalArgumentException(...).
>
> Leonid Mesnik 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:
> 
>  - fixed typo
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8270336
>  - 8270336: [TESTBUG] Fix initialization in NonbranchyTree

Looks good.

There is some typo in other code: s/Initizlize/Initialize. I do not need a re-review for that fix.

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

Marked as reviewed by tschatzl (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Jul 22 07:22:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 07:22:49 GMT
Subject: RFR: 8270961: [TESTBUG] Move GotWrongOOMEException into
 vm.share.gc package [v2]
In-Reply-To: <fUtwVzGJnNE0QCtL0XoyxODEKR5fDaoaNSj90PuHoIs=.a3a45f79-68c0-41f9-b619-a9c2b3c04a19@github.com>
References: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
 <fUtwVzGJnNE0QCtL0XoyxODEKR5fDaoaNSj90PuHoIs=.a3a45f79-68c0-41f9-b619-a9c2b3c04a19@github.com>
Message-ID: <91jfzBI7s8byTQLDCgDDaLUi4FqH5CsBo4MZf8VAgQs=.5666606b-8cd0-4d16-acfa-3ff3eac962b4@github.com>

On Thu, 22 Jul 2021 04:41:20 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The small refactoring which consolidates shared code in the shared library. Make project more IDE-friendly.
>
> Leonid Mesnik 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:
> 
>  - fixed after Kim's comments.
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8270961
>  - fixed log string.
>  - import fix.
>  - 8270961

Marked as reviewed by tschatzl (Reviewer).

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

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


From kbarrett at openjdk.java.net  Thu Jul 22 07:25:49 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 22 Jul 2021 07:25:49 GMT
Subject: [jdk17] RFR: 8270908: TestParallelRefProc fails on single core
 machines
In-Reply-To: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
References: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
Message-ID: <0WG8c3sEfcuKHRJ8-Kpx1m4EsMNyl8N6h5xf3yXUvNg=.53952cb9-1d92-4f9e-92ff-38caf242c24d@github.com>

On Wed, 21 Jul 2021 12:12:25 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small fix for the test case TestParallelRefProc.
> I changed the way the ParallelGC is tested to the same way G1GC is tested, since the test failed on single core machines. Ergo configures only 1 parallel GC thread on single core machines and with only 1 thread, ergo does not enable `ParallelRefProcEnabled`.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/262


From tschatzl at openjdk.java.net  Thu Jul 22 09:41:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 09:41:07 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation
Message-ID: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>

Hi all,

  can I have reviews for this merge of two methods that have the same purpose: determine whether this pause should be a concurrent start pause. The reason for this merge is that `G1CollectedHeap::determine_start_concurrent_mark_gc` just calls the other, and
  - is the only caller
  - only adds another condition of the same type that `G1Policy::decide_on_conc_mark_initiation` does at the beginning
  - adds some return value checking and return value
which all imho fit into `G1Policy::decide_on_conc_mark_initiation` too.

It also reduces `G1CollectedHeap` a bit. The main reason for me to put this in the new location is basically that that additional condition in  `G1CollectedHeap::determine_start_concurrent_mark_gc` makes all conditions for that decision be located closer together.

If you think otherwise and this is a bad idea, I will close this PR.

Testing: manual gc/g1 runs

Thanks,
  Thomas

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

Commit messages:
 - Refactor decide-on-conc-mark-determination

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

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


From ayang at openjdk.java.net  Thu Jul 22 10:19:49 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 22 Jul 2021 10:19:49 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation
In-Reply-To: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
Message-ID: <qMrufCcErTA-e3fFOQ9pDNqw6-MZqQYGNE4RNvr0X34=.03b6ef5d-5c61-4c0d-90c0-9989caa57cef@github.com>

On Thu, 22 Jul 2021 08:46:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this merge of two methods that have the same purpose: determine whether this pause should be a concurrent start pause. The reason for this merge is that `G1CollectedHeap::determine_start_concurrent_mark_gc` just calls the other, and
>   - is the only caller
>   - only adds another condition of the same type that `G1Policy::decide_on_conc_mark_initiation` does at the beginning
>   - adds some return value checking and return value
> which all imho fit into `G1Policy::decide_on_conc_mark_initiation` too.
> 
> It also reduces `G1CollectedHeap` a bit. The main reason for me to put this in the new location is basically that that additional condition in  `G1CollectedHeap::determine_start_concurrent_mark_gc` makes all conditions for that decision be located closer together.
> 
> If you think otherwise and this is a bad idea, I will close this PR.
> 
> Testing: manual gc/g1 runs
> 
> Thanks,
>   Thomas

bool should_start_concurrent_mark_operation = policy()->decide_on_concurrent_start_pause();

The name, `decide_on_concurrent_start_pause()`, is not very obvious, IMO; I feel it's because it's trying to do two things: 1. deciding the pause type, 2. returns whether the decided pause type is concurrent_start_gc.

I wonder if sth like the following (decoupling the two tasks) is clearer:


policy()->decide_pause_type();
bool should_start_concurrent_mark_operation = collector_state()->in_concurrent_start_gc();


Ofc, this is very subjective. The PR is fine as it is.

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

Marked as reviewed by ayang (Committer).

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


From kbarrett at openjdk.java.net  Thu Jul 22 10:24:59 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 22 Jul 2021 10:24:59 GMT
Subject: RFR: 8270870: Simplify G1ServiceThread
Message-ID: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>

Please review this simplification of the internal control structure of
G1ServiceThread, particularly around the entry and exit of monitor contexts.

In addition, the run_task logging now includes the delay between the
scheduled time to run and the actual, as that seems like useful information
to have sometimes.

I also changed the monitor rank from nonleaf to leaf.  There was no reason
to use nonleaf, and leaf avoids questions about why nonleaf was used.

Testing:
mach5 tier1-3.  This includes the gtest for G1ServiceThread.

Ran a test program with gc+task logging enabled and checked that the logging
output looked okay.

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

Commit messages:
 - improve assert
 - peek/pop -> front/remove_front
 - tidy run_service
 - log schedule delay
 - simplify task wait loop and monitor usage

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 10:28:43 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 10:28:43 GMT
Subject: RFR: 8270842: G1: Only young regions need to redirty outside
 references in remset.
In-Reply-To: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
References: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
Message-ID: <NZVLfx2dIB_2PEQj08H27frVs2IbWiGwqNsvwZV6NTg=.21215c23-240f-4cd9-a51d-91bed5a1e384@github.com>

On Wed, 21 Jul 2021 02:13:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

> For evac failure objects in non-young regions (old) of cset, the outside reference remset already recorded in the dirty queue, we only needs to do it for obj in young regions

Instead of trying to optimize this scanning a bit, did you consider avoiding this rescan for all types of regions?

It seems that the code for skipping the enqueuing for young region is this:

oop G1ParScanThreadState::handle_evacuation_failure_par(oop old, markWord m) {
  assert(_g1h->is_in_cset(old), "Object " PTR_FORMAT " should be in the CSet", p2i(old));

  oop forward_ptr = old->forward_to_atomic(old, m, memory_order_relaxed);
  if (forward_ptr == NULL) {
    // Forward-to-self succeeded. We are the "owner" of the object.
    HeapRegion* r = _g1h->heap_region_containing(old);

    if (_g1h->notify_region_failed_evacuation(r->hrm_index())) {
      _g1h->hr_printer()->evac_failure(r);
    }

    _g1h->preserve_mark_during_evac_failure(_worker_id, old, m);

    G1ScanInYoungSetter x(&_scanner, r->is_young());
    old->oop_iterate_backwards(&_scanner);



I.e. just as a thought, would it be worth a try to fake an "old" region by doing

    // Always make the scanning assume this is from an old region, causing it to collect
    // dirty cards for remembered sets as we will turn this region with a failed allocation
    // into old later.
    G1ScanInYoungSetter x(&_scanner, false);

I have not really checked this actually works, but it seems a nice hack to avoid the rescanning if it worked.

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 10:33:47 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 10:33:47 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation
In-Reply-To: <qMrufCcErTA-e3fFOQ9pDNqw6-MZqQYGNE4RNvr0X34=.03b6ef5d-5c61-4c0d-90c0-9989caa57cef@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
 <qMrufCcErTA-e3fFOQ9pDNqw6-MZqQYGNE4RNvr0X34=.03b6ef5d-5c61-4c0d-90c0-9989caa57cef@github.com>
Message-ID: <3HpCYE1A13xqJzeRJPmYo69JEkTizG8Fw2jO8k3uKEw=.8d56ad7e-bb5d-4abb-b611-99a10e6ee34a@github.com>

On Thu, 22 Jul 2021 10:16:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> ```
> bool should_start_concurrent_mark_operation = policy()->decide_on_concurrent_start_pause();
> ```
> 
> The name, `decide_on_concurrent_start_pause()`, is not very obvious, IMO; I feel it's because it's trying to do two things: 1. deciding the pause type, 2. returns whether the decided pause type is concurrent_start_gc.
> 
> I wonder if sth like the following (decoupling the two tasks) is clearer:
> 
> ```
> policy()->decide_pause_type();
> bool should_start_concurrent_mark_operation = collector_state()->in_concurrent_start_gc();
> ```
> 
> Ofc, this is very subjective. The PR is fine as it is.

Thanks for your review. I understand your concerns and will think about it. Are there any other opinions in that direction?

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 10:48:16 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 10:48:16 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation [v2]
In-Reply-To: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
Message-ID: <FxCz57ciXMd-pzbQ1nNWFLfFtfjbJP-3tMGR2s4zScM=.9727e9f9-e138-4e64-b688-0ad77947ab87@github.com>

> Hi all,
> 
>   can I have reviews for this merge of two methods that have the same purpose: determine whether this pause should be a concurrent start pause. The reason for this merge is that `G1CollectedHeap::determine_start_concurrent_mark_gc` just calls the other, and
>   - is the only caller
>   - only adds another condition of the same type that `G1Policy::decide_on_conc_mark_initiation` does at the beginning
>   - adds some return value checking and return value
> which all imho fit into `G1Policy::decide_on_conc_mark_initiation` too.
> 
> It also reduces `G1CollectedHeap` a bit. The main reason for me to put this in the new location is basically that that additional condition in  `G1CollectedHeap::determine_start_concurrent_mark_gc` makes all conditions for that decision be located closer together.
> 
> If you think otherwise and this is a bad idea, I will close this PR.
> 
> Testing: manual gc/g1 runs
> 
> Thanks,
>   Thomas

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

  ayang review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4867/files
  - new: https://git.openjdk.java.net/jdk/pull/4867/files/bf8d44d1..0393b5f2

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

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 10:48:17 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 10:48:17 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation [v2]
In-Reply-To: <qMrufCcErTA-e3fFOQ9pDNqw6-MZqQYGNE4RNvr0X34=.03b6ef5d-5c61-4c0d-90c0-9989caa57cef@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
 <qMrufCcErTA-e3fFOQ9pDNqw6-MZqQYGNE4RNvr0X34=.03b6ef5d-5c61-4c0d-90c0-9989caa57cef@github.com>
Message-ID: <zLbkJVjx7FyO0tP0edPTcjfb4oc68VnYdoa6F6M0xFQ=.d1503451-1cb3-4386-929a-35349d0cdf8e@github.com>

On Thu, 22 Jul 2021 10:16:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   ayang review
>
> bool should_start_concurrent_mark_operation = policy()->decide_on_concurrent_start_pause();
> 
> The name, `decide_on_concurrent_start_pause()`, is not very obvious, IMO; I feel it's because it's trying to do two things: 1. deciding the pause type, 2. returns whether the decided pause type is concurrent_start_gc.
> 
> I wonder if sth like the following (decoupling the two tasks) is clearer:
> 
> 
> policy()->decide_pause_type();
> bool should_start_concurrent_mark_operation = collector_state()->in_concurrent_start_gc();
> 
> 
> Ofc, this is very subjective. The PR is fine as it is.

I updated the code according to @albertnetymk 's suggestions: I've been on the fence about this already anyway.

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 13:06:52 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 13:06:52 GMT
Subject: RFR: 8270870: Simplify G1ServiceThread
In-Reply-To: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
References: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
Message-ID: <9lGDVhW353XiEWxqP_ooVFhRkVYXRLNLTtGC_puypTA=.c029b8d0-d834-4edc-8453-f2eb63c84920@github.com>

On Thu, 22 Jul 2021 10:15:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simplification of the internal control structure of
> G1ServiceThread, particularly around the entry and exit of monitor contexts.
> 
> In addition, the run_task logging now includes the delay between the
> scheduled time to run and the actual, as that seems like useful information
> to have sometimes.
> 
> I also changed the monitor rank from nonleaf to leaf.  There was no reason
> to use nonleaf, and leaf avoids questions about why nonleaf was used.
> 
> Testing:
> mach5 tier1-3.  This includes the gtest for G1ServiceThread.
> 
> Ran a test program with gc+task logging enabled and checked that the logging
> output looked okay.

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

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


From iwalulya at openjdk.java.net  Thu Jul 22 13:12:49 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 22 Jul 2021 13:12:49 GMT
Subject: RFR: 8271043: Rename G1CollectedHeap::g1mm()
In-Reply-To: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
References: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
Message-ID: <oUBvW1gUKUBe8SIhzNuljJLiQ0_2zisQ3BK6rXKm4xk=.b2438dab-4205-4606-ae74-b4ea0bc41f3d@github.com>

On Wed, 21 Jul 2021 14:12:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that renames the somewhat cryptic name `g1mm` with `monitoring_support` which sounds much better to me.
> Feel free to suggest a better name or if you think it's not worth I can also just drop this change.
> 
> Testing: tier1-5

lgtm!

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

Marked as reviewed by iwalulya (Committer).

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


From iwalulya at openjdk.java.net  Thu Jul 22 13:23:46 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 22 Jul 2021 13:23:46 GMT
Subject: RFR: 8270912: Clean up
 G1CollectedHeap::process_discovered_references()
In-Reply-To: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
References: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
Message-ID: <LsOFWFzZXXEQj5_8uvEZf6uiReCrWDjXXEd947HfY-U=.73ff3b77-2794-471e-89dc-375c8c87f7fa@github.com>

On Wed, 21 Jul 2021 10:14:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this cleanup of `G1CollectedHeap::process_discovered_references()`, cleaning out obsolete or duplicate code and moving asserts?
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Committer).

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

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


From kbarrett at openjdk.java.net  Thu Jul 22 13:39:48 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 22 Jul 2021 13:39:48 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation [v2]
In-Reply-To: <FxCz57ciXMd-pzbQ1nNWFLfFtfjbJP-3tMGR2s4zScM=.9727e9f9-e138-4e64-b688-0ad77947ab87@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
 <FxCz57ciXMd-pzbQ1nNWFLfFtfjbJP-3tMGR2s4zScM=.9727e9f9-e138-4e64-b688-0ad77947ab87@github.com>
Message-ID: <997eiuFa7M_MH_Mz9n_iCWNM3-7I5ks2wIdeLg2m8Xc=.344097a0-681f-49f7-b276-e979c8f6ce71@github.com>

On Thu, 22 Jul 2021 10:48:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this merge of two methods that have the same purpose: determine whether this pause should be a concurrent start pause. The reason for this merge is that `G1CollectedHeap::determine_start_concurrent_mark_gc` just calls the other, and
>>   - is the only caller
>>   - only adds another condition of the same type that `G1Policy::decide_on_conc_mark_initiation` does at the beginning
>>   - adds some return value checking and return value
>> which all imho fit into `G1Policy::decide_on_conc_mark_initiation` too.
>> 
>> It also reduces `G1CollectedHeap` a bit. The main reason for me to put this in the new location is basically that that additional condition in  `G1CollectedHeap::determine_start_concurrent_mark_gc` makes all conditions for that decision be located closer together.
>> 
>> If you think otherwise and this is a bad idea, I will close this PR.
>> 
>> Testing: manual gc/g1 runs
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From iwalulya at openjdk.java.net  Thu Jul 22 13:45:49 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Thu, 22 Jul 2021 13:45:49 GMT
Subject: RFR: 8270870: Simplify G1ServiceThread
In-Reply-To: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
References: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
Message-ID: <gAYkJu_cA5WE2g9jAfAHeGKMraH8K0g7Cl864TRWkOk=.4cf820e0-698c-4fda-9c95-c105812e6390@github.com>

On Thu, 22 Jul 2021 10:15:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simplification of the internal control structure of
> G1ServiceThread, particularly around the entry and exit of monitor contexts.
> 
> In addition, the run_task logging now includes the delay between the
> scheduled time to run and the actual, as that seems like useful information
> to have sometimes.
> 
> I also changed the monitor rank from nonleaf to leaf.  There was no reason
> to use nonleaf, and leaf avoids questions about why nonleaf was used.
> 
> Testing:
> mach5 tier1-3.  This includes the gtest for G1ServiceThread.
> 
> Ran a test program with gc+task logging enabled and checked that the logging
> output looked okay.

Lgtm!

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

Marked as reviewed by iwalulya (Committer).

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


From kbarrett at openjdk.java.net  Thu Jul 22 13:49:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 22 Jul 2021 13:49:50 GMT
Subject: RFR: 8270912: Clean up
 G1CollectedHeap::process_discovered_references()
In-Reply-To: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
References: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
Message-ID: <rUz0sWS6adGhrKPaeN_N88UxUq-vktafcTT9m3tIWgU=.b924892b-01fe-4336-a728-eb138a8e42d6@github.com>

On Wed, 21 Jul 2021 10:14:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this cleanup of `G1CollectedHeap::process_discovered_references()`, cleaning out obsolete or duplicate code and moving asserts?
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

One suggestion for a minor improvement.  Otherwise looks good.

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

> 3280:     G1STWIsAliveClosure is_alive(&_g1h);
> 3281:     G1CopyingKeepAliveClosure keep_alive(&_g1h, _pss.state_for_worker(index));
> 3282:     G1ParEvacuateFollowersClosure complete_gc(&_g1h, _pss.state_for_worker(index), &_task_queues, _tm == RefProcThreadModel::Single ? nullptr : &_terminator, G1GCPhaseTimes::ObjCopy);

New `pss` variable could be used in these two statements too.

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

Marked as reviewed by kbarrett (Reviewer).

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


From tschatzl at openjdk.java.net  Thu Jul 22 14:39:14 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 14:39:14 GMT
Subject: RFR: 8270912: Clean up
 G1CollectedHeap::process_discovered_references() [v2]
In-Reply-To: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
References: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
Message-ID: <ojzAw-L8wD0C4T9G1v6W3js2wuS5E6KNmWus2mD_9w4=.bbc7d855-7471-4ece-9efb-dc2f6f612c56@github.com>

> Hi all,
> 
>   can I have reviews for this cleanup of `G1CollectedHeap::process_discovered_references()`, cleaning out obsolete or duplicate code and moving asserts?
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

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

  kbarrett review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4857/files
  - new: https://git.openjdk.java.net/jdk/pull/4857/files/97b1e81a..849b4dbf

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

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 14:41:48 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 14:41:48 GMT
Subject: RFR: 8271043: Rename G1CollectedHeap::g1mm()
In-Reply-To: <f53u569wW-DxZ6zbc4Jdu6QChv8FZUQCht1CvEGnghw=.860c8b58-1743-4d26-9149-646545a6ccee@github.com>
References: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
 <f53u569wW-DxZ6zbc4Jdu6QChv8FZUQCht1CvEGnghw=.860c8b58-1743-4d26-9149-646545a6ccee@github.com>
Message-ID: <BLnTgWxsokQaQ5vnYmdSLBrbhkxBN8Omtt2JrvDeAio=.5f6cc3be-01cf-40cd-a96a-551bb264ad3d@github.com>

On Wed, 21 Jul 2021 19:18:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that renames the somewhat cryptic name `g1mm` with `monitoring_support` which sounds much better to me.
>> Feel free to suggest a better name or if you think it's not worth I can also just drop this change.
>> 
>> Testing: tier1-5
>
> Looks good.

Thanks @kimbarrett @walulyai for your reviews

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 14:41:49 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 14:41:49 GMT
Subject: Integrated: 8271043: Rename G1CollectedHeap::g1mm()
In-Reply-To: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
References: <N7CjiGnczjRCLkyAqq16LTpkvma3i1cGJImW9jqFyEg=.b038ef5c-910d-4418-b59d-a9581f15ecd3@github.com>
Message-ID: <W6WEOCZmXbhteNBhZ4j4uPR3SHdaECje-xrsJxlWx30=.243c4f76-c58f-4c04-9d61-f0870b444409@github.com>

On Wed, 21 Jul 2021 14:12:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that renames the somewhat cryptic name `g1mm` with `monitoring_support` which sounds much better to me.
> Feel free to suggest a better name or if you think it's not worth I can also just drop this change.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: 8e27d4e8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8e27d4e8ceb3c4ea15e3a3a4328368dbe801870b
Stats:     48 lines in 12 files changed: 1 ins; 0 del; 47 mod

8271043: Rename G1CollectedHeap::g1mm()

Reviewed-by: kbarrett, iwalulya

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 15:25:57 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 15:25:57 GMT
Subject: RFR: 8270912: Clean up
 G1CollectedHeap::process_discovered_references() [v2]
In-Reply-To: <rUz0sWS6adGhrKPaeN_N88UxUq-vktafcTT9m3tIWgU=.b924892b-01fe-4336-a728-eb138a8e42d6@github.com>
References: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
 <rUz0sWS6adGhrKPaeN_N88UxUq-vktafcTT9m3tIWgU=.b924892b-01fe-4336-a728-eb138a8e42d6@github.com>
Message-ID: <U1_VCbMyO3fCRSD9uOqPOenYPbrc3ezmf5H17YaVXV0=.cc04e42c-2405-46e3-818d-023217b994b6@github.com>

On Thu, 22 Jul 2021 13:46:29 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett review
>
> One suggestion for a minor improvement.  Otherwise looks good.

Thanks @kimbarrett @walulyai for your reviews.

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

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


From tschatzl at openjdk.java.net  Thu Jul 22 15:26:00 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 22 Jul 2021 15:26:00 GMT
Subject: Integrated: 8270912: Clean up
 G1CollectedHeap::process_discovered_references()
In-Reply-To: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
References: <TAYIPMhCFrTSasYVkWYS4hpwJqwjIDBEuOU1NUMMydA=.7a1d38c5-894e-4f15-91e8-ed2116073ad3@github.com>
Message-ID: <_bq0ieLFEs3VVHw39yTUw6EvtQ8f0BCN7JFVfHewy_I=.3d8f1e94-d908-43a2-9c95-375dff7b4e84@github.com>

On Wed, 21 Jul 2021 10:14:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this cleanup of `G1CollectedHeap::process_discovered_references()`, cleaning out obsolete or duplicate code and moving asserts?
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c2ed3368
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c2ed336828705e3591a17dba22aa77d89ac96a8d
Stats:     35 lines in 2 files changed: 9 ins; 20 del; 6 mod

8270912: Clean up G1CollectedHeap::process_discovered_references()

Reviewed-by: iwalulya, kbarrett

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

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


From lmesnik at openjdk.java.net  Thu Jul 22 18:20:11 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 18:20:11 GMT
Subject: Integrated: 8270336: [TESTBUG] Fix initialization in NonbranchyTree
In-Reply-To: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
References: <9BsAIuGzarZd13A6XW7m-CvljU7GIWlGemf9JkeITW8=.9a92e076-ac60-4ef8-9e00-784c096ab010@github.com>
Message-ID: <Pklot-0-cSgZfscZVGcXKTiEJcXD2rmYDbqAF9-1_Gc=.0720b6eb-31fd-4a18-948b-b8ef828cee04@github.com>

On Tue, 13 Jul 2021 02:02:02 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk.share.gc.NonbranchyTree might call initTree() twice and incorrectly reports branchiness in the case of IllegalArgumentException(...).

This pull request has now been integrated.

Changeset: 3cadc360
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3cadc3606073f0efc2e97dda348ffb65c41dad0c
Stats:     30 lines in 1 file changed: 4 ins; 17 del; 9 mod

8270336: [TESTBUG] Fix initialization in NonbranchyTree

Reviewed-by: kbarrett, tschatzl

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

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


From lmesnik at openjdk.java.net  Thu Jul 22 18:21:17 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Thu, 22 Jul 2021 18:21:17 GMT
Subject: Integrated: 8270961: [TESTBUG] Move GotWrongOOMEException into
 vm.share.gc package
In-Reply-To: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
References: <68ZribzSwQCScsVM69wcNS5HYkUN3nMIz5H6z05u7UI=.413e9cb3-cb70-4b66-ad67-cc7861999bfb@github.com>
Message-ID: <4-_OOzeOnoX7nRVsyrWlASrSiaap7sFZ1YdAY1ClJTc=.c43f1687-a43d-4345-bff6-87960f72fdd8@github.com>

On Tue, 20 Jul 2021 19:26:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The small refactoring which consolidates shared code in the shared library. Make project more IDE-friendly.

This pull request has now been integrated.

Changeset: 258f188b
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/258f188bff07b6c873128a181746afcf8053d936
Stats:     82 lines in 4 files changed: 37 ins; 40 del; 5 mod

8270961: [TESTBUG] Move GotWrongOOMEException into vm.share.gc package

Reviewed-by: kbarrett, tschatzl

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

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


From cgo at openjdk.java.net  Fri Jul 23 07:16:05 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 23 Jul 2021 07:16:05 GMT
Subject: [jdk17] RFR: 8270908: TestParallelRefProc fails on single core
 machines
In-Reply-To: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
References: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
Message-ID: <wZZaVhACTKY127WHfxASoO3zb0z0XHlZi28_mMi0m_4=.be526f14-db86-4217-99e6-c0eba2787d5e@github.com>

On Wed, 21 Jul 2021 12:12:25 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small fix for the test case TestParallelRefProc.
> I changed the way the ParallelGC is tested to the same way G1GC is tested, since the test failed on single core machines. Ergo configures only 1 parallel GC thread on single core machines and with only 1 thread, ergo does not enable `ParallelRefProcEnabled`.

Thanks for the reviews.
The test failure on macOS is because 3 unrelated test cases ran into a timeout:
* runtime/CreateMirror/ArraysNewInstanceBug.java
* runtime/exceptionMsgs/ArrayIndexOutOfBoundsException/ArrayIndexOutOfBoundsExceptionTest.java#id1
* runtime/LoadClass/TestResize.java

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

PR: https://git.openjdk.java.net/jdk17/pull/262


From tschatzl at openjdk.java.net  Fri Jul 23 09:55:05 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 09:55:05 GMT
Subject: RFR: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation [v2]
In-Reply-To: <997eiuFa7M_MH_Mz9n_iCWNM3-7I5ks2wIdeLg2m8Xc=.344097a0-681f-49f7-b276-e979c8f6ce71@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
 <FxCz57ciXMd-pzbQ1nNWFLfFtfjbJP-3tMGR2s4zScM=.9727e9f9-e138-4e64-b688-0ad77947ab87@github.com>
 <997eiuFa7M_MH_Mz9n_iCWNM3-7I5ks2wIdeLg2m8Xc=.344097a0-681f-49f7-b276-e979c8f6ce71@github.com>
Message-ID: <5dEZgcJyKCv-IV-bInjuZb_NprrK7-OI3OUxQ21WAeQ=.ce2fc320-5e41-41b1-83bb-95304de51b0b@github.com>

On Thu, 22 Jul 2021 13:36:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

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

Thanks @kimbarrett and @albertnetymk for your reviews.

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

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


From tschatzl at openjdk.java.net  Fri Jul 23 09:55:06 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 09:55:06 GMT
Subject: Integrated: 8271060: Merge
 G1CollectedHeap::determine_start_concurrent_mark_gc and
 G1Policy::decide_on_conc_mark_initiation
In-Reply-To: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
References: <06HJSvE7A8EJaNQVAu2-5PMdNwRVFK1VxWbGtTP5C2s=.d278671c-e314-4f82-ae5b-d78c26807424@github.com>
Message-ID: <9JRtxVsi3dH9uwb0R-7x9-EvLvgKloYo3porNRZ2CoY=.4a18bb35-c305-4dce-840e-6d6ed6532a5d@github.com>

On Thu, 22 Jul 2021 08:46:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this merge of two methods that have the same purpose: determine whether this pause should be a concurrent start pause. The reason for this merge is that `G1CollectedHeap::determine_start_concurrent_mark_gc` just calls the other, and
>   - is the only caller
>   - only adds another condition of the same type that `G1Policy::decide_on_conc_mark_initiation` does at the beginning
>   - adds some return value checking and return value
> which all imho fit into `G1Policy::decide_on_conc_mark_initiation` too.
> 
> It also reduces `G1CollectedHeap` a bit. The main reason for me to put this in the new location is basically that that additional condition in  `G1CollectedHeap::determine_start_concurrent_mark_gc` makes all conditions for that decision be located closer together.
> 
> If you think otherwise and this is a bad idea, I will close this PR.
> 
> Testing: manual gc/g1 runs
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: ea182b5c
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea182b5c6eba5f7e66b324068d3b42ffb2d29190
Stats:     50 lines in 5 files changed: 20 ins; 20 del; 10 mod

8271060: Merge G1CollectedHeap::determine_start_concurrent_mark_gc and G1Policy::decide_on_conc_mark_initiation

Reviewed-by: ayang, kbarrett

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

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


From mli at openjdk.java.net  Fri Jul 23 10:19:58 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Fri, 23 Jul 2021 10:19:58 GMT
Subject: RFR: 8270842: G1: Only young regions need to redirty outside
 references in remset.
In-Reply-To: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
References: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
Message-ID: <4zxK3v2H7pVbVNyQ1jO-IYJ6X5aRFrTF7USPPv6bhDE=.2c72d2d6-a2d1-49e8-abea-dd7034ed17f7@github.com>

On Wed, 21 Jul 2021 02:13:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

> For evac failure objects in non-young regions (old) of cset, the outside reference remset already recorded in the dirty queue, we only needs to do it for obj in young regions

Thanks for the suggestion, I think it should work, I will update the patch  as you suggested.

In fact, I have this question in my mind for a while, **this is not related to evac failed obj**. If an obj A in young region has the ONLY reference to obj B in optional set (but not in current cset), where this refering relationship is recorded after the young is evaced to survirvor regions? I guessed it's recorded by other "dead" old obj, as in remset there is no reference from young to old.

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

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


From kbarrett at openjdk.java.net  Fri Jul 23 11:42:11 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 23 Jul 2021 11:42:11 GMT
Subject: RFR: 8270870: Simplify G1ServiceThread
In-Reply-To: <9lGDVhW353XiEWxqP_ooVFhRkVYXRLNLTtGC_puypTA=.c029b8d0-d834-4edc-8453-f2eb63c84920@github.com>
References: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
 <9lGDVhW353XiEWxqP_ooVFhRkVYXRLNLTtGC_puypTA=.c029b8d0-d834-4edc-8453-f2eb63c84920@github.com>
Message-ID: <9LVoycerH2qk6tqQQPX1bCcEYlwvgdPxolXtwa1M6M0=.22b0d611-8f19-4b5f-8712-db640033fbd1@github.com>

On Thu, 22 Jul 2021 13:03:49 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this simplification of the internal control structure of
>> G1ServiceThread, particularly around the entry and exit of monitor contexts.
>> 
>> In addition, the run_task logging now includes the delay between the
>> scheduled time to run and the actual, as that seems like useful information
>> to have sometimes.
>> 
>> I also changed the monitor rank from nonleaf to leaf.  There was no reason
>> to use nonleaf, and leaf avoids questions about why nonleaf was used.
>> 
>> Testing:
>> mach5 tier1-3.  This includes the gtest for G1ServiceThread.
>> 
>> Ran a test program with gc+task logging enabled and checked that the logging
>> output looked okay.
>
> Lgtm.

Thanks @tschatzl and @walulyai  for reviews.

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

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


From tschatzl at openjdk.java.net  Fri Jul 23 11:44:20 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 11:44:20 GMT
Subject: RFR: 8271163: G1 uses wrong degree of MT processing since JDK-8270169
Message-ID: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>

Hi all,

  JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.

This causes crashes because of the code assuming single threaded operation while it is not.

The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.

I also added a comment in the reference processor constructor to why we need to consider both thread counts.

Thanks,
  Thomas

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

Commit messages:
 - Revert 7d2825e4219671bdaef6586864afecbca7b33e48 and comment why

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

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


From tschatzl at openjdk.java.net  Fri Jul 23 12:05:25 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 12:05:25 GMT
Subject: RFR: 8271163: G1 uses wrong degree of MT processing since
 JDK-8270169 [v2]
In-Reply-To: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
References: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
Message-ID: <MA2w-D5LLHrFbqsBjeXflmMYxRaw9IHeDR83-pZEcQU=.a2adf658-f709-46f8-a9a6-05804f98a0e2@github.com>

> Hi all,
> 
>   JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
> This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.
> 
> This causes crashes because of the code assuming single threaded operation while it is not.
> 
> The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.
> 
> I also added a comment in the reference processor constructor to why we need to consider both thread counts.
> 
> Thanks,
>   Thomas

Thomas Schatzl 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:

  Revert 7d2825e4219671bdaef6586864afecbca7b33e48 and comment why

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4888/files
  - new: https://git.openjdk.java.net/jdk/pull/4888/files/c7628e64..04e043a2

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

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

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


From kbarrett at openjdk.java.net  Fri Jul 23 12:05:26 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 23 Jul 2021 12:05:26 GMT
Subject: RFR: 8271163: G1 uses wrong degree of MT processing since
 JDK-8270169 [v2]
In-Reply-To: <MA2w-D5LLHrFbqsBjeXflmMYxRaw9IHeDR83-pZEcQU=.a2adf658-f709-46f8-a9a6-05804f98a0e2@github.com>
References: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
 <MA2w-D5LLHrFbqsBjeXflmMYxRaw9IHeDR83-pZEcQU=.a2adf658-f709-46f8-a9a6-05804f98a0e2@github.com>
Message-ID: <1iP5Hx39pq3JjPQlG_4yGMrdNXnrnbexXwaj7j-RO74=.73df0d9d-8817-414c-b1b6-eab282353ae0@github.com>

On Fri, 23 Jul 2021 11:57:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
>> This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.
>> 
>> This causes crashes because of the code assuming single threaded operation while it is not.
>> 
>> The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.
>> 
>> I also added a comment in the reference processor constructor to why we need to consider both thread counts.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl 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:
> 
>   Revert 7d2825e4219671bdaef6586864afecbca7b33e48 and comment why

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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


From ayang at openjdk.java.net  Fri Jul 23 12:05:26 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 23 Jul 2021 12:05:26 GMT
Subject: RFR: 8271163: G1 uses wrong degree of MT processing since
 JDK-8270169 [v2]
In-Reply-To: <MA2w-D5LLHrFbqsBjeXflmMYxRaw9IHeDR83-pZEcQU=.a2adf658-f709-46f8-a9a6-05804f98a0e2@github.com>
References: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
 <MA2w-D5LLHrFbqsBjeXflmMYxRaw9IHeDR83-pZEcQU=.a2adf658-f709-46f8-a9a6-05804f98a0e2@github.com>
Message-ID: <yBdmfsznP1_3GQzRZLYXXTfjRk2K9ynPbXfsTqM5f10=.ee2840f2-1dc4-4df4-abe5-e6d7e989f66b@github.com>

On Fri, 23 Jul 2021 11:57:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
>> This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.
>> 
>> This causes crashes because of the code assuming single threaded operation while it is not.
>> 
>> The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.
>> 
>> I also added a comment in the reference processor constructor to why we need to consider both thread counts.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl 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:
> 
>   Revert 7d2825e4219671bdaef6586864afecbca7b33e48 and comment why

Marked as reviewed by ayang (Committer).

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

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


From kbarrett at openjdk.java.net  Fri Jul 23 12:05:27 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 23 Jul 2021 12:05:27 GMT
Subject: RFR: 8271163: G1 uses wrong degree of MT processing since
 JDK-8270169
In-Reply-To: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
References: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
Message-ID: <-LJS5RM2FB0OKRO6g8GL4YHK-2bryLFUy9F7E91_tjw=.5938d47c-9ba1-4669-ada8-534294e3e3d6@github.com>

On Fri, 23 Jul 2021 10:33:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
> This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.
> 
> This causes crashes because of the code assuming single threaded operation while it is not.
> 
> The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.
> 
> I also added a comment in the reference processor constructor to why we need to consider both thread counts.
> 
> Thanks,
>   Thomas

As this is a simple backout (plus commentary), I suggest not waiting the usual 24 hours before pushing, to reduce testing noise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4888


From tschatzl at openjdk.java.net  Fri Jul 23 12:05:27 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 12:05:27 GMT
Subject: RFR: 8271163: G1 uses wrong degree of MT processing since
 JDK-8270169
In-Reply-To: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
References: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
Message-ID: <5u9Fb6NQTN7-71A1RiQBZdRWJsaMyDvfVqHuz27lJTg=.608aa048-143c-4288-ac32-7c53eba3a774@github.com>

On Fri, 23 Jul 2021 10:33:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
> This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.
> 
> This causes crashes because of the code assuming single threaded operation while it is not.
> 
> The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.
> 
> I also added a comment in the reference processor constructor to why we need to consider both thread counts.
> 
> Thanks,
>   Thomas

Since this is basically a clean backout of JDK-8270169, I'll skip the 24h rule requirement.

Thanks @kimbarrett @albertnetymk for your reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4888


From tschatzl at openjdk.java.net  Fri Jul 23 12:05:27 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 12:05:27 GMT
Subject: Integrated: 8271163: G1 uses wrong degree of MT processing since
 JDK-8270169
In-Reply-To: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
References: <vVOHVSL146Wesek4-F4iyHpd79zip_gtMtZtm0E07pw=.0c06fe02-06ea-43fe-b4ab-365d4395b9a1@github.com>
Message-ID: <KSIn-x8guLCcLkk4tfSEjxHbtu4qr0YoLVPgpnig7QQ=.9747c275-44e0-4ac8-bb0b-0c59b0d35699@github.com>

On Fri, 23 Jul 2021 10:33:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   JDK-8270169 changed the amount of resources supplied by the CM reference processor, assuming that the CM ref processor is only ever used with the marking threads.
> This is unfortunately not true, the CM reference processor is also used by the Remark pause for discovery using the parallel gc worker threads.
> 
> This causes crashes because of the code assuming single threaded operation while it is not.
> 
> The solution proposed here is to just revert JDK-8270169 which introduced  that change. Applies cleanly.
> 
> I also added a comment in the reference processor constructor to why we need to consider both thread counts.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 8c8e3a0d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c8e3a0df2dac94a2978ec86093985af47ffe330
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8271163: G1 uses wrong degree of MT processing since JDK-8270169

Reviewed-by: kbarrett, ayang

-------------

PR: https://git.openjdk.java.net/jdk/pull/4888


From kbarrett at openjdk.java.net  Fri Jul 23 12:18:34 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 23 Jul 2021 12:18:34 GMT
Subject: RFR: 8270870: Simplify G1ServiceThread [v2]
In-Reply-To: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
References: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
Message-ID: <fNwAGVpWQc4rQ8x0dW75SJ4637Yf_XrGSgNX2wjzOJo=.cf314fb9-ad6b-489e-b607-8b442f79e6b5@github.com>

> Please review this simplification of the internal control structure of
> G1ServiceThread, particularly around the entry and exit of monitor contexts.
> 
> In addition, the run_task logging now includes the delay between the
> scheduled time to run and the actual, as that seems like useful information
> to have sometimes.
> 
> I also changed the monitor rank from nonleaf to leaf.  There was no reason
> to use nonleaf, and leaf avoids questions about why nonleaf was used.
> 
> Testing:
> mach5 tier1-3.  This includes the gtest for G1ServiceThread.
> 
> Ran a test program with gc+task logging enabled and checked that the logging
> output looked okay.

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 g1service_thread
 - improve assert
 - peek/pop -> front/remove_front
 - tidy run_service
 - log schedule delay
 - simplify task wait loop and monitor usage

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4868/files
  - new: https://git.openjdk.java.net/jdk/pull/4868/files/1a2e4e18..bd364d33

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4868&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4868&range=00-01

  Stats: 1793 lines in 122 files changed: 1224 ins; 241 del; 328 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4868/head:pull/4868

PR: https://git.openjdk.java.net/jdk/pull/4868


From kbarrett at openjdk.java.net  Fri Jul 23 12:18:35 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 23 Jul 2021 12:18:35 GMT
Subject: Integrated: 8270870: Simplify G1ServiceThread
In-Reply-To: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
References: <V5OZnx732DqjLmLE0dT3c_ZMImL33kTKBvdjSgMPRaI=.ef529173-c565-4d1d-8789-e08d9643548c@github.com>
Message-ID: <W1-VAORpfN0iXOc-NrgnARTS5nI1Odir3Krwm2bi2vo=.9e37a408-63eb-48aa-9868-a5b148101edf@github.com>

On Thu, 22 Jul 2021 10:15:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this simplification of the internal control structure of
> G1ServiceThread, particularly around the entry and exit of monitor contexts.
> 
> In addition, the run_task logging now includes the delay between the
> scheduled time to run and the actual, as that seems like useful information
> to have sometimes.
> 
> I also changed the monitor rank from nonleaf to leaf.  There was no reason
> to use nonleaf, and leaf avoids questions about why nonleaf was used.
> 
> Testing:
> mach5 tier1-3.  This includes the gtest for G1ServiceThread.
> 
> Ran a test program with gc+task logging enabled and checked that the logging
> output looked okay.

This pull request has now been integrated.

Changeset: 0cc4bb72
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0cc4bb729e3746537e0983a8f2665044ad2689b1
Stats:     109 lines in 3 files changed: 20 ins; 36 del; 53 mod

8270870: Simplify G1ServiceThread

Reviewed-by: tschatzl, iwalulya

-------------

PR: https://git.openjdk.java.net/jdk/pull/4868


From tschatzl at openjdk.java.net  Fri Jul 23 12:51:07 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 23 Jul 2021 12:51:07 GMT
Subject: RFR: 8270842: G1: Only young regions need to redirty outside
 references in remset.
In-Reply-To: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
References: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
Message-ID: <S3vJiQyoGEHIZQWxQWYZvzSrd2znlfUDvvmCBLjzTT8=.ca2985bf-2c23-45f8-a3bb-8de14aefcac8@github.com>

On Wed, 21 Jul 2021 02:13:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

> For evac failure objects in non-young regions (old) of cset, the outside reference remset already recorded in the dirty queue, we only needs to do it for obj in young regions

Please have a look at `G1ParScanThreadState::remember_reference_into_optional_region` - G1 collects those references in an extra data structure when scanning an object after it has been copied in `G1ParScanThreadState` as it encounters those, and uses them as appropriate during optional evacuation.

Fwiw, I did not do any performance evaluation of that idea to completely avoid scanning during evacuation failure. I do not think it has significant impact though.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4853


From ayang at openjdk.java.net  Fri Jul 23 13:57:06 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 23 Jul 2021 13:57:06 GMT
Subject: RFR: 8270187: G1: Remove ConcGCThreads constraint
In-Reply-To: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>
References: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>
Message-ID: <Lzyml4Y-ZO3xAEfBWL5dRUk-L8yTwxLTb33cNl7lRc4=.1c2bd42d-99b1-400d-b534-2f12ec7db204@github.com>

On Mon, 12 Jul 2021 15:09:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing `ConcGCThreads <= ParallelGCThreads` constraint for G1.
> 
> Tested: hotspot_gc with `-XX:ConcGCThreads=3 -XX:ParallelGCThreads=2`

Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4756


From ayang at openjdk.java.net  Fri Jul 23 13:57:07 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 23 Jul 2021 13:57:07 GMT
Subject: Integrated: 8270187: G1: Remove ConcGCThreads constraint
In-Reply-To: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>
References: <_FulfI-PfF12ujInyvCFkqQIyBwNwDb_grqNdBP-_4k=.9ca93ce2-c5f7-4961-b2f4-a223ac6a6550@github.com>
Message-ID: <2L_KG3l_YQcqACSyljlZF9cONWuH-oKfYtYHWCzpBX0=.35f8bcc0-5765-4624-91c5-d72f8abd76c9@github.com>

On Mon, 12 Jul 2021 15:09:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing `ConcGCThreads <= ParallelGCThreads` constraint for G1.
> 
> Tested: hotspot_gc with `-XX:ConcGCThreads=3 -XX:ParallelGCThreads=2`

This pull request has now been integrated.

Changeset: 96247ae8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96247ae8fb4d38229af433c34016c208999900af
Stats:     19 lines in 5 files changed: 0 ins; 17 del; 2 mod

8270187: G1: Remove ConcGCThreads constraint

Reviewed-by: kbarrett, iwalulya

-------------

PR: https://git.openjdk.java.net/jdk/pull/4756


From kbarrett at openjdk.java.net  Sat Jul 24 09:11:16 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 24 Jul 2021 09:11:16 GMT
Subject: RFR: 8271215: Fix data races in G1PeriodicGCTask
Message-ID: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>

Please review this small change to G1PeriodicGCTask, eliminating unlikely
but possible data races with a concurrently running GC pause.  An STS-joiner
is used to ensure there isn't a GC pause while doing the checks to decide
whether to perform a periodic GC.

Testing:
mach5 tier1

-------------

Commit messages:
 - use STS-joiner to prevent GC safepoint concurrency

Changes: https://git.openjdk.java.net/jdk/pull/4899/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4899&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271215
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4899/head:pull/4899

PR: https://git.openjdk.java.net/jdk/pull/4899


From iwalulya at openjdk.java.net  Sat Jul 24 10:40:06 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Sat, 24 Jul 2021 10:40:06 GMT
Subject: RFR: 8271215: Fix data races in G1PeriodicGCTask
In-Reply-To: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
References: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
Message-ID: <G95ZRpag66HyfoXFw7ILJodRcYLMzg1Ves_GpOC56ZA=.52683921-6c31-432d-afc3-cc8edfbdca85@github.com>

On Sat, 24 Jul 2021 09:02:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small change to G1PeriodicGCTask, eliminating unlikely
> but possible data races with a concurrently running GC pause.  An STS-joiner
> is used to ensure there isn't a GC pause while doing the checks to decide
> whether to perform a periodic GC.
> 
> Testing:
> mach5 tier1

Marked as reviewed by iwalulya (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4899


From shade at openjdk.java.net  Mon Jul 26 07:42:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 26 Jul 2021 07:42:08 GMT
Subject: RFR: 8271215: Fix data races in G1PeriodicGCTask
In-Reply-To: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
References: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
Message-ID: <RBzCsheNxQchiHrhsTuOHenu6npG0hJ4VLH4AX6vKrU=.50e26fed-ac27-4e8e-b863-31c18754ef7c@github.com>

On Sat, 24 Jul 2021 09:02:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small change to G1PeriodicGCTask, eliminating unlikely
> but possible data races with a concurrently running GC pause.  An STS-joiner
> is used to ensure there isn't a GC pause while doing the checks to decide
> whether to perform a periodic GC.
> 
> Testing:
> mach5 tier1

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4899


From shade at openjdk.java.net  Mon Jul 26 07:48:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 26 Jul 2021 07:48:08 GMT
Subject: RFR: 8269924: Shenandoah: Introduce weak/strong marking asserts
In-Reply-To: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
References: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
Message-ID: <mAZZswaI019QqoCTfLu_mI_Ac--pD7SDwJcDxbGBuK0=.743dfb26-c014-444c-bcd0-cf03167b6220@github.com>

On Tue, 6 Jul 2021 15:13:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For debugging, it is sometimes important to have not only `shenandoah_assert_marked`, but also `shenandoah_assert_marked_(weak|strong)` flavors.

No takers? :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4691


From rkennke at openjdk.java.net  Mon Jul 26 11:03:10 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 26 Jul 2021 11:03:10 GMT
Subject: RFR: 8269924: Shenandoah: Introduce weak/strong marking asserts
In-Reply-To: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
References: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
Message-ID: <l4unhkHAF91KD6htKWJY3cXUE1VN7lVXlYfdy2Styis=.5d418990-0932-4f9d-93c3-35a5a93fd352@github.com>

On Tue, 6 Jul 2021 15:13:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For debugging, it is sometimes important to have not only `shenandoah_assert_marked`, but also `shenandoah_assert_marked_(weak|strong)` flavors.

Looks good.

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4691


From kbarrett at openjdk.java.net  Mon Jul 26 14:23:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 26 Jul 2021 14:23:07 GMT
Subject: RFR: 8271215: Fix data races in G1PeriodicGCTask
In-Reply-To: <G95ZRpag66HyfoXFw7ILJodRcYLMzg1Ves_GpOC56ZA=.52683921-6c31-432d-afc3-cc8edfbdca85@github.com>
References: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
 <G95ZRpag66HyfoXFw7ILJodRcYLMzg1Ves_GpOC56ZA=.52683921-6c31-432d-afc3-cc8edfbdca85@github.com>
Message-ID: <K6Tum3fYbazlPRie-9AyiieHipNhd_Qcke5stFfdV6w=.fd8cb891-e20d-41f9-888a-840d99c33117@github.com>

On Sat, 24 Jul 2021 10:37:30 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Please review this small change to G1PeriodicGCTask, eliminating unlikely
>> but possible data races with a concurrently running GC pause.  An STS-joiner
>> is used to ensure there isn't a GC pause while doing the checks to decide
>> whether to perform a periodic GC.
>> 
>> Testing:
>> mach5 tier1
>
> Marked as reviewed by iwalulya (Committer).

Thanks @walulyai and @shipilev for reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4899


From kbarrett at openjdk.java.net  Mon Jul 26 14:27:09 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 26 Jul 2021 14:27:09 GMT
Subject: Integrated: 8271215: Fix data races in G1PeriodicGCTask
In-Reply-To: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
References: <o5vuM71jd4XLaG7-85z0zewCN3V7HvCdPK9YC3PCVzE=.884cfafc-7e33-45d4-b02b-4607e6c62122@github.com>
Message-ID: <uG97olG72EAQItfefWaYdr7WV0XQshw8WE9TdfA-98o=.7ed965e4-dbf3-46a8-b61b-a7a127714692@github.com>

On Sat, 24 Jul 2021 09:02:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this small change to G1PeriodicGCTask, eliminating unlikely
> but possible data races with a concurrently running GC pause.  An STS-joiner
> is used to ensure there isn't a GC pause while doing the checks to decide
> whether to perform a periodic GC.
> 
> Testing:
> mach5 tier1

This pull request has now been integrated.

Changeset: f2c359a8
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2c359a8826e51a92f6a7c6917f2c3d223c24488
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8271215: Fix data races in G1PeriodicGCTask

Reviewed-by: iwalulya, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/4899


From shade at openjdk.java.net  Mon Jul 26 14:45:14 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 26 Jul 2021 14:45:14 GMT
Subject: Integrated: 8269924: Shenandoah: Introduce weak/strong marking asserts
In-Reply-To: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
References: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
Message-ID: <TBuFdMqTUSiAcdv1KIhMqNR4nN8bDAVzHGKBHS4MloE=.ed704948-e381-4d1b-a30a-be25c2e8ef51@github.com>

On Tue, 6 Jul 2021 15:13:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For debugging, it is sometimes important to have not only `shenandoah_assert_marked`, but also `shenandoah_assert_marked_(weak|strong)` flavors.

This pull request has now been integrated.

Changeset: 515113d8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/515113d8589875e76980ebf7473cb81f778bb86f
Stats:     46 lines in 2 files changed: 46 ins; 0 del; 0 mod

8269924: Shenandoah: Introduce weak/strong marking asserts

Reviewed-by: rkennke

-------------

PR: https://git.openjdk.java.net/jdk/pull/4691


From shade at openjdk.java.net  Mon Jul 26 14:45:13 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 26 Jul 2021 14:45:13 GMT
Subject: RFR: 8269924: Shenandoah: Introduce weak/strong marking asserts
In-Reply-To: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
References: <ko1ws4eF-Ild7B9FUfpmVBOvMde3hW_RAaQr3yNIt6M=.984f9e8d-b16c-403f-91e6-02e5fed458a7@github.com>
Message-ID: <GyOSBBILxtsEIIvEy7Pg4dW2SnQXuoP1ShuIC8q8PN4=.4af12c7d-2a5b-470e-9879-b88d704d065c@github.com>

On Tue, 6 Jul 2021 15:13:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> For debugging, it is sometimes important to have not only `shenandoah_assert_marked`, but also `shenandoah_assert_marked_(weak|strong)` flavors.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4691


From kbarrett at openjdk.java.net  Mon Jul 26 18:14:01 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 26 Jul 2021 18:14:01 GMT
Subject: RFR: 8271217: Fix race between G1PeriodicGCTask checks and GC request
Message-ID: <uRNcD5_k85STeBV1hlLUA61HTq4pHapBLdha_eAdROE=.3a08b7c8-3df2-4f08-9fc5-c0adb61a2c14@github.com>

Please review this change to remove a race involving G1PeriodicGCTask.  The
task performs various checks to determine whether a periodic GC should be
performed.  If they pass, then it requests the GC by calling try_collect.
The problem is that an unrelated GC could occur after the task's checks but
before its request is processed.  In that case we don't want to do the
periodic GC after all, but there's nothing to prevent it.

This change lets the task capture the various GC counters as part of its
checking, and pass them to try_collect for use in detecting an intervening
GC.

Testing:
mach5 tier1

-------------

Commit messages:
 - eliminate races in periodic gc requests

Changes: https://git.openjdk.java.net/jdk/pull/4905/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4905&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271217
  Stats: 159 lines in 8 files changed: 126 ins; 13 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4905/head:pull/4905

PR: https://git.openjdk.java.net/jdk/pull/4905


From manc at google.com  Mon Jul 26 23:39:26 2021
From: manc at google.com (Man Cao)
Date: Mon, 26 Jul 2021 16:39:26 -0700
Subject: hotspot-gc-dev Digest, Vol 168, Issue 38
In-Reply-To: <CADy33kBHZHfTt5a40YAY8s=FsSeryp=rS0Zy5D_MeoDWc0RLCw@mail.gmail.com>
References: <mailman.41.1624276762.20809.hotspot-gc-dev@openjdk.java.net>
 <CADy33kBHZHfTt5a40YAY8s=FsSeryp=rS0Zy5D_MeoDWc0RLCw@mail.gmail.com>
Message-ID: <CA+w6HxbqqBzFvyR8E49zruuzD7sKBFfujq_ibRUNmv8=ebF+ww@mail.gmail.com>

Hi all,

I added the "g1-heap-resizing" label to the issues that have been brought
up in the thread:
https://bugs.openjdk.java.net/issues/?jql=labels+%3D+g1-heap-resizing.
We agree that most of these issues should be resolved first, before further
working on SoftMaxHeapSize or developing an external component to
automatically set GCTimeRatio/GCCpuPercentage at runtime.

Regarding CurrentMaxHeapSize, it is tracked in
https://bugs.openjdk.java.net/browse/JDK-8204088. It seems more independent
of other g1-heap-resizing issues, so perhaps it could be implemented
earlier. On the other hand, once most of the g1-heap-resizing issues are
fixed, SoftMaxHeapSize should behave better. One main goal of those
g1-heap-resizing issues is to fix the problem that "G1 expands the heap too
aggressively".

I agree that CurrentMaxHeapSize can address several problems that cannot be
solved by tuning SoftMaxHeapSize and/or GCTimeRatio/GCCpuPercentage.
However, it may introduce other issues and does not satisfy all of our
requirements. In particular:
- In our experience, having a tight Xmx is prone to GC thrashing, which
could make servers unresponsive and wasting CPU resources, and is worse
than getting killed by a container manager due to running out of container
RAM (because a killed process can be restarted easily). I suspect using
CurrentMaxHeapSize instead of SoftMaxHeapSize will increase the chance of
GC thrashing, when it is better to let the process run out of container RAM
limit and get killed and restarted.

- We found that turning off CompressedOops could waste 30%-40% heap memory.
This means many of our servers are better off keeping Xmx below 32G. Thus,
many of our servers cannot directly use the strategy of setting Xmx to the
maximum memory available, then dynamically adjust CurrentMaxHeapSize.
Admittedly, this problem exists for both CurrentMaxHeapSize or
SoftMaxHeapSize. We will probably need to develop a separate strategy to
determine when to make Xmx go above 32G. It is also possible to set
-XX:ObjectAlignmentInBytes=16, which can then use CompressedOops up to 64G
of Xmx.

We are definitely happy to experiment and compare automatically setting
CurrentMaxHeapSize vs SoftMaxHeapSize. Again, SoftMaxHeapSize is not ready
until most g1-heap-resizing issues are fixed.

-Man


From mli at openjdk.java.net  Wed Jul 28 04:15:29 2021
From: mli at openjdk.java.net (Hamlin Li)
Date: Wed, 28 Jul 2021 04:15:29 GMT
Subject: RFR: 8270842: G1: Only young regions need to redirty outside
 references in remset.
In-Reply-To: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
References: <ZRYxkuhSgws5Aot_J6OJnasy5B5wC2EDAKo38gNeKsY=.11b1cf5d-e401-4fbb-ae69-b18ef9b20f59@github.com>
Message-ID: <QA5gvr9YcIXY2U0KKTplC4dD_IH1_u9eCsMKNbk0Z3M=.626a2af8-f91a-4b66-97bf-584afaeb2779@github.com>

On Wed, 21 Jul 2021 02:13:38 GMT, Hamlin Li <mli at openjdk.org> wrote:

> For evac failure objects in non-young regions (old) of cset, the outside reference remset already recorded in the dirty queue, we only needs to do it for obj in young regions

Sorry for delayed reply, I've been occupied by other things.
I'm afraid the solution (hacking G1ScanInYoungSetter) does not work as expected. With following super simple patch, I got a crash when Concurrent Mark starts (after evacuation failure in young regions, I triggerred it with G1EvacuationFailureALot).
'''
diff --git a/src/hotspot/share/gc/g1/g1EvacFailure.cpp b/src/hotspot/share/gc/g1/g1EvacFailure.cpp
index 1f775badbac..1ac1a69fc0a 100644
--- a/src/hotspot/share/gc/g1/g1EvacFailure.cpp
+++ b/src/hotspot/share/gc/g1/g1EvacFailure.cpp
@@ -155,7 +155,7 @@ public:
       // remembered set entries missing given that we skipped cards on
       // the collection set. So, we'll recreate such entries now.
       if (_is_young) {
-        obj->oop_iterate(_log_buffer_cl);
+        //obj->oop_iterate(_log_buffer_cl);
       }

       HeapWord* obj_end = obj_addr + obj_size;
diff --git a/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp b/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
index 9eebe411936..7e82f50b373 100644
--- a/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
+++ b/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
@@ -611,7 +611,7 @@ oop G1ParScanThreadState::handle_evacuation_failure_par(oop old, markWord m) {

     _g1h->preserve_mark_during_evac_failure(_worker_id, old, m);

-    G1ScanInYoungSetter x(&_scanner, r->is_young());
+    G1ScanInYoungSetter x(&_scanner, false);
     old->oop_iterate_backwards(&_scanner);

     return old;
diff --git a/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp b/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
index 79f5b3a22cb..2a2060642cc 100644
--- a/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
+++ b/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp
@@ -130,7 +130,7 @@ public:

   template <class T> void enqueue_card_if_tracked(G1HeapRegionAttr region_attr, T* p, oop o) {
     assert(!HeapRegion::is_in_same_region(p, o), "Should have filtered out cross-region references already.");
-    assert(!_g1h->heap_region_containing(p)->is_young(), "Should have filtered out from-young references already.");
+    // assert(!_g1h->heap_region_containing(p)->is_young(), "Should have filtered out from-young references already.");

 #ifdef ASSERT
     HeapRegion* const hr_obj = _g1h->heap_region_containing(o);
'''

After investigation, I think it's because the difference between the initial patch (says pathc I) and the patch hacking G1ScanInYoungSetter (says patch H) is that:
1. Patch I keep all the logic in UpdateLogBuffersDeferred for evac failure obj in young regions, especially it will enqueue all the fields for evac failure obj (check UpdateLogBuffersDeferred::do_oop_work(T* p), not matter where it points to(except of pointing to its own region).
2. Patch H will not do it for fields of evac failure obj in young regions if a field points to obj in cset. (check G1ScanEvacuatedObjClosure::do_oop_work(T* p), G1ParScanThreadState::do_oop_evac(T* p))

If I amend following patch (says Patch A), it will resolve the crash issue, but I don't think this is what we want.
'''
diff --git a/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp b/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
index 9eebe411936..91d9bc76528 100644
--- a/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
+++ b/src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
@@ -208,9 +208,9 @@ void G1ParScanThreadState::do_oop_evac(T* p) {
     return;
   }
   HeapRegion* from = _g1h->heap_region_containing(p);
-  if (!from->is_young()) {
+
     enqueue_card_if_tracked(_g1h->region_attr(obj), p, obj);
-  }
+
'''

I still don't know the exact reason why the Patch H will fail, not sure if you will have some clue?
But seems the Patch I is the right way to go.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4853


From cgo at openjdk.java.net  Wed Jul 28 08:30:29 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 28 Jul 2021 08:30:29 GMT
Subject: [jdk17] RFR: 8270908: TestParallelRefProc fails on single core
 machines
In-Reply-To: <a5v6RMDIxnXnTa73-6--wBCIZS1szR2YY2B4AK2yhqU=.d4aec1ec-c61c-490a-81ef-e8c1cabbdb04@github.com>
References: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
 <a5v6RMDIxnXnTa73-6--wBCIZS1szR2YY2B4AK2yhqU=.d4aec1ec-c61c-490a-81ef-e8c1cabbdb04@github.com>
Message-ID: <B6UlsMP3h6zd38TC8nksCb3PxJZ5BkZIXK_BjbAshrM=.fe859a67-9dbe-47ce-ae51-eeb8ebc42cbf@github.com>

On Wed, 21 Jul 2021 13:26:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi,
>> 
>> please review this small fix for the test case TestParallelRefProc.
>> I changed the way the ParallelGC is tested to the same way G1GC is tested, since the test failed on single core machines. Ergo configures only 1 parallel GC thread on single core machines and with only 1 thread, ergo does not enable `ParallelRefProcEnabled`.
>
> Thanks! Lgtm.

@tschatzl  or @kimbarrett, would one of you mind sponsoring this change?

-------------

PR: https://git.openjdk.java.net/jdk17/pull/262


From cgo at openjdk.java.net  Wed Jul 28 14:52:38 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 28 Jul 2021 14:52:38 GMT
Subject: [jdk17] Integrated: 8270908: TestParallelRefProc fails on single core
 machines
In-Reply-To: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
References: <iE1arR8ejPRDjUuX199ZidGCO9G9ckPHw6D1nZn3__Y=.5c1929e4-0b8a-4379-a391-032a30f31bc1@github.com>
Message-ID: <O0aKdxdDXMjrLtYtFTuK7YCQYouy_CYmq9-26uj7is0=.e290f24a-3652-4a2c-9f25-ae4caee805cd@github.com>

On Wed, 21 Jul 2021 12:12:25 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Hi,
> 
> please review this small fix for the test case TestParallelRefProc.
> I changed the way the ParallelGC is tested to the same way G1GC is tested, since the test failed on single core machines. Ergo configures only 1 parallel GC thread on single core machines and with only 1 thread, ergo does not enable `ParallelRefProcEnabled`.

This pull request has now been integrated.

Changeset: 6e1da644
Author:    Christoph G?ttschkes <cgo at openjdk.org>
Committer: Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/6e1da6440b898d8a10b3db56707a75f32a489149
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8270908: TestParallelRefProc fails on single core machines

Reviewed-by: tschatzl, kbarrett

-------------

PR: https://git.openjdk.java.net/jdk17/pull/262


From rs at jelastic.com  Wed Jul 28 20:06:50 2021
From: rs at jelastic.com (Ruslan Synytsky)
Date: Wed, 28 Jul 2021 23:06:50 +0300
Subject: Status of JEP-8204088/JDK-8236073
In-Reply-To: <CA+w6HxbqqBzFvyR8E49zruuzD7sKBFfujq_ibRUNmv8=ebF+ww@mail.gmail.com>
References: <mailman.41.1624276762.20809.hotspot-gc-dev@openjdk.java.net>
 <CADy33kBHZHfTt5a40YAY8s=FsSeryp=rS0Zy5D_MeoDWc0RLCw@mail.gmail.com>
 <CA+w6HxbqqBzFvyR8E49zruuzD7sKBFfujq_ibRUNmv8=ebF+ww@mail.gmail.com>
Message-ID: <CA++bR4Oiqh_dq2pC9f_=cxSEptvc8K8Fgjav4Gu1oHrGu4CcAQ@mail.gmail.com>

Hi Man, thank you for your feedback. It is clear and highly appreciated. I
love the SoftMaxHeapSize idea and the use cases it serves. It's a great
step forward. Now we can learn, improve, fix and get it better every new
release. At the same time, should we really compare CurrentMaxHeapSize (or
HardMaxHeapSize) vs SoftMaxHeapSize and try to replace one by another?
There are different use cases. One of them just got my attention recently -
restoring JVM runtimes from previosuly saved state
https://mail.openjdk.java.net/pipermail/discuss/2021-July/005890.html. Can
we start from an experimental option for G1 or something that will unlock
us to put more effort behind it?
Thanks
--
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS


On Tue, 27 Jul 2021 at 02:39, Man Cao <manc at google.com> wrote:

> Hi all,
>
> I added the "g1-heap-resizing" label to the issues that have been brought
> up in the thread:
> https://bugs.openjdk.java.net/issues/?jql=labels+%3D+g1-heap-resizing.
> We agree that most of these issues should be resolved first, before
> further working on SoftMaxHeapSize or developing an external component to
> automatically set GCTimeRatio/GCCpuPercentage at runtime.
>
> Regarding CurrentMaxHeapSize, it is tracked in
> https://bugs.openjdk.java.net/browse/JDK-8204088. It seems more
> independent of other g1-heap-resizing issues, so perhaps it could be
> implemented earlier. On the other hand, once most of the g1-heap-resizing
> issues are fixed, SoftMaxHeapSize should behave better. One main goal of
> those g1-heap-resizing issues is to fix the problem that "G1 expands the
> heap too aggressively".
>
> I agree that CurrentMaxHeapSize can address several problems that cannot
> be solved by tuning SoftMaxHeapSize and/or GCTimeRatio/GCCpuPercentage.
> However, it may introduce other issues and does not satisfy all of our
> requirements. In particular:
> - In our experience, having a tight Xmx is prone to GC thrashing, which
> could make servers unresponsive and wasting CPU resources, and is worse
> than getting killed by a container manager due to running out of container
> RAM (because a killed process can be restarted easily). I suspect using
> CurrentMaxHeapSize instead of SoftMaxHeapSize will increase the chance of
> GC thrashing, when it is better to let the process run out of container RAM
> limit and get killed and restarted.
>
> - We found that turning off CompressedOops could waste 30%-40%
> heap memory. This means many of our servers are better off keeping Xmx
> below 32G. Thus, many of our servers cannot directly use the strategy of
> setting Xmx to the maximum memory available, then dynamically adjust
> CurrentMaxHeapSize. Admittedly, this problem exists for both
> CurrentMaxHeapSize or SoftMaxHeapSize. We will probably need to develop a
> separate strategy to determine when to make Xmx go above 32G. It is also
> possible to set -XX:ObjectAlignmentInBytes=16, which can then use
> CompressedOops up to 64G of Xmx.
>
> We are definitely happy to experiment and compare automatically setting
> CurrentMaxHeapSize vs SoftMaxHeapSize. Again, SoftMaxHeapSize is not ready
> until most g1-heap-resizing issues are fixed.
>
> -Man
>


From dcubed at openjdk.java.net  Thu Jul 29 19:50:09 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 29 Jul 2021 19:50:09 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v3]
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <2ppfp1xwNDM6FMqH0iZLYbixIhiHSH0EmxvAXQTbVLo=.8cac62e7-84f5-459d-9ea3-3d28cffc985a@github.com>

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8193559
 - kbarrett CR - delete unused _list member.
 - 8193559.cr0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4671/files
  - new: https://git.openjdk.java.net/jdk/pull/4671/files/5ee49914..a133ca42

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=01-02

  Stats: 39768 lines in 1046 files changed: 18045 ins; 16146 del; 5577 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4671.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 00:00:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 00:00:57 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
 <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com>
Message-ID: <Wpb51LhRhEsD6zyXETGfxRv5KzcxWtFMDAYhGh6Bb-s=.c72dee26-3320-4103-925f-9f5cc91ba764@github.com>

On Sun, 4 Jul 2021 22:29:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett CR - delete unused _list member.
>
> Changes requested by kbarrett (Reviewer).

I've updated the fix with @kimbarrett's rewrite that uses newer C++ features.
I've tested this version with Mach5 Tier[1-3].

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 00:00:56 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 00:00:56 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4671/files
  - new: https://git.openjdk.java.net/jdk/pull/4671/files/a133ca42..3be5dc72

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=02-03

  Stats: 142 lines in 4 files changed: 109 ins; 30 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4671.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671

PR: https://git.openjdk.java.net/jdk/pull/4671


From dholmes at openjdk.java.net  Fri Jul 30 02:33:33 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 30 Jul 2021 02:33:33 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
Message-ID: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com>

On Fri, 30 Jul 2021 00:00:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.

Hi Dan,

I can't comment on all the details of C++ Iterator definitions etc but these new foreach loops are definitely not ugly.  :)

Looks good!

Thanks,
David

src/hotspot/share/runtime/threadSMR.cpp line 638:

> 636: 
> 637: uint ThreadsList::Iterator::check_index(ThreadsList* list, uint i) {
> 638:   assert(i <= list->length(), "invalid index %u", i);

Shouldn't that just be a '<' check?

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Fri Jul 30 04:18:29 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 30 Jul 2021 04:18:29 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com>
Message-ID: <AUDPC9HhixAk2UdCg6F9AzxPEG6K3r3YtolfL8JywEY=.e5eb96e2-fdf2-4153-88bb-b5f97919b622@github.com>

On Fri, 30 Jul 2021 01:54:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.
>
> src/hotspot/share/runtime/threadSMR.cpp line 638:
> 
>> 636: 
>> 637: uint ThreadsList::Iterator::check_index(ThreadsList* list, uint i) {
>> 638:   assert(i <= list->length(), "invalid index %u", i);
> 
> Shouldn't that just be a '<' check?

No, less-eq is correct.  The index being checked here can be 1-past-the-last-element, for an end-iterator.  Including 0 for an empty sequence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Fri Jul 30 04:28:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 30 Jul 2021 04:28:28 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
Message-ID: <fpfNub2qk_JeT8H68b85miQpv9uXKmVaRuXXSBv7KYs=.92c524a4-d13f-44bb-a6df-5c7a69e81ac9@github.com>

On Fri, 30 Jul 2021 00:00:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.

src/hotspot/share/runtime/threadSMR.inline.hpp line 59:

> 57:   assert_not_singular();
> 58:   assert_dereferenceable();
> 59:   Prefetch::read(const_cast<JavaThread**>(_thread_ptr), PrefetchScanIntervalInBytes);

This prefetch is included because the old code had it.  But I'm dubious about it.  This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line.  I'm hoping the original authors can comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Fri Jul 30 04:36:30 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 30 Jul 2021 04:36:30 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
Message-ID: <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>

On Fri, 30 Jul 2021 00:00:56 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.

src/hotspot/share/runtime/threadSMR.inline.hpp line 53:

> 51:   assert_not_singular();
> 52:   assert_same_list(i);
> 53:   return _thread_ptr != i._thread_ptr;

Better might be to have the entire body consist of `return operator==(i);`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dholmes at openjdk.java.net  Fri Jul 30 05:52:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 30 Jul 2021 05:52:29 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <AUDPC9HhixAk2UdCg6F9AzxPEG6K3r3YtolfL8JywEY=.e5eb96e2-fdf2-4153-88bb-b5f97919b622@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com>
 <AUDPC9HhixAk2UdCg6F9AzxPEG6K3r3YtolfL8JywEY=.e5eb96e2-fdf2-4153-88bb-b5f97919b622@github.com>
Message-ID: <4T0vmegiB5unIGg-ZfJVD_x64kXEMc7ZV4IIBqmLEw0=.82b46b5a-8dcc-4991-8931-dfdd4ac137be@github.com>

On Fri, 30 Jul 2021 04:15:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadSMR.cpp line 638:
>> 
>>> 636: 
>>> 637: uint ThreadsList::Iterator::check_index(ThreadsList* list, uint i) {
>>> 638:   assert(i <= list->length(), "invalid index %u", i);
>> 
>> Shouldn't that just be a '<' check?
>
> No, less-eq is correct.  The index being checked here can be 1-past-the-last-element, for an end-iterator.  Including 0 for an empty sequence.

Okay - thanks for explaining.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 16:23:31 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 16:23:31 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <33PFDNQLa3IJPKDV3wX1en98eT72-ecZmnoqsKX7JsQ=.e96fb85e-9edf-4560-ab7f-0107b3a68a9d@github.com>
Message-ID: <Wl0k9_2NFOklSswBztKD48UbEM3k_HxdHoZ312Et29I=.b529f878-0327-43d3-b464-65340fefc505@github.com>

On Fri, 30 Jul 2021 02:30:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.
>
> Hi Dan,
> 
> I can't comment on all the details of C++ Iterator definitions etc but these new foreach loops are definitely not ugly.  :)
> 
> Looks good!
> 
> Thanks,
> David

@dholmes-ora - Thanks for the re-review.
@kimbarrett - Thanks for answering @dholmes-ora's query.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 16:29:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 16:29:34 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
Message-ID: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>

On Fri, 30 Jul 2021 04:33:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.
>
> src/hotspot/share/runtime/threadSMR.inline.hpp line 53:
> 
>> 51:   assert_not_singular();
>> 52:   assert_same_list(i);
>> 53:   return _thread_ptr != i._thread_ptr;
> 
> Better might be to have the entire body consist of `return operator==(i);`.

I think what's there is more clear. If we switch to `return operator==(i)`,
then I think that will lead to some head scratching. Especially since it's
making me wonder right now...

> src/hotspot/share/runtime/threadSMR.inline.hpp line 59:
> 
>> 57:   assert_not_singular();
>> 58:   assert_dereferenceable();
>> 59:   Prefetch::read(const_cast<JavaThread**>(_thread_ptr), PrefetchScanIntervalInBytes);
> 
> This prefetch is included because the old code had it.  But I'm dubious about it.  This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line.  I'm hoping the original authors can comment.

The original author that added the prefetch is @fisk. He's reviewed an earlier
version of this fix and I'm hoping he's around to review this version.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Fri Jul 30 19:12:31 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 30 Jul 2021 19:12:31 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
 <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
Message-ID: <v86h89WW_iPfg1cG4hZ2h66qHExEiH56Ud4h7e29j1A=.b25bc3b4-b278-43da-bf1e-229d1d89c943@github.com>

On Fri, 30 Jul 2021 16:24:33 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadSMR.inline.hpp line 53:
>> 
>>> 51:   assert_not_singular();
>>> 52:   assert_same_list(i);
>>> 53:   return _thread_ptr != i._thread_ptr;
>> 
>> Better might be to have the entire body consist of `return operator==(i);`.
>
> I think what's there is more clear. If we switch to `return operator==(i)`,
> then I think that will lead to some head scratching. Especially since it's
> making me wonder right now...

And _obviously_ I meant `return !operator==(i)`.  Need to keep that all-important one-character difference...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 19:29:29 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 19:29:29 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <v86h89WW_iPfg1cG4hZ2h66qHExEiH56Ud4h7e29j1A=.b25bc3b4-b278-43da-bf1e-229d1d89c943@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
 <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
 <v86h89WW_iPfg1cG4hZ2h66qHExEiH56Ud4h7e29j1A=.b25bc3b4-b278-43da-bf1e-229d1d89c943@github.com>
Message-ID: <G8SrBwNOeAIrs2GdQG9EZ4XQ08aVgQEUVH1kbsAMX-g=.3ef487b8-4132-461a-aa88-6a83c9b2729b@github.com>

On Fri, 30 Jul 2021 19:09:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I think what's there is more clear. If we switch to `return operator==(i)`,
>> then I think that will lead to some head scratching. Especially since it's
>> making me wonder right now...
>
> And _obviously_ I meant `return !operator==(i)`.  Need to keep that all-important one-character difference...

Thanks for the clarification. Now you see why I was scratching my head and
wondering what C++ voodoo you were doing now... :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 20:53:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 20:53:53 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5]
In-Reply-To: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
Message-ID: <FWLdfhOeOUl0LvyzCUnlOJ8wUwID4_fwiF2YSHeeDOE=.c29a2e57-2773-420a-8463-23ceba51576a@github.com>

> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
> piece of history that I'm finally getting around to cleaning up. While this macro has
> been with us for a long time, its time has passed...
> 
> Tested with Mach5 Tier[1-3].

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4671/files
  - new: https://git.openjdk.java.net/jdk/pull/4671/files/3be5dc72..a8865b8e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4671&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4671.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4671/head:pull/4671

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Fri Jul 30 20:53:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 30 Jul 2021 20:53:53 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v2]
In-Reply-To: <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <REN83xGf1wxqIbAra0i1y28bOPY8WGfSieBKPPyRJ4g=.356b2753-24e9-4c6d-9691-6649dc23994d@github.com>
 <0yNOkRrweFvaVauhMHJz8RVSKurahOukCJ9VKQReuZw=.4309a359-d1de-4979-88d2-f49a4075a03c@github.com>
Message-ID: <mK8KaPjqhlRgPAGDIeWwgcpZdwYVkfpz-y-LqZK8Zx0=.4c8657d3-ad9e-41e4-9441-c2f9b2fbca62@github.com>

On Sun, 4 Jul 2021 22:29:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett CR - delete unused _list member.
>
> Changes requested by kbarrett (Reviewer).

Added @kimbarrett's simplification of 'ThreadsList::Iterator::operator!=(Iterator i)'.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Sat Jul 31 04:37:31 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 31 Jul 2021 04:37:31 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5]
In-Reply-To: <FWLdfhOeOUl0LvyzCUnlOJ8wUwID4_fwiF2YSHeeDOE=.c29a2e57-2773-420a-8463-23ceba51576a@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <FWLdfhOeOUl0LvyzCUnlOJ8wUwID4_fwiF2YSHeeDOE=.c29a2e57-2773-420a-8463-23ceba51576a@github.com>
Message-ID: <wdYhetulLpOUeccyz8es8NsGCs_zGBqvIAwNSnSGDts=.7016d928-db96-406e-a611-de3bae5c4520@github.com>

On Fri, 30 Jul 2021 20:53:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)'

This looks good to me (unsurprisingly), except for the prefetch question.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From eosterlund at openjdk.java.net  Sat Jul 31 08:14:31 2021
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Sat, 31 Jul 2021 08:14:31 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
 <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
Message-ID: <k5A7BIOXejdfFUzOTZbI9tGvorpvx-yERSdp2cmoXX4=.89ba2983-b393-427f-8c90-785f235fbd41@github.com>

On Fri, 30 Jul 2021 16:26:35 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/threadSMR.inline.hpp line 59:
>> 
>>> 57:   assert_not_singular();
>>> 58:   assert_dereferenceable();
>>> 59:   Prefetch::read(const_cast<JavaThread**>(_thread_ptr), PrefetchScanIntervalInBytes);
>> 
>> This prefetch is included because the old code had it.  But I'm dubious about it.  This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line.  I'm hoping the original authors can comment.
>
> The original author that added the prefetch is @fisk. He's reviewed an earlier
> version of this fix and I'm hoping he's around to review this version.

I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial.
Now we don't support that kind of hardware any longer, so I don't think this trick would necessarily spark as much joy any longer.
I don't mind if we do or do not perform the prefetching. I'm okay either way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Sat Jul 31 14:24:30 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 31 Jul 2021 14:24:30 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5]
In-Reply-To: <wdYhetulLpOUeccyz8es8NsGCs_zGBqvIAwNSnSGDts=.7016d928-db96-406e-a611-de3bae5c4520@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <FWLdfhOeOUl0LvyzCUnlOJ8wUwID4_fwiF2YSHeeDOE=.c29a2e57-2773-420a-8463-23ceba51576a@github.com>
 <wdYhetulLpOUeccyz8es8NsGCs_zGBqvIAwNSnSGDts=.7016d928-db96-406e-a611-de3bae5c4520@github.com>
Message-ID: <aTD7Rpdb7MfRPXkWl7zlD5xGGnd1R_08OfRrSU_HcOE=.727baac5-fa56-407a-80f2-6cfdf2729433@github.com>

On Sat, 31 Jul 2021 04:34:18 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)'
>
> This looks good to me (unsurprisingly), except for the prefetch question.

@kimbarrett - Thanks for the re-review.

I'm going to leave resolution of the prefetch question to a follow-up bug.
I think that discussion deserves a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From dcubed at openjdk.java.net  Sat Jul 31 14:41:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 31 Jul 2021 14:41:36 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <k5A7BIOXejdfFUzOTZbI9tGvorpvx-yERSdp2cmoXX4=.89ba2983-b393-427f-8c90-785f235fbd41@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
 <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
 <k5A7BIOXejdfFUzOTZbI9tGvorpvx-yERSdp2cmoXX4=.89ba2983-b393-427f-8c90-785f235fbd41@github.com>
Message-ID: <N5m4JF2aYSAQMYKqAntQZ-wZEQ3_Ib1IcMUG_HqFy2Y=.a1907dfb-90d8-4e4e-95a2-763b896a9d1e@github.com>

On Sat, 31 Jul 2021 08:11:05 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The original author that added the prefetch is @fisk. He's reviewed an earlier
>> version of this fix and I'm hoping he's around to review this version.
>
> I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial.
> Now we don't support that kind of hardware any longer, so I don't think this trick would necessarily spark as much joy any longer.
> I don't mind if we do or do not perform the prefetching. I'm okay either way.

I'm going to leave resolution of the prefetch question to a follow-up bug.
I think that discussion deserves a separate issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Sat Jul 31 17:40:36 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 31 Jul 2021 17:40:36 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v5]
In-Reply-To: <FWLdfhOeOUl0LvyzCUnlOJ8wUwID4_fwiF2YSHeeDOE=.c29a2e57-2773-420a-8463-23ceba51576a@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <FWLdfhOeOUl0LvyzCUnlOJ8wUwID4_fwiF2YSHeeDOE=.c29a2e57-2773-420a-8463-23ceba51576a@github.com>
Message-ID: <_ZO1aky7oyRjpY6NTFG_fjGhd9sr0ucpgQ8wO7VXTH8=.8491610a-5043-42f5-a8cc-1e6a906066aa@github.com>

On Fri, 30 Jul 2021 20:53:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> This is a simple rewrite of what is "Possibly the ugliest for loop the world has seen."
>> Thanks to @stefank for the draft proposed fix. Thanks to @fisk for providing this
>> piece of history that I'm finally getting around to cleaning up. While this macro has
>> been with us for a long time, its time has passed...
>> 
>> Tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)'

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4671


From kbarrett at openjdk.java.net  Sat Jul 31 17:40:37 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sat, 31 Jul 2021 17:40:37 GMT
Subject: RFR: 8193559: ugly DO_JAVA_THREADS macro should be replaced [v4]
In-Reply-To: <N5m4JF2aYSAQMYKqAntQZ-wZEQ3_Ib1IcMUG_HqFy2Y=.a1907dfb-90d8-4e4e-95a2-763b896a9d1e@github.com>
References: <NZZ_y2ob4kJEqjINw26XasTvxlhdwk5WnchCtjg07NY=.2f375c7c-b6e2-4958-a3fa-0c3011efc6f9@github.com>
 <gbg17wsMw-WC55Feaidk27jVMkrPhmKmnZMU2eMcft8=.bf04ed6a-240f-4ebd-b138-9bb1f43e28f5@github.com>
 <fY5vuaw1AMCW8yWBiveAD-1IavLXaPZ8-AWzh8F1xXA=.f52c1dc6-030d-4e1e-8dd5-5fa3f593e012@github.com>
 <7XZU2gwQFrzk4sl665oruDmYt_VuyJo8-yvacq3NOuw=.198345bb-ead7-499f-a01a-bb7f75675a38@github.com>
 <k5A7BIOXejdfFUzOTZbI9tGvorpvx-yERSdp2cmoXX4=.89ba2983-b393-427f-8c90-785f235fbd41@github.com>
 <N5m4JF2aYSAQMYKqAntQZ-wZEQ3_Ib1IcMUG_HqFy2Y=.a1907dfb-90d8-4e4e-95a2-763b896a9d1e@github.com>
Message-ID: <I02_jUYSo_6ezkbDrgU-jMg3wMHHnQ8Q1yKX6WitGis=.099659a4-084b-4588-b7e9-3b58966bb89d@github.com>

On Sat, 31 Jul 2021 14:37:29 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial.
>> Now we don't support that kind of hardware any longer, so I don't think this trick would necessarily spark as much joy any longer.
>> I don't mind if we do or do not perform the prefetching. I'm okay either way.
>
> I'm going to leave resolution of the prefetch question to a follow-up bug.
> I think that discussion deserves a separate issue.

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4671