From tschatzl at openjdk.java.net Fri Oct 1 11:55:31 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 1 Oct 2021 11:55:31 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v3] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 04:44:51 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with one additional commit since the last revision: > > Resolve TODOs Initial thoughts while looking through it for the first time and testing it a bit more. More thoughts may be dripping in over time: * G1 already uses so many threads, so adding more does not seem to be a good idea. Also, just one thread is going to be overwhelmed on large heaps, probably making the method less effective there where it is more necessary than in other cases. Maybe just fake cards to scan in the DCQS so that this work is done first (and always) by the refinement threads? Some tweaking of thread numbers and refinement threads is likely needed. * Not sure about whether the complexity for using the bitmap level as storage is worth the effort: in my testing I have never even come close to 512 PLABs per region. In that case (or even earlier), probably just bail out, drop the whole task and do nothing as with that many PLABs the amount of overlap during gc is likely to be small. I need to do some more testing and thinking about this though. * the G1BOTFixingCardSet in HeapRegion should at most be a pointer within HeapRegion: since only a small percentage of regions are ever affected by this, it seems a waste to always allocate memory for them, even if only little. * Actually I have seen only mid single digit number of plabs per region whatever I have been running; so I even kind of think it might be useful to decrease the maximum PLAB size to have more of those so that more threads can work on these and the individual BOT fixup is faster (to abort faster). I have no particular guidance here at this time of how large is too large; but something like half or a third of a region for 32m regions is quite a bit to chew on :) This of course affects the storage needs, but this limit should always be so that we would never want to use the bitmap. * some potential renames to be done only when we are done evaluating this: rename this feature to `G1ConcurrentBOTUpdate`, not "fixing" :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Fri Oct 1 12:11:58 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 1 Oct 2021 12:11:58 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references Message-ID: Hi all, can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. There are three interesting changes: * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times Thanks, Thomas ------------- Commit messages: - Fixes - Revert "8274340: [BACKOUT] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references" Changes: https://git.openjdk.java.net/jdk/pull/5786/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274516 Stats: 189 lines in 16 files changed: 83 ins; 74 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/5786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5786/head:pull/5786 PR: https://git.openjdk.java.net/jdk/pull/5786 From tschatzl at openjdk.java.net Fri Oct 1 16:32:32 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 1 Oct 2021 16:32:32 GMT Subject: RFR: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:23:48 GMT, Yude Lin wrote: > Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5770 From kbarrett at openjdk.java.net Fri Oct 1 19:45:42 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 1 Oct 2021 19:45:42 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming Message-ID: Please review this change to PretouchTask, fixing the mechanism used to claim chunks for parallel touching. The old mechanism unconditionally added a potentially large value to the current pointer and then checked the result for overflow. But since pointer arithmetic overflow is UB, that's not a reliable approach. Testing: mach5 tier1 ------------- Commit messages: - use cmpxchg to claim chunks Changes: https://git.openjdk.java.net/jdk/pull/5791/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5791&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274632 Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5791/head:pull/5791 PR: https://git.openjdk.java.net/jdk/pull/5791 From kbarrett at openjdk.java.net Fri Oct 1 20:01:33 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 1 Oct 2021 20:01:33 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming [v2] In-Reply-To: References: Message-ID: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> > Please review this change to PretouchTask, fixing the mechanism used to > claim chunks for parallel touching. The old mechanism unconditionally added > a potentially large value to the current pointer and then checked the result > for overflow. But since pointer arithmetic overflow is UB, that's not a > reliable approach. > > Testing: > mach5 tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: remove unused _start_addr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5791/files - new: https://git.openjdk.java.net/jdk/pull/5791/files/8b57b3eb..b3e5e12a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5791&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5791&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5791/head:pull/5791 PR: https://git.openjdk.java.net/jdk/pull/5791 From kbarrett at openjdk.java.net Fri Oct 1 20:01:33 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 1 Oct 2021 20:01:33 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 19:38:58 GMT, Kim Barrett wrote: > Please review this change to PretouchTask, fixing the mechanism used to > claim chunks for parallel touching. The old mechanism unconditionally added > a potentially large value to the current pointer and then checked the result > for overflow. But since pointer arithmetic overflow is UB, that's not a > reliable approach. > > Testing: > mach5 tier1 Also removed the no longer used _start_addr member. And I just realized the overflow check was doubly bad, since it was using that value, and the potential wrap-around could exceed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5791 From tschatzl at openjdk.java.net Mon Oct 4 10:57:20 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 4 Oct 2021 10:57:20 GMT Subject: RFR: 8274286: Skip null for make_referent_alive in referenceProcessor [v2] In-Reply-To: <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com> References: <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com> Message-ID: On Wed, 29 Sep 2021 12:39:42 GMT, Albert Mingkun Yang wrote: >> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Refactoring looks good. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5682 From tschatzl at openjdk.java.net Mon Oct 4 11:25:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 4 Oct 2021 11:25:07 GMT Subject: RFR: 8274178: Occupancy value in logging and JFR event is inaccurate in G1IHOPControl In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 20:03:03 GMT, Man Cao wrote: > Hi all, > > Could we have reviews for this minor fix for logging and JFR event occupancy number for G1? See https://bugs.openjdk.java.net/browse/JDK-8274178 for more details. > > This fix is contributed by colleague Jonathan Joo . I am not completely sure this change is correct: the target occupancy is the occupancy we want to reach, which is void G1Policy::record_new_heap_size(uint new_number_of_regions) { [...] _ihop_control->update_target_occupancy(new_number_of_regions * HeapRegion::GrainBytes); } i.e. the current committed amount of regions. I think it is interesting for the user to see what the current usage (fraction of target occupancy, i.e. committed regions) is when marking starts. The change has a valid point though: since `get_conc_mark_start_threshold` is compared towards the non-young occupancy. What about providing that information additionally instead of replacing the existing info? Or alternatively only provide information compared against non young capacity (i.e. the `_target_occupancy` is, as mentioned, against the whole committed memory, not just non-young). Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5762 From tschatzl at openjdk.java.net Mon Oct 4 11:40:06 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 4 Oct 2021 11:40:06 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming [v2] In-Reply-To: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> References: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> Message-ID: <1wtbxP1rHiSvEYybIsGZ25-12noOu6bQ4BlHJfsWQfw=.a8e76303-0503-4f5b-8423-5f2024f8862e@github.com> On Fri, 1 Oct 2021 20:01:33 GMT, Kim Barrett wrote: >> Please review this change to PretouchTask, fixing the mechanism used to >> claim chunks for parallel touching. The old mechanism unconditionally added >> a potentially large value to the current pointer and then checked the result >> for overflow. But since pointer arithmetic overflow is UB, that's not a >> reliable approach. >> >> Testing: >> mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > remove unused _start_addr Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5791 From ayang at openjdk.java.net Mon Oct 4 12:01:29 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 4 Oct 2021 12:01:29 GMT Subject: RFR: 8274286: Skip null for make_referent_alive in referenceProcessor [v3] In-Reply-To: References: Message-ID: > Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure. > > Test: hotspot_gc Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5682/files - new: https://git.openjdk.java.net/jdk/pull/5682/files/e8d87db0..88d895d0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5682&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5682&range=01-02 Stats: 9 lines in 1 file changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5682.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5682/head:pull/5682 PR: https://git.openjdk.java.net/jdk/pull/5682 From ayang at openjdk.java.net Mon Oct 4 12:01:30 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 4 Oct 2021 12:01:30 GMT Subject: RFR: 8274286: Skip null for make_referent_alive in referenceProcessor [v2] In-Reply-To: <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com> References: <0ClSEvg0s9yZDCgBU8hhlXSJWPmKP6GBwAJSbj1gyvs=.524d00a1-8c90-4de6-a8ba-278a74b75256@github.com> Message-ID: <1d1cHHzADWOGv6iBw4Vfj71wEPNihk_quZ43-_rRT4M=.23aef5ad-28fe-4b2a-bf00-d1f3ab95ad60@github.com> On Wed, 29 Sep 2021 12:39:42 GMT, Albert Mingkun Yang wrote: >> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Light edit around the comment, because I don't get what "we need to be careful below" refers to. ------------- PR: https://git.openjdk.java.net/jdk/pull/5682 From pliden at openjdk.java.net Mon Oct 4 18:27:22 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 4 Oct 2021 18:27:22 GMT Subject: RFR: 8274738: ZGC: Use relaxed atomic load when reading bits in the live map Message-ID: `ZLiveMap::get()` currently uses a non-atomic load to read bits in the live map. This should really be an relaxed atomic load. ------------- Commit messages: - 8274738: ZGC: Use relaxed atomic load when reading bits in the live map Changes: https://git.openjdk.java.net/jdk/pull/5809/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5809&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274738 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5809.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5809/head:pull/5809 PR: https://git.openjdk.java.net/jdk/pull/5809 From kbarrett at openjdk.java.net Mon Oct 4 20:29:11 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 4 Oct 2021 20:29:11 GMT Subject: RFR: 8274286: Skip null for make_referent_alive in referenceProcessor [v3] In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 12:01:29 GMT, Albert Mingkun Yang wrote: >> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > comment Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5682 From ayang at openjdk.java.net Mon Oct 4 21:47:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 4 Oct 2021 21:47:06 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming [v2] In-Reply-To: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> References: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> Message-ID: On Fri, 1 Oct 2021 20:01:33 GMT, Kim Barrett wrote: >> Please review this change to PretouchTask, fixing the mechanism used to >> claim chunks for parallel touching. The old mechanism unconditionally added >> a potentially large value to the current pointer and then checked the result >> for overflow. But since pointer arithmetic overflow is UB, that's not a >> reliable approach. >> >> Testing: >> mach5 tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > remove unused _start_addr Using ` + if` instead of `else if` makes the early-return more visible, IMO. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5791 From stefank at openjdk.java.net Tue Oct 5 06:38:04 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 5 Oct 2021 06:38:04 GMT Subject: RFR: 8274738: ZGC: Use relaxed atomic load when reading bits in the live map In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 18:18:11 GMT, Per Liden wrote: > `ZLiveMap::get()` currently uses a non-atomic load to read bits in the live map. This should really be an relaxed atomic load. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5809 From kbarrett at openjdk.java.net Tue Oct 5 07:56:30 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 5 Oct 2021 07:56:30 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming [v3] In-Reply-To: References: Message-ID: > Please review this change to PretouchTask, fixing the mechanism used to > claim chunks for parallel touching. The old mechanism unconditionally added > a potentially large value to the current pointer and then checked the result > for overflow. But since pointer arithmetic overflow is UB, that's not a > reliable approach. > > Testing: > mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into pretouch_chunk_claim - remove unused _start_addr - use cmpxchg to claim chunks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5791/files - new: https://git.openjdk.java.net/jdk/pull/5791/files/b3e5e12a..bd976c03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5791&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5791&range=01-02 Stats: 2690 lines in 138 files changed: 1848 ins; 328 del; 514 mod Patch: https://git.openjdk.java.net/jdk/pull/5791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5791/head:pull/5791 PR: https://git.openjdk.java.net/jdk/pull/5791 From kbarrett at openjdk.java.net Tue Oct 5 08:11:08 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 5 Oct 2021 08:11:08 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming [v2] In-Reply-To: References: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> Message-ID: On Mon, 4 Oct 2021 21:44:25 GMT, Albert Mingkun Yang wrote: > Using ` + if` instead of `else if` makes the early-return more visible, IMO. That doesn't seem like an improvement to me. And it's not an early-return as I would use that term. ------------- PR: https://git.openjdk.java.net/jdk/pull/5791 From kbarrett at openjdk.java.net Tue Oct 5 08:11:08 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 5 Oct 2021 08:11:08 GMT Subject: RFR: 8274632: Possible pointer overflow in PretouchTask chunk claiming [v2] In-Reply-To: <1wtbxP1rHiSvEYybIsGZ25-12noOu6bQ4BlHJfsWQfw=.a8e76303-0503-4f5b-8423-5f2024f8862e@github.com> References: <6Wz6awnDfvMR84HuERFK6tx1Wfb6BcHMtUcsz_7GwNY=.741047df-d48b-4581-96fb-7a152cae77ae@github.com> <1wtbxP1rHiSvEYybIsGZ25-12noOu6bQ4BlHJfsWQfw=.a8e76303-0503-4f5b-8423-5f2024f8862e@github.com> Message-ID: On Mon, 4 Oct 2021 11:36:42 GMT, Thomas Schatzl wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unused _start_addr > > Lgtm. Thanks for reviews @tschatzl and @albertnetymk ------------- PR: https://git.openjdk.java.net/jdk/pull/5791 From kbarrett at openjdk.java.net Tue Oct 5 08:11:09 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 5 Oct 2021 08:11:09 GMT Subject: Integrated: 8274632: Possible pointer overflow in PretouchTask chunk claiming In-Reply-To: References: Message-ID: <5Rz3ZkHukd8HxtxArhi-t4EGBOAS0xr2FoyZyEhrIlM=.090c8d6f-6d51-4f1a-84a1-0f2dd7c0f862@github.com> On Fri, 1 Oct 2021 19:38:58 GMT, Kim Barrett wrote: > Please review this change to PretouchTask, fixing the mechanism used to > claim chunks for parallel touching. The old mechanism unconditionally added > a potentially large value to the current pointer and then checked the result > for overflow. But since pointer arithmetic overflow is UB, that's not a > reliable approach. > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: a914ee72 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/a914ee72167f642b76b1c1cdddd7ff0698d061cc Stats: 11 lines in 2 files changed: 1 ins; 4 del; 6 mod 8274632: Possible pointer overflow in PretouchTask chunk claiming Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5791 From sjohanss at openjdk.java.net Tue Oct 5 09:35:08 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 5 Oct 2021 09:35:08 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 08:58:35 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? > > The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). > > The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). > > This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. > > There are three interesting changes: > * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. > * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. > * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). > > Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times > > Thanks, > Thomas Looks good. Just some small comments. src/hotspot/share/gc/shared/referenceProcessor.cpp line 266: > 264: } else { > 265: RawAccess<>::oop_store(_prev_discovered_addr, new_next); > 266: } What do you think about switching the if-statement around and add a comment explaining why we special case the head? src/hotspot/share/gc/shared/referenceProcessor.hpp line 51: > 49: public: > 50: // For the given j.l.ref.Reference reference, set the discovered field to value. > 51: virtual void enqueue(HeapWord* discovered_field_addr, oop value) = 0; Comments hare a slightly out of date now since passing in the address to the field. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5786 From kbarrett at openjdk.java.net Tue Oct 5 10:10:21 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 5 Oct 2021 10:10:21 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm Message-ID: Please review this fix of the test, eliminating a race that could unexpectedly leave buffers in the "completed" list after all the threads have shut down. Testing: mach5 tier1 ------------- Commit messages: - fix race in test Changes: https://git.openjdk.java.net/jdk/pull/5820/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5820&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273381 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5820.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5820/head:pull/5820 PR: https://git.openjdk.java.net/jdk/pull/5820 From tschatzl at openjdk.java.net Tue Oct 5 10:26:36 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 5 Oct 2021 10:26:36 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references [v2] In-Reply-To: References: Message-ID: <9-eGYnLWMv9N9jL8-jwcwZrr0xdCOsXA8lxtaxx5pys=.42ee8c4a-7cc7-4243-98a7-396c6aebc36f@github.com> > Hi all, > > can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? > > The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). > > The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). > > This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. > > There are three interesting changes: > * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. > * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. > * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). > > Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanss review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5786/files - new: https://git.openjdk.java.net/jdk/pull/5786/files/fe61938f..d9e8d956 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5786/head:pull/5786 PR: https://git.openjdk.java.net/jdk/pull/5786 From tschatzl at openjdk.java.net Tue Oct 5 11:14:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 5 Oct 2021 11:14:07 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references [v2] In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 09:29:53 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> sjohanss review > > src/hotspot/share/gc/shared/referenceProcessor.cpp line 266: > >> 264: } else { >> 265: RawAccess<>::oop_store(_prev_discovered_addr, new_next); >> 266: } > > What do you think about switching the if-statement around and add a comment explaining why we special case the head? I prefer to keep the common case as first option. Added a comment to it though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5786 From sjohanss at openjdk.java.net Tue Oct 5 11:24:08 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 5 Oct 2021 11:24:08 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 10:02:21 GMT, Kim Barrett wrote: > Please review this fix of the test, eliminating a race that could > unexpectedly leave buffers in the "completed" list after all the threads > have shut down. > > Testing: > mach5 tier1 Lgtm ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5820 From tschatzl at openjdk.java.net Tue Oct 5 11:53:05 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 5 Oct 2021 11:53:05 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 10:02:21 GMT, Kim Barrett wrote: > Please review this fix of the test, eliminating a race that could > unexpectedly leave buffers in the "completed" list after all the threads > have shut down. > > Testing: > mach5 tier1 Lgtm apart from the mentioned (imho) comment inaccuracy. test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp line 191: > 189: return; > 190: } else if (!Atomic::load_acquire(_continue_running)) { > 191: // To avoid a race that could leave buffers in the list after this s/avoid/handle/ (or something similar). The change does not eliminate (or avoids) the race, but handles the (not logic-breaking) results of the race. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5820 From tschatzl at openjdk.java.net Tue Oct 5 11:53:05 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 5 Oct 2021 11:53:05 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: References: Message-ID: <4JdnLTNpvrVu08pWRrSd82Xb9MfKDCw0DOS-M8nIsRQ=.81a51a57-f31c-4ca5-8d0f-43818d301a17@github.com> On Tue, 5 Oct 2021 11:49:26 GMT, Thomas Schatzl wrote: >> Please review this fix of the test, eliminating a race that could >> unexpectedly leave buffers in the "completed" list after all the threads >> have shut down. >> >> Testing: >> mach5 tier1 > > test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp line 191: > >> 189: return; >> 190: } else if (!Atomic::load_acquire(_continue_running)) { >> 191: // To avoid a race that could leave buffers in the list after this > > s/avoid/handle/ (or something similar). > > The change does not eliminate (or avoids) the race, but handles the (not logic-breaking) results of the race. Suggestion: // To handle a benign race that could leave buffers in the list after this ------------- PR: https://git.openjdk.java.net/jdk/pull/5820 From mdoerr at openjdk.java.net Tue Oct 5 12:35:22 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 5 Oct 2021 12:35:22 GMT Subject: RFR: 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform Message-ID: The test creates new Nodes and publishes them to concurrent readers. This requires at least release and load_consume. A clean fix would be to make `Node.next` volatile. But that would be a sledgehammer. A minimalistic fix for our supported weak memory model platforms is to insert a `storeFence`. What is better? (See JBS for failure description.) ------------- Commit messages: - 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform Changes: https://git.openjdk.java.net/jdk/pull/5823/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5823&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274773 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5823.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5823/head:pull/5823 PR: https://git.openjdk.java.net/jdk/pull/5823 From ayang at openjdk.java.net Tue Oct 5 14:36:13 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 5 Oct 2021 14:36:13 GMT Subject: RFR: 8274286: Skip null for make_referent_alive in referenceProcessor [v3] In-Reply-To: References: Message-ID: <6i7lJtv_FaAgG3otvhdywYjirObKsjjL3_077B2lNzg=.0fc6a69a-fc04-4aab-9e81-ac2ea61f662a@github.com> On Mon, 4 Oct 2021 12:01:29 GMT, Albert Mingkun Yang wrote: >> Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure. >> >> Test: hotspot_gc > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > comment Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5682 From ayang at openjdk.java.net Tue Oct 5 14:36:13 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 5 Oct 2021 14:36:13 GMT Subject: Integrated: 8274286: Skip null for make_referent_alive in referenceProcessor In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 13:42:14 GMT, Albert Mingkun Yang wrote: > Simple change of avoiding a virtual call for null referent. With this change, two methods of processing the discovered list, `process_discovered_list_work` and `preclean_discovered_reflist`, share the same structure. > > Test: hotspot_gc This pull request has now been integrated. Changeset: bb0bab57 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/bb0bab57a1ff447bfb41cfe10c91838a6812b93d Stats: 24 lines in 1 file changed: 11 ins; 0 del; 13 mod 8274286: Skip null for make_referent_alive in referenceProcessor Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5682 From kbarrett at openjdk.java.net Tue Oct 5 23:40:14 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 5 Oct 2021 23:40:14 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: <4JdnLTNpvrVu08pWRrSd82Xb9MfKDCw0DOS-M8nIsRQ=.81a51a57-f31c-4ca5-8d0f-43818d301a17@github.com> References: <4JdnLTNpvrVu08pWRrSd82Xb9MfKDCw0DOS-M8nIsRQ=.81a51a57-f31c-4ca5-8d0f-43818d301a17@github.com> Message-ID: On Tue, 5 Oct 2021 11:50:57 GMT, Thomas Schatzl wrote: >> test/hotspot/gtest/gc/shared/test_ptrQueueBufferAllocator.cpp line 191: >> >>> 189: return; >>> 190: } else if (!Atomic::load_acquire(_continue_running)) { >>> 191: // To avoid a race that could leave buffers in the list after this >> >> s/avoid/handle/ (or something similar). >> >> The change does not eliminate (or avoids) the race, but handles the (not logic-breaking) results of the race. > > Suggestion: > > // To handle a benign race that could leave buffers in the list after this The race involved is not a benign data race, it's a logic race that's not at all benign. I could describe the race in more detail if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/5820 From tschatzl at openjdk.java.net Wed Oct 6 06:15:09 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 6 Oct 2021 06:15:09 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: References: <4JdnLTNpvrVu08pWRrSd82Xb9MfKDCw0DOS-M8nIsRQ=.81a51a57-f31c-4ca5-8d0f-43818d301a17@github.com> Message-ID: On Tue, 5 Oct 2021 23:37:02 GMT, Kim Barrett wrote: >> Suggestion: >> >> // To handle a benign race that could leave buffers in the list after this > > The race involved is not a benign data race, it's a logic race that's not at all benign. I could describe the race in more detail if you want. I meant "benign" wrt to what is actually tested (functionality of the ptrqueuebuffer), but you are right about that my suggestion is the wrong wording. Just leave it as is then. Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5820 From eosterlund at openjdk.java.net Wed Oct 6 07:48:11 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 6 Oct 2021 07:48:11 GMT Subject: RFR: 8274738: ZGC: Use relaxed atomic load when reading bits in the live map In-Reply-To: References: Message-ID: <8ovQVyQ6-ZZyRNaszk7mQXD0P3D6nJfTsGEuqIXKTyU=.c9f8ceb2-645a-466b-b399-7b9af0500e67@github.com> On Mon, 4 Oct 2021 18:18:11 GMT, Per Liden wrote: > `ZLiveMap::get()` currently uses a non-atomic load to read bits in the live map. This should really be an relaxed atomic load. Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5809 From pliden at openjdk.java.net Wed Oct 6 07:48:11 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 6 Oct 2021 07:48:11 GMT Subject: RFR: 8274738: ZGC: Use relaxed atomic load when reading bits in the live map In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 18:18:11 GMT, Per Liden wrote: > `ZLiveMap::get()` currently uses a non-atomic load to read bits in the live map. This should really be an relaxed atomic load. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5809 From pliden at openjdk.java.net Wed Oct 6 07:48:12 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 6 Oct 2021 07:48:12 GMT Subject: Integrated: 8274738: ZGC: Use relaxed atomic load when reading bits in the live map In-Reply-To: References: Message-ID: On Mon, 4 Oct 2021 18:18:11 GMT, Per Liden wrote: > `ZLiveMap::get()` currently uses a non-atomic load to read bits in the live map. This should really be an relaxed atomic load. This pull request has now been integrated. Changeset: 2faced09 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/2faced09ce0f6901dcdc969e6c85f2a5b55778f1 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8274738: ZGC: Use relaxed atomic load when reading bits in the live map Reviewed-by: stefank, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/5809 From kbarrett at openjdk.java.net Wed Oct 6 11:14:04 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 6 Oct 2021 11:14:04 GMT Subject: RFR: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 11:21:12 GMT, Stefan Johansson wrote: >> Please review this fix of the test, eliminating a race that could >> unexpectedly leave buffers in the "completed" list after all the threads >> have shut down. >> >> Testing: >> mach5 tier1 > > Lgtm Thanks for reviews @kstefanj and @tschatzl . ------------- PR: https://git.openjdk.java.net/jdk/pull/5820 From kbarrett at openjdk.java.net Wed Oct 6 11:17:15 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 6 Oct 2021 11:17:15 GMT Subject: Integrated: 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 10:02:21 GMT, Kim Barrett wrote: > Please review this fix of the test, eliminating a race that could > unexpectedly leave buffers in the "completed" list after all the threads > have shut down. > > Testing: > mach5 tier1 This pull request has now been integrated. Changeset: c80a6127 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/c80a612709f1e483575e2843c1f0ea84e1b9a257 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8273381: Assert in PtrQueueBufferAllocatorTest.stress_free_list_allocator_vm Reviewed-by: sjohanss, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5820 From github.com+10235864+vish-chan at openjdk.java.net Wed Oct 6 12:59:24 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Wed, 6 Oct 2021 12:59:24 GMT Subject: RFR: 8272773: Investigate making card table size configurable Message-ID: Hi, Please review the changes to make CardTable entry size configurable. The changes primarily consists of: 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. ------------- Commit messages: - 8272773: Investigate making card table size configurable Changes: https://git.openjdk.java.net/jdk/pull/5838/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8272773 Stats: 109 lines in 10 files changed: 87 ins; 1 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5838.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838 PR: https://git.openjdk.java.net/jdk/pull/5838 From tschatzl at openjdk.java.net Wed Oct 6 20:48:11 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 6 Oct 2021 20:48:11 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v3] In-Reply-To: References: Message-ID: On Mon, 13 Sep 2021 04:44:51 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with one additional commit since the last revision: > > Resolve TODOs There is another option for storing whether this part of the BOT is unrefined yet: take a bit from the BOT values themselves to encode that. I did not look whether this is actually possible with the current encoding, but is an option if that does not take away too much of the range of the backskip - at the moment we use the values 0-63 (*8 = 512) to encode the offsets within the card, all higher values are backskip values after all. I.e. it might even be that extremely high backskip values which would not be used in all but huge arrays (if at all) are available for such a thing. Just some weird idea that came to my mind... ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Wed Oct 6 20:56:06 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 6 Oct 2021 20:56:06 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v3] In-Reply-To: References: Message-ID: <8oqpDO2rHoqjwKI8Vf9EHuZZKu35B0yM6LF1Em8LRNQ=.e3e6b3bb-33b1-4058-9f85-7be3d8442ee6@github.com> On Mon, 13 Sep 2021 04:44:51 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with one additional commit since the last revision: > > Resolve TODOs Another minor optimization is that if we used the refinement information in some way, only update the BOT for areas that actually may ever be scanned - i.e. anything that is may be put into a remembered set. I.e. we might be promoting a lot of data that never needs to be scanned (because e.g. they reference almost only data within a region). Admittedly this is all just slinging ideas around and see if something sticks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From ihse at openjdk.java.net Thu Oct 7 07:38:08 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 7 Oct 2021 07:38:08 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 19:27:26 GMT, Niklas Radomski wrote: > Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. Changes requested by ihse (Reviewer). make/autoconf/jvm-features.m4 line 365: > 363: AC_MSG_RESULT([yes]) > 364: else > 365: AC_MSG_RESULT([no, $OPENJDK_TARGET_CPU]) Please use the `$OPENJDK_TARGET_OS-$OPENJDK_TARGET_CPU` error message per the pattern above. make/hotspot/gensrc/GensrcAdlc.gmk line 3: > 1: # > 2: # Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved. > 3: # Copyright (c) 2021 SAP SE. All rights reserved. I must say I'm a bit surprised to see these new copyright headers for trivial changes. At the very least, this has not been SAP practice before. Is this in accordance with SAP legal recommendations? ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From nradomski at openjdk.java.net Thu Oct 7 08:27:50 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Thu, 7 Oct 2021 08:27:50 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 07:33:47 GMT, Magnus Ihse Bursie wrote: >> Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update autoconf error message >> - Remove copyright headers > > make/hotspot/gensrc/GensrcAdlc.gmk line 3: > >> 1: # >> 2: # Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved. >> 3: # Copyright (c) 2021 SAP SE. All rights reserved. > > I must say I'm a bit surprised to see these new copyright headers for trivial changes. At the very least, this has not been SAP practice before. Is this in accordance with SAP legal recommendations? I removed them, thank you for the heads-up! ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From nradomski at openjdk.java.net Thu Oct 7 08:27:47 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Thu, 7 Oct 2021 08:27:47 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: > Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: - Update autoconf error message - Remove copyright headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5842/files - new: https://git.openjdk.java.net/jdk/pull/5842/files/17946ddf..5da8c1b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5842&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5842&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5842.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5842/head:pull/5842 PR: https://git.openjdk.java.net/jdk/pull/5842 From tschatzl at openjdk.java.net Thu Oct 7 11:25:14 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 7 Oct 2021 11:25:14 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 12:50:25 GMT, Vishal Chand wrote: > Hi, > > Please review the changes to make CardTable entry size configurable. The changes primarily consists of: > > 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. > 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. > 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. Hi Vish-chan, thanks for your contribution. Could you configure Github actions (see the green box where it says "Testing is not configured") ? This will uncover the issues found when trying to compile it for performance testing. This performance testing will take bit. I am also curious why you enabled minimum card size of 128 bytes? Did you see any advantages in your testing on small heaps? Also, the other comments are based on a very passing look on the code. Thanks, Thomas src/hotspot/share/gc/g1/heapRegion.cpp line 96: > 94: // Initialize card size based on the region size. > 95: // Maximum no. of cards per region is 2^16. > 96: CardTable::initialize_card_size(1 << (region_size_log - 16)); Please make a constant out of the `16`; the reason is the size of the `G1CardSetArray::EntryDataType` being 16 bit. src/hotspot/share/gc/g1/heapRegion.cpp line 103: > 101: LogCardsPerRegion = log2i(CardsPerRegion); > 102: > 103: assert(LogCardsPerRegion <= 16, "Total cards per region should be less than or equal to 2^16"); Same here. This check should probably be moved into (G1) argument processing instead of being checked here all the time. src/hotspot/share/gc/parallel/objectStartArray.cpp line 48: > 46: // size blocks as the card table. > 47: assert((int)block_size == (int)CardTable::card_size, "Sanity"); > 48: assert((int)block_size <= 1024, "block_size must be less than or equal to 1024"); The maximum of `1024` is derived from that we need an extra bit for possible offsets in the byte for backskip values (at least that's a hard limit). Please factor out a constant and comment it. Maybe for now, also check that card element size and offset table element size are equal (although they need not be, but the code may assume that). src/hotspot/share/gc/parallel/objectStartArray.hpp line 57: > 55: static uint block_shift; > 56: static uint block_size; > 57: static uint block_size_in_words; I *think* the naming guideline for static members is the same as for regular class members, i.e. use an underscore in front. Maybe wait on changing this for another person to comment on (I did not look up the style guide). We do not use public static members too often :) src/hotspot/share/gc/shared/cardTable.cpp line 48: > 46: // GCCardSizeInBytes is rounded off to the nearest power of 2, and clamped > 47: // between min and max card sizes > 48: card_size = GCCardSizeInBytes; I would prefer, instead of rounding, add a constraint function on that option that makes sure that the given value is a power of two. src/hotspot/share/gc/shared/cardTable.cpp line 50: > 48: card_size = GCCardSizeInBytes; > 49: card_size = round_up_power_of_2(card_size); > 50: card_size = clamp(card_size, MAX2(min_card_size,card_size_min), card_size_max); I think this is unnecessary: the constraint on the option already prohibits that the given value is within [128, 1024] src/hotspot/share/gc/shared/cardTable.cpp line 52: > 50: card_size = clamp(card_size, MAX2(min_card_size,card_size_min), card_size_max); > 51: card_shift = log2i_exact(card_size); > 52: card_size = 1 << card_shift; Windows compilation correctly fails here: [2021-10-07T09:16:43,181Z] cardTable.cpp(52): error C2220: the following warning is treated as an error [2021-10-07T09:16:43,181Z] cardTable.cpp(52): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) src/hotspot/share/gc/shared/cardTable.cpp line 64: > 62: FLAG_SET_ERGO(GCCardSizeInBytes, card_size); > 63: } > 64: This would also be unnecessary with a constraint function that limits the values of the option. src/hotspot/share/gc/shared/cardTable.cpp line 65: > 63: } > 64: > 65: log_info(gc, barrier)("CardTable entry size: " UINTX_FORMAT, card_size); Please use `log_info_p` here, probably with `gc, init` so that this is marked as "precious" so that this is also printed to the `hs_err` file. src/hotspot/share/gc/shared/cardTable.cpp line 96: > 94: assert((uintptr_t(_whole_heap.start()) & (card_size - 1)) == 0, "heap must start at card boundary"); > 95: assert((uintptr_t(_whole_heap.end()) & (card_size - 1)) == 0, "heap must end at card boundary"); > 96: assert(card_size >= card_size_min && card_size <= card_size_max, "card_size must be between min and max"); Also unnecessary with the constraint function. src/hotspot/share/gc/shared/cardTable.cpp line 468: > 466: uintx CardTable::ct_max_alignment_constraint() { > 467: // CardTable max alignment is computed with card_size_max > 468: return card_size_max * os::vm_page_size(); I think this change causes some tests to fail because their heap will get too large. Maybe it is possible to move code so that the actual card size value is used here to avoid this, or fix the errors (will be visible with enabled github actions). src/hotspot/share/gc/shared/cardTable.hpp line 234: > 232: static uintx card_shift; > 233: static uintx card_size; > 234: static uintx card_size_in_words; Please do not use `uintx`; I think `uint` is just fine for those. src/hotspot/share/gc/shared/cardTable.hpp line 238: > 236: // min and max permissible card sizes > 237: static const uintx card_size_min = 128; > 238: static const uintx card_size_max = 1024; static consts should be CamelCased. src/hotspot/share/gc/shared/gc_globals.hpp line 700: > 698: "Card table entry size (in bytes) for card based collectors") \ > 699: range(128, 1024) \ > 700: // end of GC_FLAGS See e.g. `MaxTenuringThreshold` for how adding a constraint function works. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+16811675+linade at openjdk.java.net Thu Oct 7 11:32:10 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Thu, 7 Oct 2021 11:32:10 GMT Subject: Integrated: 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 09:23:48 GMT, Yude Lin wrote: > Remove the unused ShenandoahUpdateRootsTask duplicate from shenandoahConcurrentMark.cpp This pull request has now been integrated. Changeset: 83198361 Author: Yude Lin Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/8319836152cbd0aa5bf6c93d3ba04733cacf83b4 Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod 8274546: Shenandoah: Remove unused ShenandoahUpdateRootsTask copy Reviewed-by: zgu, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5770 From github.com+741251+turbanoff at openjdk.java.net Thu Oct 7 11:47:20 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 7 Oct 2021 11:47:20 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Message-ID: Collections.sort is just a wrapper, so it is better to use an instance method directly. ------------- Commit messages: - 8272992: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Changes: https://git.openjdk.java.net/jdk/pull/5697/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5697&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274899 Stats: 26 lines in 7 files changed: 0 ins; 13 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/5697.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5697/head:pull/5697 PR: https://git.openjdk.java.net/jdk/pull/5697 From ihse at openjdk.java.net Thu Oct 7 12:14:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 7 Oct 2021 12:14:07 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 08:27:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: > > - Update autoconf error message > - Remove copyright headers Build changes look good now. I leave it to others to determine the actual code changes. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5842 From pliden at openjdk.java.net Thu Oct 7 14:07:12 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 7 Oct 2021 14:07:12 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 08:27:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: > > - Update autoconf error message > - Remove copyright headers Nice to see ZGC ported to linux/ppc! I don't have a lot to say about the ppc-specific code. As you know, we at Oracle don't build and test on that platform, so any problems here will go unnoticed by us. It would be good to see a review or two from your colleagues at SAP. src/hotspot/share/gc/z/zBarrierSetAssembler.cpp line 30: > 28: > 29: Address ZBarrierSetAssemblerBase::address_bad_mask_from_thread(Register thread) { > 30: return Address(thread, (intptr_t) ZThreadLocalData::address_bad_mask_offset()); Instead of casting here in this platform agnostic code, I'd suggest that you add a new constructor for `Address` on PPC, one that takes `(Register, ByteSize)` arguments. Other platforms have that, so I'm a bit surprised that PPC doesn't already have that too. src/hotspot/share/gc/z/zBarrierSetAssembler.cpp line 34: > 32: > 33: Address ZBarrierSetAssemblerBase::address_bad_mask_from_jni_env(Register env) { > 34: return Address(env, (intptr_t) (ZThreadLocalData::address_bad_mask_offset() - JavaThread::jni_environment_offset())); .... and we would avoid there cast here also. ------------- Changes requested by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5842 From sspitsyn at openjdk.java.net Thu Oct 7 15:29:08 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 7 Oct 2021 15:29:08 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Andrey, Nice simplification. It looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5697 From cjplummer at openjdk.java.net Thu Oct 7 15:54:09 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 7 Oct 2021 15:54:09 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5697 From tschatzl at openjdk.java.net Thu Oct 7 17:05:22 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 7 Oct 2021 17:05:22 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define Message-ID: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Hi all, can I have reviews for this change that simplifies performance work with evacuation failure handling a little? In particular, it adds a define called `EVAC_FAILURE_INJECTOR` (on by default in non-product builds) that allows to compile in/out the relevant injector code also in product mode (if manually enabled). Actually, this PR suggests two variants for this: one that also automatically enables flags when `EVAC_FAILURE_INJECTOR` is selected (beaa6c3), and one that requires the developer also change the options from develop/notproduct to product to be available (9f07ffd). The first is maybe makes the change a bit too hacky in `g1_globals.hpp` (unless there are ways to do that better, i.e. I could move the `GC_G1_EVACUATION_FAILURE_FLAGS` somewhere, or there is a much better preprocessor trick here, so I would like to have you decide. Testing: gha, manual checking that in product mode by default no evacuation failure handling is in, but with the flag, and otherwise the same as before, tier1-5 Thanks, Thomas ------------- Commit messages: - Automatically enable flags - some additional comments - First version, a bit underwhelming Changes: https://git.openjdk.java.net/jdk/pull/5851/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5851&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274910 Stats: 118 lines in 6 files changed: 73 ins; 29 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5851.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5851/head:pull/5851 PR: https://git.openjdk.java.net/jdk/pull/5851 From jonathanjoo at google.com Thu Oct 7 23:08:23 2021 From: jonathanjoo at google.com (Jonathan Joo) Date: Thu, 7 Oct 2021 19:08:23 -0400 Subject: RFR: 8274178: Occupancy value in logging and JFR event is inaccurate in G1IHOPControl Message-ID: Hi Thomas, Thanks for taking a look! I just wanted to clarify what you meant from your message - for the field that I'm replacing ("occupancy"), are you saying that we do indeed want to look at the total used heap space, even though get_conc_mark_start_threshold() is depending on the non_young occupancy bytes? In other words, the actual_target values being logged are related to heap()->used(), while the get_conc_mark_start_threshold() values are related to non_young_capacity_bytes()? If so, would an appropriate change be something like keeping the original code, but adding a single new field in the debug message after "threshold" with something like: "non-young usage (compared against threshold): " + G1CollectedHeap::heap()->non_young_capacity_bytes()? Thank you, ~ Jonathan From mli at openjdk.java.net Fri Oct 8 01:19:06 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 8 Oct 2021 01:19:06 GMT Subject: RFR: 8274466 G1: simplify G1 collector states [v2] In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 01:34:28 GMT, Hamlin Li wrote: >> This is a minor improvement which remove the redundant G1 Collector states usages. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Revert wrong code Kindly reminder. ------------- PR: https://git.openjdk.java.net/jdk/pull/5745 From mli at openjdk.java.net Fri Oct 8 01:19:14 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 8 Oct 2021 01:19:14 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 08:37:30 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator > - Rename Xxx to G1Xxx > - Clean code > - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums > - Initial commit Kindly reminder. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From thomas.schatzl at oracle.com Fri Oct 8 06:17:31 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 8 Oct 2021 08:17:31 +0200 Subject: RFR: 8274178: Occupancy value in logging and JFR event is inaccurate in G1IHOPControl In-Reply-To: References: Message-ID: <3190eb70-7402-23cb-c9c8-4071740a4816@oracle.com> Hi, On 08.10.21 01:08, Jonathan Joo wrote: > Hi Thomas, > > Thanks for taking a look! I just wanted to clarify what you meant from your > message - for the field that I'm replacing ("occupancy"), are you saying > that we do indeed want to look at the total used heap space, even though > get_conc_mark_start_threshold() is depending on the non_young occupancy > bytes? In other words, the actual_target values being logged are related to > heap()->used(), while the get_conc_mark_start_threshold() values are > related to non_young_capacity_bytes()? > > If so, would an appropriate change be something like keeping the original > code, but adding a single new field in the debug message after "threshold" > with something like: "non-young usage (compared against threshold): " + > G1CollectedHeap::heap()->non_young_capacity_bytes()? Yes, that's what I suggested. Thanks, Thomas From tschatzl at openjdk.java.net Fri Oct 8 07:34:18 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 07:34:18 GMT Subject: RFR: 8274927: Remove unnecessary G1ArchiveAllocator code Message-ID: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> Hi all, can I have reviews for this change that removes code that is fairly trivially recognizable as useless? The `_archive_allocator` is always freed after use (see `HeapShared::copy_closed/open_objects`), so it must always be `nullptr` when it's accessed outside the CDS dump code. I kept the asserts in the original places, but idk if that is really necessary. Testing: tier1-5 ------------- Commit messages: - Improved log messages - Cleanup unnecessary archive allocator stuff Changes: https://git.openjdk.java.net/jdk/pull/5861/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5861&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274927 Stats: 36 lines in 3 files changed: 0 ins; 26 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5861.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5861/head:pull/5861 PR: https://git.openjdk.java.net/jdk/pull/5861 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 08:35:15 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 08:35:15 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:05:41 GMT, Thomas Schatzl wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > src/hotspot/share/gc/parallel/objectStartArray.cpp line 48: > >> 46: // size blocks as the card table. >> 47: assert((int)block_size == (int)CardTable::card_size, "Sanity"); >> 48: assert((int)block_size <= 1024, "block_size must be less than or equal to 1024"); > > The maximum of `1024` is derived from that we need an extra bit for possible offsets in the byte for backskip values (at least that's a hard limit). Please factor out a constant and comment it. > Maybe for now, also check that card element size and offset table element size are equal (although they need not be, but the code may assume that). What is meant by "factor out" a constant? ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 08:42:08 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 08:42:08 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:20:37 GMT, Thomas Schatzl wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > src/hotspot/share/gc/parallel/objectStartArray.hpp line 57: > >> 55: static uint block_shift; >> 56: static uint block_size; >> 57: static uint block_size_in_words; > > I *think* the naming guideline for static members is the same as for regular class members, i.e. use an underscore in front. Maybe wait on changing this for another person to comment on (I did not look up the style guide). > We do not use public static members too often :) Actually I've kept the names of all the pre-existing constants (which are now variables) same as before. Otherwise we have to change all the references also. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 08:52:12 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 08:52:12 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 11:10:07 GMT, Thomas Schatzl wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > src/hotspot/share/gc/shared/cardTable.cpp line 64: > >> 62: FLAG_SET_ERGO(GCCardSizeInBytes, card_size); >> 63: } >> 64: > > This would also be unnecessary with a constraint function that limits the values of the option. **FLAG_SET_ERGO** is needed for G1 GC. In case of G1, min card size is determined by the region size. For the following cmdline arguments: -XX:G1HeapRegionSize=32M -XX:GCCardSizeInBytes=256 ---- card_size is ergonomically set to 512 instead of 256, as min. card size for 32M region is 512. > src/hotspot/share/gc/shared/cardTable.hpp line 234: > >> 232: static uintx card_shift; >> 233: static uintx card_size; >> 234: static uintx card_size_in_words; > > Please do not use `uintx`; I think `uint` is just fine for those. I tried using uint, but card_size is being treated as a uintx everywhere in the code. So I'm observing compilation errors with uint. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From ayang at openjdk.java.net Fri Oct 8 09:12:07 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 8 Oct 2021 09:12:07 GMT Subject: RFR: 8274466 G1: simplify G1 collector states [v2] In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 01:34:28 GMT, Hamlin Li wrote: >> This is a minor improvement which remove the redundant G1 Collector states usages. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Revert wrong code I think using the field directly, instead of the method accessor, is more consistent. However, the ticket title should probably be updated. (The current one suggests sth more, IMO.) ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5745 From ayang at openjdk.java.net Fri Oct 8 09:16:08 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 8 Oct 2021 09:16:08 GMT Subject: RFR: 8274430: Remove some debug error printing code added in JDK-8017163 In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 08:59:23 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that undoes some logging changes from JDK-8017163, in particular it added the `XXX card set` lines in the output as shown in an example below: > > ``` [171.616s][1632757560415ms][error][gc,verify ] GC(129) Missing rem set entry: > [171.616s][1632757560415ms][error][gc,verify ] GC(129) Field 0x00000007fb1008f0 of obj 0x00000007fb1008d8 in region 1485:(O)[0x00000007fb000000,0x00000 > [171.616s][1632757560415ms][error][gc,verify ] GC(129) NULL card setjava.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry > [...] > points to obj 0x00000004d9abd4c8 in region 683:(S)[0x00000004d9000000,0x00000004da000000,0x00000004da000000] remset Complete > > > This string would indicate which card set container does not have the requested remembered set entry. This is unnecessary information, as the "points to obj" string later shows that there should be a remset to this region already, and otherwise only interesting for debugging. > > Testing: gha > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5733 From tschatzl at openjdk.java.net Fri Oct 8 09:37:18 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 09:37:18 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 08:37:30 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator > - Rename Xxx to G1Xxx > - Clean code > - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums > - Initial commit I think other than the given comments the change seems good, but there will be a second thorough path. Also the direct use of `G1SegmentedArrayBuffer` (I will *likely* suggest a separate `G1SegmentedArray` subclass for the new features) in `G1EvacuationFailureObjsInHR` seems okay. src/hotspot/share/gc/g1/g1CardSetMemory.cpp line 88: > 86: void G1CardSetAllocator::free(Elem* elem) { > 87: assert(elem != nullptr, "precondition"); > 88: // assert(elem_size() >= sizeof(G1CardSetContainer), "size mismatch"); Should be removed as it has been added to the constructor. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 41: > 39: // Collects G1CardSetAllocator options/heuristics. Called by G1CardSetAllocator > 40: // to determine the next size of the allocated G1CardSetBuffer. > 41: Superfluous newline src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 99: > 97: // memory. > 98: template > 99: class G1CardSetAllocator : public G1SegmentedArray { I think a `G1CardSetAllocator` *has* or *uses* a `G1SegmentedArray`, but itself is not. I.e. this does not seem to be a proper is-a relation, so the subclassing here seems wrong. Adding a member of that type and using it seems better to me. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 143: > 141: > 142: size_t wasted_mem_size() const { > 143: return (G1SegmentedArray::num_available_nodes() Maybe the code looks a bit better with a typedef for `G1SegmentedArray`. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 84: > 82: } > 83: > 84: const char* start() const { return _buffer; } I would prefer a `copy_to` method instead of exposing the raw buffer pointer; this is the only use in the follow-up code. That method is in this case better added in that change to highlight it. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 146: > 144: > 145: G1SegmentedArrayAllocOptions(uint elem_size, uint initial_num_elems = MinimumBufferSize, > 146: uint max_num_elems = MaximumBufferSize, uint alignment = BufferAlignment) : Now that this class is going to be used in multiple contexts, I would prefer if the defaults (and default values) would be removed and added at the place of use. Just add an empty constructor that sets this to bogus values (zeros probably), and check that these are set in eg. `next_num_elems`. Alternatively delay this suggested change to the next and change back the value of `BufferAlignment` which I'd actually prefer. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 157: > 155: } > 156: > 157: uint elem_size() const {return _elem_size;} Pre-existing: space after the `{`. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 166: > 164: // G1SegmentedArrayBufferList is the free list to cache G1SegmentedArrayBuffer, > 165: // and G1SegmentedArrayAllocOptions is the configuration for G1SegmentedArray > 166: // attributes. A large part of the `G1CardSetAllocator` documentation needs to go here, talking about MT behavior, how to use etc. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 174: > 172: > 173: volatile uint _num_available_nodes; // Number of nodes available in all buffers (allocated + free + pending + not yet used). > 174: volatile uint _num_allocated_nodes; // Number of total nodes allocated and in use. Since these are purely statistics members I would prefer if they were located last in the member list as they were before. Typically, order members by "importance", which is of course subjective; but in this case there is no reason to change the order from original code. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 213: > 211: template > 212: void iterate_nodes(Visitor& v); > 213: }; These seem to be new. Please introduce them in the next change. These introductions of new functionality when factoring out code makes it really hard to review (or at least harder than necessary). The reason I'm saying this is because such additions makes at least me suspicious of what else has been added and changed, resulting in extra effort to look through *everything* again - particularly if the author did not mention that this or that has been added (beyond what is necessary to make things work again). Which in turn makes reviews like this less appealing to do (they are typically boring - we probably prefer "boring" reviews :) ) because of the obvious extra effort. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 215: > 213: }; > 214: > 215: Extra newline. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 32: > 30: #include "runtime/atomic.hpp" > 31: #include "utilities/globalCounter.hpp" > 32: #include "utilities/globalCounter.inline.hpp" Only the .inline.hpp is needed here. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 63: > 61: > 62: > 63: // ==== G1SegmentedArrayBufferList ==== Please remove these class markers (`//===== ====`). They are not used anywhere else in gc code but maybe in ancient code and they do not add anything. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 130: > 128: template > 129: G1SegmentedArrayBuffer* G1SegmentedArray::create_new_buffer( > 130: G1SegmentedArrayBuffer* const prev) { I think it is still okay to put the parameter on the previous line. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 222: > 220: template > 221: Elem* G1SegmentedArray::allocate() { > 222: G1SegmentedArrayBuffer* cur = Atomic::load_acquire(&_first); >From the original code the `assert(elem_size > 0, ...` is missing and still seems appropriate to be in the base class. The subclass seems to just do that. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Fri Oct 8 09:40:21 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 09:40:21 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 24 Sep 2021 08:37:30 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator > - Rename Xxx to G1Xxx > - Clean code > - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums > - Initial commit Hi, > > Sorry for the late reply. Coincidentally around release there's also some housekeeping to do. > > Thanks Thomas, it's OK, this is not that urgent. > > > My main question about this change is: Would it be possible to give a sneak-peek on the use of `G1SegmentedArray` in the [JDK-8254739](https://bugs.openjdk.java.net/browse/JDK-8254739) code? It is impossible to determine if the change fits the intended purpose, and I want to avoid changing `G1SegmentedArray` again later. > > Sure, I've put the merged code in a temporary branch, https://github.com/Hamlin-Li/jdk/tree/tmp-merge.segmented-array.speed-remove-self. "speed-remove-self" part is still the old one, I did not change it yet, including the suggestions you gave in #5181 and old home made segmented array implementation; I just use the new G1SegmentedArray in G1EvacuationFailureObjsInHR. Thanks, that helped a lot to understand the change. I did some preliminary clean-up of then unused code, and it looks much nicer then. > > > This means that multiple threads might add new segments to it at the same time, meaning that they may try to append new segments to it. What happens with the thread and the segment that fails? Shouldn't this allocation be reused somehow (maybe for other segmented arrays?). > > Current(original) implementation just drop the newly allocated G1SegmentedArrayBuffer if current thread fails, seems it's fine as the race should be rare, should we add the faield one to free list? seems adding to freelist will bring some benefit. Yes, that's also what `G1CardSetAllocator` does. At least there, the race isn't that rare. > > > Also, this seems to drop the concurrent freeing of these segments after GC, which is nice too. > > The remembered set uses the memory provided by the segmented arrays in chunks too, i.e. the `G1CardSetArray` container. Not sure if something like this would be more appropriate here instead of directly using the chunks (but may well be as good). > > Not quite sure, seems both have benefit, in `G1CardSetArray` way, it has better design benefit; in G1SegmentedArray::iterate_nodes/G1EvacuationFailureObjsInHR::visit, it might have better performance. I'm OK with both ways, please kindly let me know your decision. The concurrent freeing of the arrays is a good to have since the infrastructure to do it is already there. It can be added later though. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Fri Oct 8 09:51:13 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 09:51:13 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:32:25 GMT, Vishal Chand wrote: >> src/hotspot/share/gc/parallel/objectStartArray.cpp line 48: >> >>> 46: // size blocks as the card table. >>> 47: assert((int)block_size == (int)CardTable::card_size, "Sanity"); >>> 48: assert((int)block_size <= 1024, "block_size must be less than or equal to 1024"); >> >> The maximum of `1024` is derived from that we need an extra bit for possible offsets in the byte for backskip values (at least that's a hard limit). Please factor out a constant and comment it. >> Maybe for now, also check that card element size and offset table element size are equal (although they need not be, but the code may assume that). > > What is meant by "factor out" a constant? Instead of embedding the value "1024" everywhere, use a (private) static const that is named appropriately, and can be documented as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From tschatzl at openjdk.java.net Fri Oct 8 10:02:09 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 10:02:09 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:46:36 GMT, Vishal Chand wrote: >> src/hotspot/share/gc/shared/cardTable.cpp line 64: >> >>> 62: FLAG_SET_ERGO(GCCardSizeInBytes, card_size); >>> 63: } >>> 64: >> >> This would also be unnecessary with a constraint function that limits the values of the option. > > **FLAG_SET_ERGO** is needed for G1 GC. In case of G1, min card size is determined by the region size. > For the following cmdline arguments: -XX:G1HeapRegionSize=32M -XX:GCCardSizeInBytes=256 > ---- card_size is ergonomically set to 512 instead of 256, as min. card size for 32M region is 512. Let's leave this question out for now: I am not sure it makes sense to allow a card size of 256; however the common reaction when specifying incompatible command line options would be to bail out. The question is what to do if the user selects GCCardSizeInBytes=256 and G1 ergonomically decides to use 32m regions. Silently use 16m regions, which are very likely worse than 32m regions in that case? That is why we should first determine if card size of 256 makes sense somewhere and then decide (or somebody else has a particular opinion on this). ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From tschatzl at openjdk.java.net Fri Oct 8 10:11:16 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 10:11:16 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: <6dDPGG6AHKIsbKDD9E2F37LLylKsjc7QbWfE8C21kH8=.fe700006-a1a5-4950-9fb9-094483e3c08e@github.com> On Fri, 8 Oct 2021 08:48:46 GMT, Vishal Chand wrote: >> src/hotspot/share/gc/shared/cardTable.hpp line 234: >> >>> 232: static uintx card_shift; >>> 233: static uintx card_size; >>> 234: static uintx card_size_in_words; >> >> Please do not use `uintx`; I think `uint` is just fine for those. > > I tried using uint, but card_size is being treated as a uintx everywhere in the code. So I'm observing compilation errors with uint. When trying this out, at least on Linux, I found just one (already ugly) cast that needs to be "improved", in g1CollectedHeap.cpp:1664: // The G1FromCardCache reserves card with value 0 as "invalid", so the heap must not // start within the first card. guarantee(heap_rs.base() >= (char*)(uintptr_t)G1CardTable::card_size, "Java heap must not start within the first card."); /// <--- here G1FromCardCache::initialize(max_reserved_regions()); Test branch at https://github.com/openjdk/jdk/compare/master...tschatzl:submit/5838-card-size-as-uint?expand=1 ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+16811675+linade at openjdk.java.net Fri Oct 8 10:20:08 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Fri, 8 Oct 2021 10:20:08 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v3] In-Reply-To: References: Message-ID: <_rdCVmTlYKnBWHKmngwLlOMoRKXAC5jUJLhMdRVMTFo=.c016c924-1bd8-425e-972f-6bec6f205c08@github.com> On Fri, 1 Oct 2021 11:52:50 GMT, Thomas Schatzl wrote: > G1 already uses so many threads, so adding more does not seem to be a good idea. Also, just one thread is going to be overwhelmed on large heaps, probably making the method less effective there where it is more necessary than in other cases. Maybe just fake cards to scan in the DCQS so that this work is done first (and always) by the refinement threads? Some tweaking of thread numbers and refinement threads is likely needed. This is a good point. I'll see if I can create some kind of fake refine tasks. After all real refine tasks and fake tasks do similar things like calling block_start() so it should be possible. > Not sure about whether the complexity for using the bitmap level as storage is worth the effort: in my testing I have never even come close to 512 PLABs per region. In that case (or even earlier), probably just bail out, drop the whole task and do nothing as with that many PLABs the amount of overlap during gc is likely to be small. I need to do some more testing and thinking about this though. Usually I observe small plabs (~2k in size) at the beginning of my specjbb tests. Maybe it's because the heuristics are yet to adjust the plab size. I guess my only concern is, if this is the case, we will find ourselves allocating a lot of large c-heap arrays, which might be bad for pause times. But I think bailing out is also a good choice, considering it simplifies the card set design a lot. > the G1BOTFixingCardSet in HeapRegion should at most be a pointer within HeapRegion: since only a small percentage of regions are ever affected by this, it seems a waste to always allocate memory for them, even if only little. Yes. Will change that. > Actually I have seen only mid single digit number of plabs per region whatever I have been running; so I even kind of think it might be useful to decrease the maximum PLAB size to have more of those so that more threads can work on these and the individual BOT fixup is faster (to abort faster). I have no particular guidance here at this time of how large is too large; but something like half or a third of a region for 32m regions is quite a bit to chew on :) This of course affects the storage needs, but this limit should always be so that we would never want to use the bitmap. I imagine imposing a max plab size will affect evacuation efficiency right? I'm not sure about how this weighs in.. > some potential renames to be done only when we are done evaluating this: rename this feature to G1ConcurrentBOTUpdate, not "fixing" :) Will change the name. > There is another option for storing whether this part of the BOT is unrefined yet: take a bit from the BOT values themselves to encode that. > I did not look whether this is actually possible with the current encoding, but is an option if that does not take away too much of the range of the backskip - at the moment we use the values 0-63 (*8 = 512) to encode the offsets within the card, all higher values are backskip values after all. > I.e. it might even be that extremely high backskip values which would not be used in all but huge arrays (if at all) are available for such a thing. > Just some weird idea that came to my mind... I think the backskip value is log_16(number_of_plabs_to_skip). So I don't think there is that big an array to require a large backskip value. A back_skip=4 with plab_size=512 means a 32m skip, already bigger than the biggest non-humongous object. So maybe the highest bit is always available. Nontheless, this mean we change a lot of BOT code. It becomes more complicated and slightly slower, e.g., when doing atomic updates to an entry, originally we do ``Atomic::store()`` and now we do a looped ``Atomic::cmpxchg()`` to preserve the special bit. Can we afford that? > Another minor optimization is that if we used the refinement information in some way, only update the BOT for areas that actually may ever be scanned - i.e. anything that is may be put into a remembered set. > > I.e. we might be promoting a lot of data that never needs to be scanned (because e.g. they reference almost only data within a region). > > Admittedly this is all just slinging ideas around and see if something sticks. I haven't looked at how this information is maintained and utilized before. Need to learn more about it. Thanks for another pointer :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Fri Oct 8 10:42:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 10:42:07 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 09:59:24 GMT, Thomas Schatzl wrote: >> **FLAG_SET_ERGO** is needed for G1 GC. In case of G1, min card size is determined by the region size. >> For the following cmdline arguments: -XX:G1HeapRegionSize=32M -XX:GCCardSizeInBytes=256 >> ---- card_size is ergonomically set to 512 instead of 256, as min. card size for 32M region is 512. > > Let's leave this question out for now: I am not sure it makes sense to allow a card size of 256; however the common reaction when specifying incompatible command line options would be to bail out. > The question is what to do if the user selects GCCardSizeInBytes=256 and G1 ergonomically decides to use 32m regions. Silently use 16m regions, which are very likely worse than 32m regions in that case? > That is why we should first determine if card size of 256 makes sense somewhere and then decide (or somebody else has a particular opinion on this). That same question will come up if we allow 64m regions later, but the step from 64->32m may not be that big. Another option would be to go away from the 1:1 mapping of cards in the remembered set and cards in the card table. This could probably be fixed, but is a completely different issue of course. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 11:06:09 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 11:06:09 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 10:39:06 GMT, Thomas Schatzl wrote: >> Let's leave this question out for now: I am not sure it makes sense to allow a card size of 256; however the common reaction when specifying incompatible command line options would be to bail out. >> The question is what to do if the user selects GCCardSizeInBytes=256 and G1 ergonomically decides to use 32m regions. Silently use 16m regions, which are very likely worse than 32m regions in that case? >> That is why we should first determine if card size of 256 makes sense somewhere and then decide (or somebody else has a particular opinion on this). > > That same question will come up if we allow 64m regions later, but the step from 64->32m may not be that big. Another option would be to go away from the 1:1 mapping of cards in the remembered set and cards in the card table. This could probably be fixed, but is a completely different issue of course. In this current implementation, with G1 GC, `card_size` is initialized after determining the `region_size` inside `setup_heap_region_size()`. `card_size` value is determined as `MAX(GCCardSizeInByte, minimum card size for the region size)`. So, if user selects `GCCardSizeInBytes=256` and G1 ergonomically decides to use 32M regions, `card_size` is silently set to 512b. And, if user selects `GCCardSizeInBytes=1024` and G1 ergonomically decides to use 32M regions, `card_size` stays at 1024b. In case user doesn't specify any card_size, default value of 512b is used. We can set it ergonomically, but thats a completely new problem. With Parallel and Serial GC, we directly use `GCCardSizeInBytes`, as there's no dependency. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From tschatzl at openjdk.java.net Fri Oct 8 11:22:10 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 11:22:10 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v3] In-Reply-To: <_rdCVmTlYKnBWHKmngwLlOMoRKXAC5jUJLhMdRVMTFo=.c016c924-1bd8-425e-972f-6bec6f205c08@github.com> References: <_rdCVmTlYKnBWHKmngwLlOMoRKXAC5jUJLhMdRVMTFo=.c016c924-1bd8-425e-972f-6bec6f205c08@github.com> Message-ID: On Fri, 8 Oct 2021 10:17:14 GMT, Yude Lin wrote: > > Not sure about whether the complexity for using the bitmap level as storage is worth the effort: in my testing I have never even come close to 512 PLABs per region. In that case (or even earlier), probably just bail out, drop the whole task and do nothing as with that many PLABs the amount of overlap during gc is likely to be small. I need to do some more testing and thinking about this though. > > Usually I observe small plabs (~2k in size) at the beginning of my specjbb tests. Maybe it's because the heuristics are yet to adjust the plab size. I guess my only concern is, if this is the case, we will find ourselves allocating a lot of large c-heap arrays, which might be bad for pause times. But I think bailing out is also a good choice, considering it simplifies the card set design a lot. That complexity reduction is the goal. Otherwise, just do a per-region bitmap: we are unlikely to expect a large part of the heap to be copied over at once, and even for the whole heap this would be (if I calculated correctly) around 0.02% of the heap (assuming it is worth doing). Particularly when recycling these bitmaps, allocation costs shouldn't be that bad either. > > Actually I have seen only mid single digit number of plabs per region whatever I have been running; so I even kind of think it might be useful to decrease the maximum PLAB size to have more of those so that more threads can work on these and the individual BOT fixup is faster (to abort faster). I have no particular guidance here at this time of how large is too large; but something like half or a third of a region for 32m regions is quite a bit to chew on :) This of course affects the storage needs, but this limit should always be so that we would never want to use the bitmap. > > I imagine imposing a max plab size will affect evacuation efficiency right? I'm not sure about how this weighs in.. Idk :) However in steady state the PLABs are expected to be quite large. > > There is another option for storing whether this part of the BOT is unrefined yet: take a bit from the BOT values themselves to encode that. > > I did not look whether this is actually possible with the current encoding, but is an option if that does not take away too much of the range of the backskip - at the moment we use the values 0-63 (*8 = 512) to encode the offsets within the card, all higher values are backskip values after all. > > I.e. it might even be that extremely high backskip values which would not be used in all but huge arrays (if at all) are available for such a thing. > > Just some weird idea that came to my mind... > > I think the backskip value is log_16(number_of_plabs_to_skip). So I don't think there is that big an array to require a large backskip value. A back_skip=4 with plab_size=512 means a 32m skip, already bigger than the biggest non-humongous object. So maybe the highest bit is always available. > > Nontheless, this mean we change a lot of BOT code. It becomes more complicated and slightly slower, e.g., when doing atomic updates to an entry, originally we do `Atomic::store()` and now we do a looped `Atomic::cmpxchg()` to preserve the special bit. Can we afford that? Idk since I did not measure, but it sounds so. Probably just an extra bitmap per region per card is better. Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Fri Oct 8 11:32:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 11:32:07 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 11:02:56 GMT, Vishal Chand wrote: >> That same question will come up if we allow 64m regions later, but the step from 64->32m may not be that big. Another option would be to go away from the 1:1 mapping of cards in the remembered set and cards in the card table. This could probably be fixed, but is a completely different issue of course. > > In this current implementation, with G1 GC, `card_size` is initialized after determining the `region_size` inside `setup_heap_region_size()`. `card_size` value is determined as `MAX(GCCardSizeInByte, minimum card size for the region size)`. So, if user selects `GCCardSizeInBytes=256` and G1 ergonomically decides to use 32M regions, `card_size` is silently set to 512b. And, if user selects `GCCardSizeInBytes=1024` and G1 ergonomically decides to use 32M regions, `card_size` stays at 1024b. In case user doesn't specify any card_size, default value of 512b is used. We can set it ergonomically, but thats a completely new problem. > With Parallel and Serial GC, we directly use `GCCardSizeInBytes`, as there's no dependency. I understand the code, but the problems are elsewhere: * this restriction is G1 only, but the code handling this situation is in common code (in the common `cardTable.cpp`, not in e.g. `g1CardTable*`). I do not have an extremely strong opinion about this at the moment. * the code overrides a user decision _silently_, which is not a good idea imho. The typical solution is that other settings that the user did not explicitly specified try to adapt to these. However in this case, doing that would be in almost all cases disadvantageous (I guess). Let's see what other people think about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From kbarrett at openjdk.java.net Fri Oct 8 11:49:07 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 8 Oct 2021 11:49:07 GMT Subject: RFR: 8274927: Remove unnecessary G1ArchiveAllocator code In-Reply-To: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> References: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> Message-ID: On Fri, 8 Oct 2021 07:14:08 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that removes code that is fairly trivially recognizable as useless? > > The `_archive_allocator` is always freed after use (see `HeapShared::copy_closed/open_objects`), so it must always be `nullptr` when it's accessed outside the CDS dump code. > I kept the asserts in the original places, but idk if that is really necessary. > > Testing: tier1-5 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5861 From mli at openjdk.java.net Fri Oct 8 12:16:07 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 8 Oct 2021 12:16:07 GMT Subject: RFR: 8274466 G1: use field directly rather than method in G1CollectorState::in_mixed_phase [v2] In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 01:34:28 GMT, Hamlin Li wrote: >> This is a minor improvement which remove the redundant G1 Collector states usages. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Revert wrong code Thanks Albert. Agree, the change gets more simple than expected after Stefan's review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5745 From mdoerr at openjdk.java.net Fri Oct 8 12:38:12 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 8 Oct 2021 12:38:12 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 08:27:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: > > - Update autoconf error message > - Remove copyright headers Nice contribution! Thanks for doing the changes I had requested during my offline review. New version needs a few minor fixes, but looks great in general. src/hotspot/cpu/ppc/ppc.ad line 8142: > 8140: match(Set res (CompareAndExchangeP mem_ptr (Binary src1 src2))); > 8141: predicate((((CompareAndSwapNode*)n)->order() != MemNode::acquire && ((CompareAndSwapNode*)n)->order() != MemNode::seqcst) > 8142: && n->as_Load()->barrier_data() == 0); Needs to be `as_LoadStore()`. src/hotspot/cpu/ppc/ppc.ad line 8157: > 8155: match(Set res (CompareAndExchangeP mem_ptr (Binary src1 src2))); > 8156: predicate((((CompareAndSwapNode*)n)->order() == MemNode::acquire || ((CompareAndSwapNode*)n)->order() == MemNode::seqcst) > 8157: && n->as_Load()->barrier_data() == 0); Needs to be `as_LoadStore()`. src/hotspot/cpu/ppc/ppc.ad line 8379: > 8377: instruct getAndSetP(iRegPdst res, iRegPdst mem_ptr, iRegPsrc src, flagsRegCR0 cr0) %{ > 8378: match(Set res (GetAndSetP mem_ptr src)); > 8379: predicate(n->as_Load()->barrier_data() == 0); Needs to be `as_LoadStore()`. ------------- Changes requested by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5842 From tschatzl at openjdk.java.net Fri Oct 8 12:52:08 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 12:52:08 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: Message-ID: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> On Thu, 7 Oct 2021 11:04:09 GMT, Thomas Schatzl wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > src/hotspot/share/gc/g1/heapRegion.cpp line 96: > >> 94: // Initialize card size based on the region size. >> 95: // Maximum no. of cards per region is 2^16. >> 96: CardTable::initialize_card_size(1 << (region_size_log - 16)); > > Please make a constant out of the `16`; the reason is the size of the `G1CardSetArray::EntryDataType` being 16 bit. Another question we need to answer is whether smaller card size than 512 gains anything - if not, I recommend keeping to use 512 at minimum, as otherwise the card table will obviously use much more memory for no gain. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From ayang at openjdk.java.net Fri Oct 8 12:57:11 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 8 Oct 2021 12:57:11 GMT Subject: RFR: 8274927: Remove unnecessary G1ArchiveAllocator code In-Reply-To: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> References: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> Message-ID: On Fri, 8 Oct 2021 07:14:08 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that removes code that is fairly trivially recognizable as useless? > > The `_archive_allocator` is always freed after use (see `HeapShared::copy_closed/open_objects`), so it must always be `nullptr` when it's accessed outside the CDS dump code. > I kept the asserts in the original places, but idk if that is really necessary. > > Testing: tier1-5 The change looks good. Since `_archive_allocator` is often null, I wonder if this means the field should be moved to another place. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5861 From tschatzl at openjdk.java.net Fri Oct 8 13:00:34 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 13:00:34 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? > > The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). > > The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). > > This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. > > There are three interesting changes: > * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. > * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. > * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). > > Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times > > 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/5786/files - new: https://git.openjdk.java.net/jdk/pull/5786/files/d9e8d956..3cebd394 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=01-02 Stats: 7 lines in 1 file changed: 1 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5786/head:pull/5786 PR: https://git.openjdk.java.net/jdk/pull/5786 From tschatzl at openjdk.java.net Fri Oct 8 13:07:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 13:07:07 GMT Subject: RFR: 8274927: Remove unnecessary G1ArchiveAllocator code In-Reply-To: References: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> Message-ID: <6uyTkE9OglzHGWaWfeA4FnUaTyQ1Wasy4PYdOpHw9oM=.3f4bd9c3-b53b-4909-bde2-0e0baa1ceff0@github.com> On Fri, 8 Oct 2021 12:53:49 GMT, Albert Mingkun Yang wrote: > The change looks good. Since `_archive_allocator` is often null, I wonder if this means the field should be moved to another place. That has been my initial reaction too when I noticed this. However there is no really good place. In a discussion with @iklam he suggested `ArchiveBuilder`, but before experimenting with that (it does not seem perfect either, particularly because this would require lots of ifdef-ing in builds without G1) I thought this change was good enough to stand on its own. Thanks @albertnetymk and @kimbarrett for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5861 From zgu at openjdk.java.net Fri Oct 8 13:49:18 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 8 Oct 2021 13:49:18 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check Message-ID: JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/5865/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5865&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274925 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5865/head:pull/5865 PR: https://git.openjdk.java.net/jdk/pull/5865 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 14:26:12 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 14:26:12 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> References: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> Message-ID: On Fri, 8 Oct 2021 12:49:32 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/heapRegion.cpp line 96: >> >>> 94: // Initialize card size based on the region size. >>> 95: // Maximum no. of cards per region is 2^16. >>> 96: CardTable::initialize_card_size(1 << (region_size_log - 16)); >> >> Please make a constant out of the `16`; the reason is the size of the `G1CardSetArray::EntryDataType` being 16 bit. > > Another question we need to answer is whether smaller card size than 512 gains anything - if not, I recommend keeping to use 512 at minimum, as otherwise the card table will obviously use much more memory for no gain. I'm trying to identify the usecases where we can see better performance with small card sizes. Right now, I have none. So, I'll set the minimum card size to 512 right now. Intention is to have a design such that if someone finds a usecase which gives better performance with smaller cards, only the minimum card size needs to be changed in the code, nothing else. Shall I keep this current behavior of overriding card_size based on region size till there's some feedback from others? or Do I need to change this? ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From eosterlund at openjdk.java.net Fri Oct 8 15:03:06 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 8 Oct 2021 15:03:06 GMT Subject: RFR: 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform In-Reply-To: References: Message-ID: <5MvlD693ypnPYigEOGRR2xzHTZ-mYFKZKjPSy0_lcOs=.187455c9-00e5-4abe-8c5d-a746195ca0e2@github.com> On Tue, 5 Oct 2021 12:27:05 GMT, Martin Doerr wrote: > The test creates new Nodes and publishes them to concurrent readers. This requires at least release and load_consume. A clean fix would be to make `Node.next` volatile. But that would be a sledgehammer. A minimalistic fix for our supported weak memory model platforms is to insert a `storeFence`. What is better? > (See JBS for failure description.) Yeah I have the same fix in the generational ZGC repository. Got bitten by the same issue and used the same solution. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5823 From eosterlund at openjdk.java.net Fri Oct 8 15:22:10 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 8 Oct 2021 15:22:10 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 08:27:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: > > - Update autoconf error message > - Remove copyright headers Thank you for contributing a ZGC port to PPC. Apart from what has already been said, this looks good to me. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5842 From tschatzl at openjdk.java.net Fri Oct 8 15:37:15 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 15:37:15 GMT Subject: RFR: 8272773: Investigate making card table size configurable In-Reply-To: References: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> Message-ID: <0yrT7cXU8JFAi89--wVTGOMYqVAtCxaKb25hJqcEdvk=.924ebf97-a614-40f9-9f96-49afde46261c@github.com> On Fri, 8 Oct 2021 14:23:14 GMT, Vishal Chand wrote: >> Another question we need to answer is whether smaller card size than 512 gains anything - if not, I recommend keeping to use 512 at minimum, as otherwise the card table will obviously use much more memory for no gain. > > I'm trying to identify the usecases where we can see better performance with small card sizes. Right now, I have none. So, I'll set the minimum card size to 512 right now. Intention is to have a design such that if someone finds a usecase which gives better performance with smaller cards, only the minimum card size needs to be changed in the code, nothing else. Shall I keep this current behavior of overriding card_size based on region size till there's some feedback from others? or Do I need to change this? Let's keep the minimum card size to 512 for now, this can be investigated further separately. As you said, this can be changed easily. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From nradomski at openjdk.java.net Fri Oct 8 15:41:51 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Fri, 8 Oct 2021 15:41:51 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v2] In-Reply-To: References: Message-ID: On Thu, 7 Oct 2021 13:54:16 GMT, Per Liden wrote: >> Niklas Radomski has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update autoconf error message >> - Remove copyright headers > > src/hotspot/share/gc/z/zBarrierSetAssembler.cpp line 30: > >> 28: >> 29: Address ZBarrierSetAssemblerBase::address_bad_mask_from_thread(Register thread) { >> 30: return Address(thread, (intptr_t) ZThreadLocalData::address_bad_mask_offset()); > > Instead of casting here in this platform agnostic code, I'd suggest that you add a new constructor for `Address` on PPC, one that takes `(Register, ByteSize)` arguments. Other platforms have that, so I'm a bit surprised that PPC doesn't already have that too. Good catch, thank you for the suggestion! Totally agreed, I changed it accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From nradomski at openjdk.java.net Fri Oct 8 15:41:47 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Fri, 8 Oct 2021 15:41:47 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v3] In-Reply-To: References: Message-ID: > Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. Niklas Radomski has updated the pull request incrementally with three additional commits since the last revision: - Remove superfluous copyright change - Fix predicate conditions - Add ByteSize constructor to Address ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5842/files - new: https://git.openjdk.java.net/jdk/pull/5842/files/5da8c1b7..052ad5c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5842&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5842&range=01-02 Stats: 9 lines in 3 files changed: 3 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5842.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5842/head:pull/5842 PR: https://git.openjdk.java.net/jdk/pull/5842 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 16:52:32 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 16:52:32 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v2] In-Reply-To: References: Message-ID: > Hi, > > Please review the changes to make CardTable entry size configurable. The changes primarily consists of: > > 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. > 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. > 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. Vishal Chand has updated the pull request incrementally with one additional commit since the last revision: Changes as per the first set of comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5838/files - new: https://git.openjdk.java.net/jdk/pull/5838/files/c9d5203f..83062219 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=00-01 Stats: 63 lines in 12 files changed: 34 ins; 8 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/5838.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838 PR: https://git.openjdk.java.net/jdk/pull/5838 From zgu at openjdk.java.net Fri Oct 8 16:55:26 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 8 Oct 2021 16:55:26 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests Message-ID: I were able to reproduce with aggressive heuristics. While a _wb_breakpoint GC request , at the moment a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. The solution is only run breakpoints during _wb_breakpoint GC. Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. Test: - [x] tier1 with Shenandoah ------------- Commit messages: - Order requested gc cause and gc requested flag - Merge branch 'master' into JDK-8273614-conbkptr-timeout - v1 - Merge branch 'master' into JDK-8273614-conbkptr-timeout - Merge branch 'master' into JDK-8273614-conbkptr-timeout - use wait - Merge branch 'master' into JDK-8273614-conbkptr-timeout - Merge branch 'master' into TestJNIWeak-timeout - v0 Changes: https://git.openjdk.java.net/jdk/pull/5868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273614 Stats: 29 lines in 2 files changed: 16 ins; 4 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/5868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5868/head:pull/5868 PR: https://git.openjdk.java.net/jdk/pull/5868 From tschatzl at openjdk.java.net Fri Oct 8 17:08:11 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 8 Oct 2021 17:08:11 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v2] In-Reply-To: <0yrT7cXU8JFAi89--wVTGOMYqVAtCxaKb25hJqcEdvk=.924ebf97-a614-40f9-9f96-49afde46261c@github.com> References: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> <0yrT7cXU8JFAi89--wVTGOMYqVAtCxaKb25hJqcEdvk=.924ebf97-a614-40f9-9f96-49afde46261c@github.com> Message-ID: On Fri, 8 Oct 2021 15:34:04 GMT, Thomas Schatzl wrote: >> I'm trying to identify the usecases where we can see better performance with small card sizes. Right now, I have none. So, I'll set the minimum card size to 512 right now. Intention is to have a design such that if someone finds a usecase which gives better performance with smaller cards, only the minimum card size needs to be changed in the code, nothing else. Shall I keep this current behavior of overriding card_size based on region size till there's some feedback from others? or Do I need to change this? > > Let's keep the minimum card size to 512 for now, this can be investigated further separately. As you said, this can be changed easily. Also please do not scale card table entry size with region size - there are some applications (many references, large remembered sets; e.g. the one in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438)) that with a 1024 card table size show 30% longer pause times. (Actually, they benefit a lot from smaller card table entry size, i.e. they get around the same pause time improvement with e.g. 256 byte sized card table entry size if heap region size permits). ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From pliden at openjdk.java.net Fri Oct 8 17:14:08 2021 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 8 Oct 2021 17:14:08 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with three additional commits since the last revision: > > - Remove superfluous copyright change > - Fix predicate conditions > - Add ByteSize constructor to Address Marked as reviewed by pliden (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From github.com+10235864+vish-chan at openjdk.java.net Fri Oct 8 20:16:45 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Fri, 8 Oct 2021 20:16:45 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: References: Message-ID: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> > Hi, > > Please review the changes to make CardTable entry size configurable. The changes primarily consists of: > > 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. > 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. > 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable - Changes as per the first set of comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5838/files - new: https://git.openjdk.java.net/jdk/pull/5838/files/83062219..c9c8db81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5838&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5838.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5838/head:pull/5838 PR: https://git.openjdk.java.net/jdk/pull/5838 From manc at google.com Fri Oct 8 22:19:04 2021 From: manc at google.com (Man Cao) Date: Fri, 8 Oct 2021 15:19:04 -0700 Subject: RFR: 8274178: Occupancy value in logging and JFR event is inaccurate in G1IHOPControl In-Reply-To: <3190eb70-7402-23cb-c9c8-4071740a4816@oracle.com> References: <3190eb70-7402-23cb-c9c8-4071740a4816@oracle.com> Message-ID: Do we want to rename the wording "current occupancy" and "occupancy" in logging to something else? If we keep them as G1CollectedHeap::heap()->used(), it is inconsistent with the other logging message in G1Policy::need_to_start_conc_mark(): bool G1Policy::need_to_start_conc_mark(const char* source, size_t alloc_word_size) { ... size_t cur_used_bytes = _g1h->non_young_capacity_bytes(); ... if (marking_request_bytes > marking_initiating_used_threshold) { ... log_debug(gc, ergo, ihop)("%s occupancy: " SIZE_FORMAT "B allocation request: " SIZE_FORMAT "B threshold: " SIZE_FORMAT "B (%1.2f) source: %s", result ? "Request concurrent cycle initiation (occupancy higher than threshold)" : "Do not request concurrent cycle initiation (still doing mixed collections)", cur_used_bytes, alloc_byte_size, marking_initiating_used_threshold, (double) marking_initiating_used_threshold / _g1h->capacity() * 100, source); } } The "occupancy" value in this message is already non_young_capacity_bytes(). Also, if we report both heap()->used() and non_young_capacity_bytes() in log, which value should we use for "current_occupancy" in G1NewTracer::report_basic_ihop_statistics() and G1NewTracer::report_adaptive_ihop_statistics()? -Man On Thu, Oct 7, 2021 at 11:17 PM Thomas Schatzl wrote: > Hi, > > On 08.10.21 01:08, Jonathan Joo wrote: > > Hi Thomas, > > > > Thanks for taking a look! I just wanted to clarify what you meant from > your > > message - for the field that I'm replacing ("occupancy"), are you saying > > that we do indeed want to look at the total used heap space, even though > > get_conc_mark_start_threshold() is depending on the non_young occupancy > > bytes? In other words, the actual_target values being logged are related > to > > heap()->used(), while the get_conc_mark_start_threshold() values are > > related to non_young_capacity_bytes()? > > > > If so, would an appropriate change be something like keeping the original > > code, but adding a single new field in the debug message after > "threshold" > > with something like: "non-young usage (compared against threshold): " + > > G1CollectedHeap::heap()->non_young_capacity_bytes()? > > Yes, that's what I suggested. > > Thanks, > Thomas > From mli at openjdk.java.net Sat Oct 9 02:01:12 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 02:01:12 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:37:10 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator >> - Rename Xxx to G1Xxx >> - Clean code >> - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums >> - Initial commit > > src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 84: > >> 82: } >> 83: >> 84: const char* start() const { return _buffer; } > > I would prefer a `copy_to` method instead of exposing the raw buffer pointer; this is the only use in the follow-up code. That method is in this case better added in that change to highlight it. delete this code in this change, will add it in next change. > src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 213: > >> 211: template >> 212: void iterate_nodes(Visitor& v); >> 213: }; > > These seem to be new. Please introduce them in the next change. These introductions of new functionality when factoring out code makes it really hard to review (or at least harder than necessary). > The reason I'm saying this is because such additions makes at least me suspicious of what else has been added and changed, resulting in extra effort to look through *everything* again - particularly if the author did not mention that this or that has been added (beyond what is necessary to make things work again). > Which in turn makes reviews like this less appealing to do (they are typically boring - we probably prefer "boring" reviews :) ) because of the obvious extra effort. delete this code in this change, will add it in next change. > src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 130: > >> 128: template >> 129: G1SegmentedArrayBuffer* G1SegmentedArray::create_new_buffer( >> 130: G1SegmentedArrayBuffer* const prev) { > > I think it is still okay to put the parameter on the previous line. Seems it''s too long for me, but modified as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Sat Oct 9 03:07:11 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 03:07:11 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: <80PfLja0mqNmHEHAhXoew5oZ9ErsauJu2Q5eu0vX9yY=.379b6d19-12e6-4bf1-bc01-9e23a78b294b@github.com> On Fri, 8 Oct 2021 09:26:45 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator >> - Rename Xxx to G1Xxx >> - Clean code >> - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums >> - Initial commit > > src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 99: > >> 97: // memory. >> 98: template >> 99: class G1CardSetAllocator : public G1SegmentedArray { > > I think a `G1CardSetAllocator` *has* or *uses* a `G1SegmentedArray`, but itself is not. I.e. this does not seem to be a proper is-a relation, so the subclassing here seems wrong. > Adding a member of that type and using it seems better to me. Agree! ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Sat Oct 9 03:22:09 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 03:22:09 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 09:37:42 GMT, Thomas Schatzl wrote: > > > Current(original) implementation just drop the newly allocated G1SegmentedArrayBuffer if current thread fails, seems it's fine as the race should be rare, should we add the faield one to free list? seems adding to freelist will bring some benefit. > > > > > > Yes, that's also what `G1CardSetAllocator` does. At least there, the race isn't that rare. > > You need to consider that as soon there are (real, not just faked ones) evacuation failures, all subsequent allocations of potentially all threads will fail. The segmented array somewhat deals with that by increasing the buffer size, and potentially you are not always failing in the same region... Agree. I've filed https://bugs.openjdk.java.net/browse/JDK-8274987 to track the enhancement, will work on it soon after we finish refactoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Sat Oct 9 03:35:14 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 03:35:14 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 07:59:03 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator >> - Rename Xxx to G1Xxx >> - Clean code >> - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums >> - Initial commit > > src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 146: > >> 144: >> 145: G1SegmentedArrayAllocOptions(uint elem_size, uint initial_num_elems = MinimumBufferSize, >> 146: uint max_num_elems = MaximumBufferSize, uint alignment = BufferAlignment) : > > Now that this class is going to be used in multiple contexts, I would prefer if the defaults (and default values) would be removed and added at the place of use. > Just add an empty constructor that sets this to bogus values (zeros probably), and check that these are set in eg. `next_num_elems`. > > Alternatively delay this suggested change to the next and change back the value of `BufferAlignment` which I'd actually prefer. I've filed https://bugs.openjdk.java.net/browse/JDK-8274988 to track the issue, will work on it soon after we finish refactoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Sat Oct 9 03:53:35 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 03:53:35 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: > To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. > > This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5478/files - new: https://git.openjdk.java.net/jdk/pull/5478/files/0088b53f..69d7007e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=02-03 Stats: 131 lines in 5 files changed: 35 ins; 76 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/5478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5478/head:pull/5478 PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Sat Oct 9 03:57:07 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 03:57:07 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 03:53:35 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code Thanks Thomas for the detailed review, I have modified as suggested and file issues to track the later work. https://bugs.openjdk.java.net/browse/JDK-8274988 https://bugs.openjdk.java.net/browse/JDK-8274987 https://bugs.openjdk.java.net/browse/JDK-8254739?focusedCommentId=14451862&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14451862 ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Sat Oct 9 08:58:13 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Sat, 9 Oct 2021 08:58:13 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 03:53:35 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code I almost missed https://bugs.openjdk.java.net/browse/JDK-8274993, as I can not see the message in this github PR page. ( should this be a bug of the infrastrucuture? ) ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From github.com+16811675+linade at openjdk.java.net Sat Oct 9 10:05:07 2021 From: github.com+16811675+linade at openjdk.java.net (Yude Lin) Date: Sat, 9 Oct 2021 10:05:07 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: > A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). > > What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. Yude Lin has updated the pull request incrementally with four additional commits since the last revision: - Fixed a bug in array claim - Fixed a bug that causes premature deactivate - Renaming variables - Renaming ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5039/files - new: https://git.openjdk.java.net/jdk/pull/5039/files/79ebe0a2..1fc721f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5039&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5039&range=02-03 Stats: 2278 lines in 25 files changed: 1105 ins; 1103 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/5039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5039/head:pull/5039 PR: https://git.openjdk.java.net/jdk/pull/5039 From goetz at openjdk.java.net Sat Oct 9 12:05:12 2021 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Sat, 9 Oct 2021 12:05:12 GMT Subject: RFR: 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 12:27:05 GMT, Martin Doerr wrote: > The test creates new Nodes and publishes them to concurrent readers. This requires at least release and load_consume. A clean fix would be to make `Node.next` volatile. But that would be a sledgehammer. A minimalistic fix for our supported weak memory model platforms is to insert a `storeFence`. What is better? > (See JBS for failure description.) LGTM ------------- Marked as reviewed by goetz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5823 From github.com+10235864+vish-chan at openjdk.java.net Sun Oct 10 12:34:16 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Sun, 10 Oct 2021 12:34:16 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: References: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> <0yrT7cXU8JFAi89--wVTGOMYqVAtCxaKb25hJqcEdvk=.924ebf97-a614-40f9-9f96-49afde46261c@github.com> Message-ID: <3TS03qvLOG6SzWXQzxw1mpVukud9sQWaJGRbbhVL1Ro=.6dca6a20-e0ee-4003-8351-25d95e598d53@github.com> On Fri, 8 Oct 2021 17:05:32 GMT, Thomas Schatzl wrote: >> Let's keep the minimum card size to 512 for now, this can be investigated further separately. As you said, this can be changed easily. > > Also please do not scale card table entry size with region size - there are some applications (many references, large remembered sets; e.g. the one in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438)) that with a 1024 card table size show 30% longer pause times. (Actually, they benefit a lot from smaller card table entry size, i.e. they get around the same pause time improvement with e.g. 256 byte sized card table entry size if heap region size permits). Currently I'm not scaling card size with region size, as it is not required. With current supported region sizes (1M to 32M) and card sizes (512b, 1024B), all the possible combinations of region size and card size are valid combinations. If we include 256b cards or 64M regions, then invalid combinations will be there which would need to be handled. Do you think that code/logic is needed now, or we can add if and when needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+10235864+vish-chan at openjdk.java.net Sun Oct 10 12:49:11 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Sun, 10 Oct 2021 12:49:11 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: References: Message-ID: <7eF9S2sjutg9hqwMrTD3lGFukLANxHuYwc5iiTlnLNA=.d839fa3f-fa96-4b52-80eb-630915a8e549@github.com> On Thu, 7 Oct 2021 11:13:14 GMT, Thomas Schatzl wrote: >> Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable >> - Changes as per the first set of comments > > src/hotspot/share/gc/shared/cardTable.cpp line 468: > >> 466: uintx CardTable::ct_max_alignment_constraint() { >> 467: // CardTable max alignment is computed with card_size_max >> 468: return card_size_max * os::vm_page_size(); > > I think this change causes some tests to fail because their heap will get too large. Maybe it is possible to move code so that the actual card size value is used here to avoid this, or fix the errors (will be visible with enabled github actions). I don't see any errors after enabling the tests via github actions. Am I missing something here? ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From pliden at openjdk.java.net Mon Oct 11 09:09:10 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 11 Oct 2021 09:09:10 GMT Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v3] In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 08:54:02 GMT, ?? wrote: >> Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage. >> >> The following is the result of specjbb2015 after applying the patch (the tests turn off the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%. >> >> patch: >> [2021-09-18T13:11:51.736+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 373.180 / 569.855 275.312 / 569.855 275.312 / 569.855 ms >> [2021-09-18T15:30:07.168+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 381.266 / 577.812 277.272 / 577.812 277.272 / 577.812 ms >> [2021-09-18T17:37:56.305+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 345.037 / 494.135 259.497 / 506.815 259.497 / 506.815 ms >> >> >> origin: >> [2021-09-18T01:01:32.897+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 429.099 / 662.120 327.213 / 759.723 327.213 / 759.723 ms >> [2021-09-18T03:11:10.433+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 413.014 / 613.035 307.625 / 613.035 307.625 / 613.035 ms >> [2021-09-18T05:21:12.743+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 411.745 / 642.242 308.986 / 642.242 308.986 / 642.242 ms > > ?? has updated the pull request incrementally with one additional commit since the last revision: > > Change to version provided by per lidan src/hotspot/share/gc/z/zRelocate.cpp line 161: > 159: private: > 160: volatile size_t _in_place_count; > 161: ZPerWorker> _empty_pages; You're right that `_empty_pages` needs to be worker local (or protected by a lock). However, you can't use `ZPerWorker` like you do here, since you would be allocating a new worker local storage every time we do relocation. A `ZPerWorker` instance is semi-static, i.e. can only be initialized once and it will never deallocated its backing storage. ------------- PR: https://git.openjdk.java.net/jdk/pull/5670 From mdoerr at openjdk.java.net Mon Oct 11 10:35:19 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 11 Oct 2021 10:35:19 GMT Subject: Integrated: 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 12:27:05 GMT, Martin Doerr wrote: > The test creates new Nodes and publishes them to concurrent readers. This requires at least release and load_consume. A clean fix would be to make `Node.next` volatile. But that would be a sledgehammer. A minimalistic fix for our supported weak memory model platforms is to insert a `storeFence`. What is better? > (See JBS for failure description.) This pull request has now been integrated. Changeset: 49f8ce6e Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/49f8ce6e9c797cd11ea586e3cf87398888bc8cf1 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform Reviewed-by: eosterlund, goetz ------------- PR: https://git.openjdk.java.net/jdk/pull/5823 From mdoerr at openjdk.java.net Mon Oct 11 10:35:18 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 11 Oct 2021 10:35:18 GMT Subject: RFR: 8274773: [TESTBUG] UnsafeIntrinsicsTest intermittently fails on weak memory model platform In-Reply-To: References: Message-ID: On Tue, 5 Oct 2021 12:27:05 GMT, Martin Doerr wrote: > The test creates new Nodes and publishes them to concurrent readers. This requires at least release and load_consume. A clean fix would be to make `Node.next` volatile. But that would be a sledgehammer. A minimalistic fix for our supported weak memory model platforms is to insert a `storeFence`. What is better? > (See JBS for failure description.) Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/5823 From shade at openjdk.java.net Mon Oct 11 10:47:23 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 10:47:23 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 16:47:07 GMT, Zhengyu Gu wrote: > I were able to reproduce with aggressive heuristics. > > A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. > > The solution is only run breakpoints during _wb_breakpoint GC. > > Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. > > Test: > > - [x] tier1 with Shenandoah Looks good with minor nits. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 54: > 52: class ShenandoahBreakpointGCScope : public StackObj { > 53: private: > 54: GCCause::Cause _cause; Better be `const`? src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 72: > 70: class ShenandoahBreakpointMarkScope : public StackObj { > 71: private: > 72: GCCause::Cause _cause; Also `const`? src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 509: > 507: while (current_gc_id < required_gc_id) { > 508: _requested_gc_cause = cause; > 509: _gc_requested.set(); Ah. This whole thing is under _gc_waiters_lock. But there is a raw read of `_requested_gc_cause` and `_gc_requested` in `ShenandoahControlThread::run_service`. Pity. Could you please fork it out as separate (more backportable) bug? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5868 From shade at openjdk.java.net Mon Oct 11 10:49:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 10:49:10 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu wrote: > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah Hold on a sec, I have questions... I see `MultiArray_lock` is `safepoint`. Shouldn't this be `safepoint - 1` then? I think this would basically say "you can acquire any `safepoint` lock", right? Also, does the same thing apply to `_gc_waiters_lock`? Changing both locks to `safepoint - 1` passes `hotspot_gc_shenandoah` for me here. ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From thomas.schatzl at oracle.com Mon Oct 11 11:25:19 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 11 Oct 2021 13:25:19 +0200 Subject: RFR: 8274178: Occupancy value in logging and JFR event is inaccurate in G1IHOPControl In-Reply-To: References: <3190eb70-7402-23cb-c9c8-4071740a4816@oracle.com> Message-ID: Hi, On 09.10.21 00:19, Man Cao wrote: > Do we want to rename the wording "current occupancy" and "occupancy" in > logging to something else? If we keep them as > G1CollectedHeap::heap()->used(), it is inconsistent with the other > logging message in G1Policy::need_to_start_conc_mark(): > > bool G1Policy::need_to_start_conc_mark(const char* source, size_t > alloc_word_size) { > ? ... > ? size_t cur_used_bytes = _g1h->non_young_capacity_bytes(); > ? ... > ? if (marking_request_bytes > marking_initiating_used_threshold) { > ? ? ... > ? ? log_debug(gc, ergo, ihop)("%s occupancy: " SIZE_FORMAT "B > allocation request: " SIZE_FORMAT "B threshold: " SIZE_FORMAT "B (%1.2f) > source: %s", > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? result ? "Request concurrent cycle > initiation (occupancy higher than threshold)" : "Do not request > concurrent cycle initiation (still doing mixed collections)", > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? cur_used_bytes, alloc_byte_size, > marking_initiating_used_threshold, (double) > marking_initiating_used_threshold / _g1h->capacity() * 100, source); > ? } > } > > The "occupancy" value in this message is already non_young_capacity_bytes(). > > Also, if we report both heap()->used() and non_young_capacity_bytes() in > log, which value should we use for "current_occupancy" in > G1NewTracer::report_basic_ihop_statistics() and > G1NewTracer::report_adaptive_ihop_statistics()? > just fix it elsewhere as well, as well adding the field to the JFR events. JFR recordings are self-describing, so this should not be an issue wrt to backwards compatibility for future recordings. Thanks, Thomas From tschatzl at openjdk.java.net Mon Oct 11 11:50:17 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Oct 2021 11:50:17 GMT Subject: RFR: 8274927: Remove unnecessary G1ArchiveAllocator code In-Reply-To: References: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> Message-ID: On Fri, 8 Oct 2021 12:53:49 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> can I have reviews for this change that removes code that is fairly trivially recognizable as useless? >> >> The `_archive_allocator` is always freed after use (see `HeapShared::copy_closed/open_objects`), so it must always be `nullptr` when it's accessed outside the CDS dump code. >> I kept the asserts in the original places, but idk if that is really necessary. >> >> Testing: tier1-5 > > The change looks good. Since `_archive_allocator` is often null, I wonder if this means the field should be moved to another place. Thanks @albertnetymk @kimbarrett for your reviews ------------- PR: https://git.openjdk.java.net/jdk/pull/5861 From tschatzl at openjdk.java.net Mon Oct 11 11:50:18 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Oct 2021 11:50:18 GMT Subject: Integrated: 8274927: Remove unnecessary G1ArchiveAllocator code In-Reply-To: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> References: <708tizJhdyPaV6aZ6q2qXKtfRR1eTTJ8WnQfWaGGeUs=.2c89106d-05ac-42a4-a03b-a72d13de10ca@github.com> Message-ID: <0V2QeuBtXS5944-h7bcj3aT24ihEKHQPLk6oo1xYhKw=.5a692dff-423f-4dc8-b813-6253ee1c2b49@github.com> On Fri, 8 Oct 2021 07:14:08 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that removes code that is fairly trivially recognizable as useless? > > The `_archive_allocator` is always freed after use (see `HeapShared::copy_closed/open_objects`), so it must always be `nullptr` when it's accessed outside the CDS dump code. > I kept the asserts in the original places, but idk if that is really necessary. > > Testing: tier1-5 This pull request has now been integrated. Changeset: aaf2401b Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/aaf2401bc7d766dee5ffc623db86c4723c7e3760 Stats: 36 lines in 3 files changed: 0 ins; 26 del; 10 mod 8274927: Remove unnecessary G1ArchiveAllocator code Reviewed-by: kbarrett, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5861 From tschatzl at openjdk.java.net Mon Oct 11 11:51:19 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Oct 2021 11:51:19 GMT Subject: RFR: 8274430: Remove some debug error printing code added in JDK-8017163 In-Reply-To: References: Message-ID: <5BYMyVdMRMB5Gv-diu8cqmchmpmqqRPxW0QTQgVgN_Q=.27dee842-1e16-4c8a-95fd-0674d2b7bb67@github.com> On Wed, 29 Sep 2021 12:43:47 GMT, Stefan Johansson wrote: >> Hi all, >> >> can I have reviews for this change that undoes some logging changes from JDK-8017163, in particular it added the `XXX card set` lines in the output as shown in an example below: >> >> ``` [171.616s][1632757560415ms][error][gc,verify ] GC(129) Missing rem set entry: >> [171.616s][1632757560415ms][error][gc,verify ] GC(129) Field 0x00000007fb1008f0 of obj 0x00000007fb1008d8 in region 1485:(O)[0x00000007fb000000,0x00000 >> [171.616s][1632757560415ms][error][gc,verify ] GC(129) NULL card setjava.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry >> [...] >> points to obj 0x00000004d9abd4c8 in region 683:(S)[0x00000004d9000000,0x00000004da000000,0x00000004da000000] remset Complete >> >> >> This string would indicate which card set container does not have the requested remembered set entry. This is unnecessary information, as the "points to obj" string later shows that there should be a remset to this region already, and otherwise only interesting for debugging. >> >> Testing: gha >> >> Thanks, >> Thomas > > Looks good. Thanks @kstefanj @albertnetymk for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5733 From tschatzl at openjdk.java.net Mon Oct 11 11:51:20 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Oct 2021 11:51:20 GMT Subject: Integrated: 8274430: Remove some debug error printing code added in JDK-8017163 In-Reply-To: References: Message-ID: On Tue, 28 Sep 2021 08:59:23 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that undoes some logging changes from JDK-8017163, in particular it added the `XXX card set` lines in the output as shown in an example below: > > ``` [171.616s][1632757560415ms][error][gc,verify ] GC(129) Missing rem set entry: > [171.616s][1632757560415ms][error][gc,verify ] GC(129) Field 0x00000007fb1008f0 of obj 0x00000007fb1008d8 in region 1485:(O)[0x00000007fb000000,0x00000 > [171.616s][1632757560415ms][error][gc,verify ] GC(129) NULL card setjava.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry > [...] > points to obj 0x00000004d9abd4c8 in region 683:(S)[0x00000004d9000000,0x00000004da000000,0x00000004da000000] remset Complete > > > This string would indicate which card set container does not have the requested remembered set entry. This is unnecessary information, as the "points to obj" string later shows that there should be a remset to this region already, and otherwise only interesting for debugging. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: b7af8905 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/b7af890574b3c13122fe7de987a8c9458c05f625 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod 8274430: Remove some debug error printing code added in JDK-8017163 Reviewed-by: sjohanss, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5733 From zgu at openjdk.java.net Mon Oct 11 12:23:11 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 12:23:11 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 10:46:09 GMT, Aleksey Shipilev wrote: > Hold on a sec, I have questions... > > I see `MultiArray_lock` is `safepoint`. Shouldn't this be `safepoint - 1` then? You see any difference with safepoint-1 and safepoint-2? I do agree probably should be safepoint-1 because https://github.com/openjdk/jdk/pull/5869 did that. I think this would basically say "you can acquire any `safepoint` lock", right? Also, does the same thing apply to `_gc_waiters_lock`? > I thought about that. It appears that _gc_waiters_lock is only acquired vs. SH::collect(), where I don't see it is possible holding MultiArray_lock. > Changing both locks to `safepoint - 1` passes `hotspot_gc_shenandoah` for me here. I will make change on _alloc_failure_waiters_lock rank, but not sure we really need to change _gc_waiters_lock, what your opinion? ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From mdoerr at openjdk.java.net Mon Oct 11 12:30:23 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 11 Oct 2021 12:30:23 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register Message-ID: The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. ------------- Commit messages: - 8275049: [ZGC] missing null check in ZNMethod::log_register Changes: https://git.openjdk.java.net/jdk/pull/5892/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5892&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275049 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5892/head:pull/5892 PR: https://git.openjdk.java.net/jdk/pull/5892 From zgu at openjdk.java.net Mon Oct 11 12:42:33 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 12:42:33 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests [v2] In-Reply-To: References: Message-ID: > I were able to reproduce with aggressive heuristics. > > A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. > > The solution is only run breakpoints during _wb_breakpoint GC. > > Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. > > Test: > > - [x] tier1 with Shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5868/files - new: https://git.openjdk.java.net/jdk/pull/5868/files/175811c7..e34cd1bc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5868&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5868&range=00-01 Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5868/head:pull/5868 PR: https://git.openjdk.java.net/jdk/pull/5868 From sjohanss at openjdk.java.net Mon Oct 11 12:57:07 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 11 Oct 2021 12:57:07 GMT Subject: RFR: 8274466 G1: use field directly rather than method in G1CollectorState::in_mixed_phase [v2] In-Reply-To: References: Message-ID: On Thu, 30 Sep 2021 01:34:28 GMT, Hamlin Li wrote: >> This is a minor improvement which remove the redundant G1 Collector states usages. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Revert wrong code Marked as reviewed by sjohanss (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5745 From github.com+25214855+casparcwang at openjdk.java.net Mon Oct 11 13:06:35 2021 From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=) Date: Mon, 11 Oct 2021 13:06:35 GMT Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v4] In-Reply-To: References: Message-ID: > Similar to JDK-8255237, bulk free empty relocated pages can amortize the cost of freeing a page and speed up the relocation stage. > > The following is the result of specjbb2015 after applying the patch (the tests turn off the option`UseDynamicNumberOfGCThreads`): the average relocation time speeds up 14%, and the max relocation time speeds up 18%. > > patch: > [2021-09-18T13:11:51.736+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 373.180 / 569.855 275.312 / 569.855 275.312 / 569.855 ms > [2021-09-18T15:30:07.168+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 381.266 / 577.812 277.272 / 577.812 277.272 / 577.812 ms > [2021-09-18T17:37:56.305+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 345.037 / 494.135 259.497 / 506.815 259.497 / 506.815 ms > > > origin: > [2021-09-18T01:01:32.897+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 429.099 / 662.120 327.213 / 759.723 327.213 / 759.723 ms > [2021-09-18T03:11:10.433+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 413.014 / 613.035 307.625 / 613.035 307.625 / 613.035 ms > [2021-09-18T05:21:12.743+0800][info][gc,stats ] Phase: Concurrent Relocate 0.000 / 0.000 411.745 / 642.242 308.986 / 642.242 308.986 / 642.242 ms ?? has updated the pull request incrementally with one additional commit since the last revision: Fix the wrong usage of ZPerWorker ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5670/files - new: https://git.openjdk.java.net/jdk/pull/5670/files/cf18a1f1..8961636f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5670&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5670&range=02-03 Stats: 14 lines in 1 file changed: 5 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5670/head:pull/5670 PR: https://git.openjdk.java.net/jdk/pull/5670 From github.com+25214855+casparcwang at openjdk.java.net Mon Oct 11 13:10:10 2021 From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=) Date: Mon, 11 Oct 2021 13:10:10 GMT Subject: RFR: JDK-8274249: ZGC: Bulk free empty relocated pages [v3] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 08:49:57 GMT, Per Liden wrote: > You're right that `_empty_pages` needs to be worker local (or protected by a lock). However, you can't use `ZPerWorker` like you do here, since you would be allocating a new worker local storage every time we do relocation. A `ZPerWorker` instance is semi-static, i.e. can only be initialized once and it will never deallocated its backing storage. Thank you for your review. Directly use `ZPerWorker` like this will lead to memory leak. So I just changed it to a static variable. ------------- PR: https://git.openjdk.java.net/jdk/pull/5670 From shade at openjdk.java.net Mon Oct 11 13:11:10 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:11:10 GMT Subject: RFR: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:42:33 GMT, Zhengyu Gu wrote: >> I were able to reproduce with aggressive heuristics. >> >> A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. >> >> The solution is only run breakpoints during _wb_breakpoint GC. >> >> Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. >> >> Test: >> >> - [x] tier1 with Shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Aleksey's comment Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5868 From shade at openjdk.java.net Mon Oct 11 13:28:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:28:09 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu wrote: > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah > I do agree probably should be safepoint-1 because #5869 did that. Yes, I think Shenandoah never takes `JNICritical_lock`, so it is fine to have `safepoint - 1` here. > I thought about that. It appears that _gc_waiters_lock is only acquired vs. SH::collect(), where I don't see it is possible holding MultiArray_lock. I think it is technically possible to call `SH::collect()` from the Java code that holds the `MultiArray_lock`, as part of OOM allocation? I think it would be future-proof to accept all `safepoint`-rank locks in `ShenandoahControlThread`, i.e. make all of them `safepoint - 1`. You probably want to run `tier1`, `tier2` with `TEST_VM_OPTS=-XX:+UseShenandoahGC` to confirm. ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From zgu at openjdk.java.net Mon Oct 11 13:38:32 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 13:38:32 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check [v2] In-Reply-To: References: Message-ID: <0GZrEu1lHjo6kpJqn13T1YMpNkNErNjFY4eJ8qkkAcc=.a8afbde1-8a24-4812-99c2-afb924b4201d@github.com> > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Aleksey's comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5865/files - new: https://git.openjdk.java.net/jdk/pull/5865/files/bad7be7c..c224b441 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5865&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5865&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5865.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5865/head:pull/5865 PR: https://git.openjdk.java.net/jdk/pull/5865 From shade at openjdk.java.net Mon Oct 11 13:43:09 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 11 Oct 2021 13:43:09 GMT Subject: RFR: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check [v2] In-Reply-To: <0GZrEu1lHjo6kpJqn13T1YMpNkNErNjFY4eJ8qkkAcc=.a8afbde1-8a24-4812-99c2-afb924b4201d@github.com> References: <0GZrEu1lHjo6kpJqn13T1YMpNkNErNjFY4eJ8qkkAcc=.a8afbde1-8a24-4812-99c2-afb924b4201d@github.com> Message-ID: On Mon, 11 Oct 2021 13:38:32 GMT, Zhengyu Gu wrote: >> JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. >> >> This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. >> >> >> Test: >> >> - [x] hotspot_gc_shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Aleksey's comment Looks good, provided the tests pass. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5865 From tschatzl at openjdk.java.net Mon Oct 11 13:50:12 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Oct 2021 13:50:12 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: <3TS03qvLOG6SzWXQzxw1mpVukud9sQWaJGRbbhVL1Ro=.6dca6a20-e0ee-4003-8351-25d95e598d53@github.com> References: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> <0yrT7cXU8JFAi89--wVTGOMYqVAtCxaKb25hJqcEdvk=.924ebf97-a614-40f9-9f96-49afde46261c@github.com> <3TS03qvLOG6SzWXQzxw1mpVukud9sQWaJGRbbhVL1Ro=.6dca6a20-e0ee-4003-8351-25d95e598d53@github.com> Message-ID: On Sun, 10 Oct 2021 12:31:43 GMT, Vishal Chand wrote: >> Also please do not scale card table entry size with region size - there are some applications (many references, large remembered sets; e.g. the one in [JDK-8152438](https://bugs.openjdk.java.net/browse/JDK-8152438)) that with a 1024 card table size show 30% longer pause times. (Actually, they benefit a lot from smaller card table entry size, i.e. they get around the same pause time improvement with e.g. 256 byte sized card table entry size if heap region size permits). > > Currently I'm not scaling card size with region size, as it is not required. With current supported region sizes (1M to 32M) and card sizes (512b, 1024B), all the possible combinations of region size and card size are valid combinations. If we include 256b cards or 64M regions, then invalid combinations will be there which would need to be handled. > Do you think that code/logic is needed now, or we can add if and when needed? Okay, let's leave it at that for now. Note that all that kept me thinking over the weekend, and I found an easy way (the remembered set refactoring in 18 made that possible) to completely decouple heap region size from remembered sets. So soon we'll be able to have heap region sizes > 32M without any restrictions. Same for card table sizes, they can be set independently of region size now (although 1024 is max as long as we fix BOT and card table size to the same). Then we can re-introduce the option to allow smaller (probably 256, *maybe* 128) card table sizes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From github.com+10235864+vish-chan at openjdk.java.net Mon Oct 11 15:01:10 2021 From: github.com+10235864+vish-chan at openjdk.java.net (Vishal Chand) Date: Mon, 11 Oct 2021 15:01:10 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: References: <8hSCW0kaRXskz_uS-KVuHlpjLxRdwKQSdQA9HGMkFSw=.60b1eedd-894a-4786-ba9a-1388c1de7b0c@github.com> <0yrT7cXU8JFAi89--wVTGOMYqVAtCxaKb25hJqcEdvk=.924ebf97-a614-40f9-9f96-49afde46261c@github.com> <3TS03qvLOG6SzWXQzxw1mpVukud9sQWaJGRbbhVL1Ro=.6dca6a20-e0ee-4003-8351-25d95e598d53@github.com> Message-ID: <7YSOnngS0aOFD3uUxXriDuXul6orkRwZ0W4CDefJoSE=.0e996ec7-dad2-4bdf-8a23-4d72b73a400a@github.com> On Mon, 11 Oct 2021 13:47:29 GMT, Thomas Schatzl wrote: >> Currently I'm not scaling card size with region size, as it is not required. With current supported region sizes (1M to 32M) and card sizes (512b, 1024B), all the possible combinations of region size and card size are valid combinations. If we include 256b cards or 64M regions, then invalid combinations will be there which would need to be handled. >> Do you think that code/logic is needed now, or we can add if and when needed? > > Okay, let's leave it at that for now. > > Note that all that kept me thinking over the weekend, and I found an easy way (the remembered set refactoring in 18 made that possible) to completely decouple heap region size from remembered sets. > > So soon we'll be able to have heap region sizes > 32M without any restrictions. Same for card table sizes, they can be set independently of region size now (although 1024 is max as long as we fix BOT and card table size to the same). > > Then we can re-introduce the option to allow smaller (probably 256, *maybe* 128) card table sizes. Great, sounds good. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From zgu at openjdk.java.net Mon Oct 11 15:14:17 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 15:14:17 GMT Subject: Integrated: 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 16:47:07 GMT, Zhengyu Gu wrote: > I were able to reproduce with aggressive heuristics. > > A _wb_breakpoint GC request , while a concurrent GC is started. ShenandoahBreakpoint::_start_gc may not get set, as we bypass it if it is not a _wb_breakpoint GC, then we are forever blocked in ShenandoahBreakpoint::at_before_gc(), waiting for the flag to be set. > > The solution is only run breakpoints during _wb_breakpoint GC. > > Also, enforced _requested_gc_cause and _gc_requested order, ensure that read side sees latest _requested_gc_cause. > > Test: > > - [x] tier1 with Shenandoah This pull request has now been integrated. Changeset: 3f073377 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/3f07337722a0c8c6b452a44745598268d67c0864 Stats: 27 lines in 1 file changed: 15 ins; 3 del; 9 mod 8273614: Shenandoah: intermittent timeout with ConcurrentGCBreakpoint tests Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5868 From tschatzl at openjdk.java.net Mon Oct 11 15:25:29 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 11 Oct 2021 15:25:29 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() Message-ID: Hi all, can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. Testing: gha, gc/g1 local testing. Thanks, Thomas ------------- Commit messages: - Optimize HeapRegionRemSet::split_card Changes: https://git.openjdk.java.net/jdk/pull/5895/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275055 Stats: 45 lines in 6 files changed: 42 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5895.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5895/head:pull/5895 PR: https://git.openjdk.java.net/jdk/pull/5895 From zgu at openjdk.java.net Mon Oct 11 17:02:23 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 17:02:23 GMT Subject: Integrated: 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check In-Reply-To: References: Message-ID: <6_QTyEr66ayhWg3BJhNCVcVP5iCl-roChJiNGlRUs_A=.3c364b78-f29d-476e-a467-c0a394c60222@github.com> On Fri, 8 Oct 2021 13:40:51 GMT, Zhengyu Gu wrote: > JDK-8273917 lowered MultiArray_lock rank from nonleaf+2 to nonleaf, that results several Shenandoah tests failed on lock rank check. > > This patch lowers ShenandoahAllocFailureGC_lock rank by 2 to maintain original order. > > > Test: > > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 75f5145e Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/75f5145e21a1320c1a08080af861497ce7c3f266 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8274925: Shenandoah: shenandoah/TestAllocHumongousFragment.java test failed on lock rank check Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5865 From zgu at openjdk.java.net Mon Oct 11 18:13:34 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 11 Oct 2021 18:13:34 GMT Subject: RFR: 8275051: Shenandoah: Enforce ordering of requested gc cause and gc request flag Message-ID: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> Although setting gc request is under _gc_waiters_lock, but read side (run_service()) does not take the lock. We need to enforce following ordering, so that read side sees latest requested gc cause when the flag is set. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - Merge branch 'master' into JDK-8275051-gc_req_order - v0 Changes: https://git.openjdk.java.net/jdk/pull/5898/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5898&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275051 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5898.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5898/head:pull/5898 PR: https://git.openjdk.java.net/jdk/pull/5898 From mdoerr at openjdk.java.net Mon Oct 11 18:28:56 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 11 Oct 2021 18:28:56 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v3] In-Reply-To: References: Message-ID: <4dGhPv7DKhCFo7EdlOW5AmNHgmTsI9gR_ExPcRqb6wM=.008ec779-aeba-4f0f-97f6-5e04ca8f4ed0@github.com> On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with three additional commits since the last revision: > > - Remove superfluous copyright change > - Fix predicate conditions > - Add ByteSize constructor to Address Thanks for doing the requested fixes. LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5842 From nradomski at openjdk.java.net Mon Oct 11 20:18:54 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Mon, 11 Oct 2021 20:18:54 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v3] In-Reply-To: References: Message-ID: <1R7fNrUlVve0iCeLPoSqdffRJzwjNMBjv7ELUcE3fNc=.bbc9ad55-a976-4129-9da0-dad205a7a50a@github.com> On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with three additional commits since the last revision: > > - Remove superfluous copyright change > - Fix predicate conditions > - Add ByteSize constructor to Address Thank you for your reviews! Glad to see that the changes have been so well received. ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From jonathanjoo at google.com Mon Oct 11 20:33:48 2021 From: jonathanjoo at google.com (Jonathan Joo) Date: Mon, 11 Oct 2021 16:33:48 -0400 Subject: Question about the return value of g1CollectedHeap::expand() Message-ID: Hello, I'm not sure if this is a bug, but in the documentation it says that expand() returns True if the heap was expanded by the requested amount: https://github.com/openjdk/jdk17/blob/master/src/hotspot/share/gc/g1/g1CollectedHeap.hpp#L592 However, in the code, it seems to actually return True if the number of regions to expand is > 0, which is not dependent on whether the expand() call actually expands the heap or not. https://github.com/openjdk/jdk17/blob/master/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1318 I believe the return value should be something like `return expanded_by > 0` (if any heap expansion should return True), or even `return expanded_by == regions_to_expand` (if the full requested expansion needs to occur in order to return True). Am I misunderstanding something here? Thank you in advance! ~ Jonathan From nradomski at openjdk.java.net Mon Oct 11 21:05:53 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Mon, 11 Oct 2021 21:05:53 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. Marked as reviewed by nradomski (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From thomas.schatzl at oracle.com Mon Oct 11 21:20:38 2021 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 11 Oct 2021 21:20:38 +0000 Subject: Question about the return value of g1CollectedHeap::expand() In-Reply-To: References: Message-ID: Hi Jonathan, you are right afaict. The correct return value should be "return expanded_by > 0;" as you suggest. I filed https://bugs.openjdk.java.net/browse/JDK-8275080. Feel free to pick it up! ? Thanks, Thomas ________________________________ From: hotspot-gc-dev on behalf of Jonathan Joo Sent: Monday, October 11, 2021 10:33 PM To: hotspot-gc-dev Subject: Question about the return value of g1CollectedHeap::expand() Hello, I'm not sure if this is a bug, but in the documentation it says that expand() returns True if the heap was expanded by the requested amount: https://github.com/openjdk/jdk17/blob/master/src/hotspot/share/gc/g1/g1CollectedHeap.hpp#L592 However, in the code, it seems to actually return True if the number of regions to expand is > 0, which is not dependent on whether the expand() call actually expands the heap or not. https://github.com/openjdk/jdk17/blob/master/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1318 I believe the return value should be something like `return expanded_by > 0` (if any heap expansion should return True), or even `return expanded_by == regions_to_expand` (if the full requested expansion needs to occur in order to return True). Am I misunderstanding something here? Thank you in advance! ~ Jonathan From mli at openjdk.java.net Tue Oct 12 01:28:52 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 12 Oct 2021 01:28:52 GMT Subject: RFR: 8274466 G1: use field directly rather than method in G1CollectorState::in_mixed_phase [v2] In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:54:29 GMT, Stefan Johansson wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert wrong code > > Marked as reviewed by sjohanss (Reviewer). Thanks @kstefanj @albertnetymk for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5745 From mli at openjdk.java.net Tue Oct 12 01:28:53 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 12 Oct 2021 01:28:53 GMT Subject: Integrated: 8274466 G1: use field directly rather than method in G1CollectorState::in_mixed_phase In-Reply-To: References: Message-ID: On Wed, 29 Sep 2021 01:09:41 GMT, Hamlin Li wrote: > This is a minor improvement which remove the redundant G1 Collector states usages. This pull request has now been integrated. Changeset: 1e306959 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/1e3069593e6f56714e1ee557b70930c2749d820c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8274466: G1: use field directly rather than method in G1CollectorState::in_mixed_phase Reviewed-by: ayang, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/5745 From shade at openjdk.java.net Tue Oct 12 05:59:00 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 12 Oct 2021 05:59:00 GMT Subject: RFR: 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag In-Reply-To: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> References: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> Message-ID: On Mon, 11 Oct 2021 18:07:01 GMT, Zhengyu Gu wrote: > Although setting gc request is under _gc_waiters_lock, but read side (run_service()) does not take the lock. We need to enforce following ordering, so that read side sees latest requested gc cause when the flag is set. > > Test: > - [x] hotspot_gc_shenandoah Looks good! ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5898 From sjohanss at openjdk.java.net Tue Oct 12 08:15:55 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 12 Oct 2021 08:15:55 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 10:05:07 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with four additional commits since the last revision: > > - Fixed a bug in array claim > - Fixed a bug that causes premature deactivate > - Renaming variables > - Renaming A bit late to the party. Here are some thoughts from me. First of all, many thanks for identifying this issue. Certainly something we need to address. ? Secondly, did you ever explore fixing the bot as we go in the evacuation phase? And if so, have you seen any issues with such an approach? I did a quick PoC (that doesn't yet handle out of PLAB allocations) and from my initial measurements it looks quite promising: https://github.com/openjdk/jdk/compare/master...kstefanj:rnd-bot-yc-update Pushing this work out of the pause might be the end goal, but analyzing the overall affect of increased concurrent work is harder than just shuffling around the work in the pause. My initial measurements with the above shows shorter scan-times at the cost of slightly longer copy-times, but the overall pause is shorter. ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From eosterlund at openjdk.java.net Tue Oct 12 08:32:48 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 12 Oct 2021 08:32:48 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. The oops we read here are written in c1_Runtime, while holding the Patching_lock. However, the Patching_lock is not held when registering. In other words, someone could be writing an oop while we are reading it in this loop, due to C1 patching. If the loads re-order in here, we may crash the VM. Since we have plain loads, the compiler is free to re-order. I think the solution I would go with, is to use the CompiledICLocker instead where we patch the code in C1. That ends up taking the per-nmethod lock, that we can hold while logging this. That makes sure that accessing the oops implies mutual exclusion. Then we can remove the Patching_lock, since it is only ever used in that one place. ------------- Changes requested by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5892 From tschatzl at openjdk.java.net Tue Oct 12 10:31:52 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 12 Oct 2021 10:31:52 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:38:39 GMT, Vishal Chand wrote: >> src/hotspot/share/gc/parallel/objectStartArray.hpp line 57: >> >>> 55: static uint block_shift; >>> 56: static uint block_size; >>> 57: static uint block_size_in_words; >> >> I *think* the naming guideline for static members is the same as for regular class members, i.e. use an underscore in front. Maybe wait on changing this for another person to comment on (I did not look up the style guide). >> We do not use public static members too often :) > > Actually I've kept the names of all the pre-existing constants (which are now variables) same as before. Otherwise we have to change all the references also. Let's see what the second reviewer thinks. Otherwise this can be done separately as it might hide the interesting part of this change. >> src/hotspot/share/gc/shared/cardTable.cpp line 468: >> >>> 466: uintx CardTable::ct_max_alignment_constraint() { >>> 467: // CardTable max alignment is computed with card_size_max >>> 468: return card_size_max * os::vm_page_size(); >> >> I think this change causes some tests to fail because their heap will get too large. Maybe it is possible to move code so that the actual card size value is used here to avoid this, or fix the errors (will be visible with enabled github actions). > > I don't see any errors after enabling the tests via github actions. Am I missing something here? I'll re-check. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From zgu at openjdk.java.net Tue Oct 12 12:01:52 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 12 Oct 2021 12:01:52 GMT Subject: Integrated: 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag In-Reply-To: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> References: <0tUy0jWP_gwht-qBTAQ9hdwQEI4TKMNm1NWsKhVAkQA=.90770606-5095-429d-bf1d-92236a58c094@github.com> Message-ID: On Mon, 11 Oct 2021 18:07:01 GMT, Zhengyu Gu wrote: > Although setting gc request is under _gc_waiters_lock, but read side (run_service()) does not take the lock. We need to enforce following ordering, so that read side sees latest requested gc cause when the flag is set. > > Test: > - [x] hotspot_gc_shenandoah This pull request has now been integrated. Changeset: 1ab64143 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/1ab64143c06e33e23172dd77c39e434443347364 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod 8275051: Shenandoah: Correct ordering of requested gc cause and gc request flag Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5898 From tschatzl at openjdk.java.net Tue Oct 12 12:53:11 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 12 Oct 2021 12:53:11 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? > > The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). > > The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). > > This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. > > There are three interesting changes: > * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. > * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. > * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). > > Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang review2 - optimize remove() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5786/files - new: https://git.openjdk.java.net/jdk/pull/5786/files/3cebd394..23b14f15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5786&range=02-03 Stats: 14 lines in 1 file changed: 4 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5786.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5786/head:pull/5786 PR: https://git.openjdk.java.net/jdk/pull/5786 From ayang at openjdk.java.net Tue Oct 12 13:08:51 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 12 Oct 2021 13:08:51 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references [v4] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 12:53:11 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? >> >> The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). >> >> The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). >> >> This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. >> >> There are three interesting changes: >> * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. >> * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. >> * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). >> >> Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > ayang review2 - optimize remove() Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5786 From tschatzl at openjdk.java.net Tue Oct 12 13:14:50 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 12 Oct 2021 13:14:50 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define In-Reply-To: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: On Thu, 7 Oct 2021 14:25:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that simplifies performance work with evacuation failure handling a little? In particular, it adds a define called `EVAC_FAILURE_INJECTOR` (on by default in non-product builds) that allows to compile in/out the relevant injector code also in product mode (if manually enabled). > > Actually, this PR suggests two variants for this: one that also automatically enables flags when `EVAC_FAILURE_INJECTOR` is selected (beaa6c3), and one that requires the developer also change the options from develop/notproduct to product to be available (9f07ffd). > > The first is maybe makes the change a bit too hacky in `g1_globals.hpp` (unless there are ways to do that better, i.e. I could move the `GC_G1_EVACUATION_FAILURE_FLAGS` somewhere, or there is a much better preprocessor trick here, so I would like to have you decide. > > Testing: gha, manual checking that in product mode by default no evacuation failure handling is in, but with the flag, and otherwise the same as before, tier1-5 > > Thanks, > Thomas Fwiw, the reason to do performance work for evacuation failure handling is that we are going to use evacuation failure handling code for region pinning work. However, since region pinning itself is not in the code (and even that would require some patches), it is easier to do performance work by inducing evacuation failure. ------------- PR: https://git.openjdk.java.net/jdk/pull/5851 From mdoerr at openjdk.java.net Tue Oct 12 13:54:48 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Oct 2021 13:54:48 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. Hi Erik, your description sounds like the plain reads are what are problematic. (Oop creation always needs to release the header initialization. Otherwise, it's a bug there.) I agree with that. I could use `Atomic::load(p)` or `Atomic::load_acquire(p)`. What do you think about that? Fundamental locking changes are out of scope, here. That could be done separately if desired. This issue is about the missing null check. Note that we may need to backport this fix, so we should better keep it simple. ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From eosterlund at openjdk.java.net Tue Oct 12 14:20:51 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 12 Oct 2021 14:20:51 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. I think we could just Atomic::load(p) for now to deal with the null check, and then see if we want to deal with the other race condition another day. ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From pliden at openjdk.java.net Tue Oct 12 14:37:52 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 12 Oct 2021 14:37:52 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. src/hotspot/share/gc/z/zNMethod.cpp line 130: > 128: for (oop* p = begin; p < end; p++) { > 129: const char* external_name = (*p) == nullptr ? "null" > 130: : (*p)->klass()->external_name(); Apart from doing an Atomic::load() here, I'd also suggest we write "N/A" instead of "null", since the class isn't really null. ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From mdoerr at openjdk.java.net Tue Oct 12 15:21:15 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Oct 2021 15:21:15 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v2] In-Reply-To: References: Message-ID: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Use Atomic::load to read the oop and change klass name to N/A in case of null oop. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5892/files - new: https://git.openjdk.java.net/jdk/pull/5892/files/bf1a79e1..5f48b723 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5892&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5892&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5892/head:pull/5892 PR: https://git.openjdk.java.net/jdk/pull/5892 From mdoerr at openjdk.java.net Tue Oct 12 15:21:16 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Oct 2021 15:21:16 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. Thanks for your suggestions. They make sense. ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From eosterlund at openjdk.java.net Tue Oct 12 15:33:52 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 12 Oct 2021 15:33:52 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:21:15 GMT, Martin Doerr wrote: >> The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Use Atomic::load to read the oop and change klass name to N/A in case of null oop. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5892 From pliden at openjdk.java.net Tue Oct 12 16:22:58 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 12 Oct 2021 16:22:58 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v2] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 15:21:15 GMT, Martin Doerr wrote: >> The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Use Atomic::load to read the oop and change klass name to N/A in case of null oop. Changes requested by pliden (Reviewer). src/hotspot/share/gc/z/zNMethod.cpp line 129: > 127: oop* const end = nm->oops_end(); > 128: for (oop* p = begin; p < end; p++) { > 129: oop o = Atomic::load(p); // C1 PatchingStub may replace it concurrently. Can we please make this `const oop o = ...` src/hotspot/share/gc/z/zNMethod.cpp line 131: > 129: oop o = Atomic::load(p); // C1 PatchingStub may replace it concurrently. > 130: const char* external_name = o == nullptr ? "N/A" > 131: : o->klass()->external_name(); Can we please make this a single line, and add parenthesis around `(o == nullptr)` src/hotspot/share/gc/z/zNMethod.cpp line 133: > 131: : o->klass()->external_name(); > 132: log_oops.print(" Oop[" SIZE_FORMAT "] " PTR_FORMAT " (%s)", > 133: (p - begin), p2i(*p), external_name); `p2i(*p)` should be `p2i(o)` now ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From mdoerr at openjdk.java.net Tue Oct 12 16:41:17 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Oct 2021 16:41:17 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v3] In-Reply-To: References: Message-ID: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Use o instead of *p plus further cleanup. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5892/files - new: https://git.openjdk.java.net/jdk/pull/5892/files/5f48b723..f6fe2e4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5892&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5892&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5892.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5892/head:pull/5892 PR: https://git.openjdk.java.net/jdk/pull/5892 From mdoerr at openjdk.java.net Tue Oct 12 16:51:59 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 12 Oct 2021 16:51:59 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 16:41:17 GMT, Martin Doerr wrote: >> The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Use o instead of *p plus further cleanup. Good catch. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From pliden at openjdk.java.net Tue Oct 12 19:07:51 2021 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 12 Oct 2021 19:07:51 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 16:41:17 GMT, Martin Doerr wrote: >> The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Use o instead of *p plus further cleanup. Thanks for fixing. Looks good! ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5892 From eosterlund at openjdk.java.net Tue Oct 12 20:00:49 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 12 Oct 2021 20:00:49 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 16:41:17 GMT, Martin Doerr wrote: >> The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Use o instead of *p plus further cleanup. Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From duke at openjdk.java.net Wed Oct 13 05:48:52 2021 From: duke at openjdk.java.net (Yude Lin) Date: Wed, 13 Oct 2021 05:48:52 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 10:05:07 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with four additional commits since the last revision: > > - Fixed a bug in array claim > - Fixed a bug that causes premature deactivate > - Renaming variables > - Renaming Hi Stefan, I looked at the PoC code. My understanding is you're updating the BOT as objects that cross card boundaries are allocated in a PLAB. I haven't try this particular approach. But my first reaction when I found this issue is also to process the plabs in the pause. (I chose a lazier approach, that is, during gc pause, update BOT for plabs allocated in the last gc pause. Lazy or not, I think there is little difference. The lazy approach needs an additional phase, and some code to coordinate parallel BOT update, which has overhead; whereas updating BOT as objects are allocated into a plab, might waste some work, because in mixed gc, there might be some old regions we never ever need to scan?) Anyway, I like the idea of removing all cost from the pause time, which is what the current approach tries to achieve. I don't think there will be lot more additional concurrent work than there currently is. Because if we don't update BOT concurrently, the refinement threads still has to update a large part of BOT. So in effect it transfers the work from concurrent refine to concurrent BOT update. As you can see in an earlier graph, the concurrent refinement rates actually increased. But this is to compare concurrent BOT update vs no BOT update at all. If we were to compare concurrent BOT update vs paused BOT update, yes, there will be additional concurrent work. But I think concurrent work should be favored over pause-time work, generally speaking. By the way, I'm working on an update on the patch. It will reuse the concurrent refinement threads and dirty card queue infrastructure, as suggested in an earlier discussion. The patch looks less scary without the additional threads and c ard set data structures. I hope that will lessen your worry about this solution. Thanks! Regards, Yude ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From mdoerr at openjdk.java.net Wed Oct 13 07:17:58 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 13 Oct 2021 07:17:58 GMT Subject: RFR: 8275049: [ZGC] missing null check in ZNMethod::log_register [v3] In-Reply-To: References: Message-ID: On Tue, 12 Oct 2021 16:41:17 GMT, Martin Doerr wrote: >> The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. > > Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: > > Use o instead of *p plus further cleanup. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From mdoerr at openjdk.java.net Wed Oct 13 07:17:59 2021 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 13 Oct 2021 07:17:59 GMT Subject: Integrated: 8275049: [ZGC] missing null check in ZNMethod::log_register In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 12:23:03 GMT, Martin Doerr wrote: > The VM crashes while trying to read (*p)->klass() in "ZNMethod::log_register" on PPC64. We need a null check. See JBS for details. This pull request has now been integrated. Changeset: cf828673 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/cf828673a9b76fd3f26db9a3f714166861a65c9e Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8275049: [ZGC] missing null check in ZNMethod::log_register Reviewed-by: nradomski, eosterlund, pliden ------------- PR: https://git.openjdk.java.net/jdk/pull/5892 From duke at openjdk.java.net Wed Oct 13 07:18:52 2021 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Wed, 13 Oct 2021 07:18:52 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with three additional commits since the last revision: > > - Remove superfluous copyright change > - Fix predicate conditions > - Add ByteSize constructor to Address 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 8275049_ZGC_log_register 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/5842 From nradomski at openjdk.java.net Wed Oct 13 07:40:57 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Wed, 13 Oct 2021 07:40:57 GMT Subject: Integrated: 8274851: [PPC64] Port zgc to linux on ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 19:27:26 GMT, Niklas Radomski wrote: > Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. This pull request has now been integrated. Changeset: 337b73a4 Author: Niklas Radomski Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/337b73a459ba24aa529b7b097617434be1d0030e Stats: 1273 lines in 11 files changed: 1265 ins; 0 del; 8 mod 8274851: [PPC64] Port zgc to linux on ppc64le Reviewed-by: ihse, pliden, mdoerr, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From tschatzl at openjdk.java.net Wed Oct 13 08:14:55 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 08:14:55 GMT Subject: Integrated: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references In-Reply-To: References: Message-ID: On Fri, 1 Oct 2021 08:58:35 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this redo of (JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references)[https://bugs.openjdk.java.net/browse/JDK-8271880]? > > The JDK-8271180 change has been backed out because it crashed fairly easily on (kitchensink)[https://bugs.openjdk.java.net/browse/JDK-8274340] (and apparently also on some (ArrayJuggle tests)[https://bugs.openjdk.java.net/browse/JDK-8274452]). > > The reason is that the original change missed application of the barriers during removal of an element from the discovered list. This change fixes that, properly applying it (calling the `enqueue` methods). > > This change consist of two commits at this time: first the revert of the backout for JDK-8271180, and a second one with the actual fixes. For people who already looked at the former I recommend only looking at that the latter. > > There are three interesting changes: > * change of the `EnqueueDiscoveredFieldClosure::enqueue` fields' first parameter to directly take the address to patch. This simplifies some code. > * introduction of the barrier in the `DiscoveredListIterator::remove` method - this should be the only relevant place where the barrier application has been missing. There is some special handling when removing from the start of the discovered list - the address points into the C-heap at that time and we should not apply a barrier here. > * the `EnqueueDiscoveredFieldClosure::enqueue` method filters out writes to non-live reference objects (as per the `_is_alive` closure) - we may get called during removal of elements, and the next element is also not live. There is no need to apply the barrier to those. Actually, leaving this out could trigger an assertion in `G1ParScanThreadState::write_ref_field_post` where it checks that the object we refer to that is in the collection set must be self-forwarded (i.e. an object where evacuation failed). > > Testing: tier1-5, kitchensink (30min) 720 times with no crash, the failing ArrayJuggle28 test 2000 times > > Thanks, > Thomas This pull request has now been integrated. Changeset: c3b75c6c Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/c3b75c6cdf03ffa3c887bf3db29e17668b228f79 Stats: 188 lines in 16 files changed: 80 ins; 75 del; 33 mod 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references Reviewed-by: sjohanss, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5786 From tschatzl at openjdk.java.net Wed Oct 13 08:14:55 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 08:14:55 GMT Subject: RFR: 8274516: [REDO] JDK-8271880: Tighten condition for excluding regions from collecting cards with cross-references [v4] In-Reply-To: References: Message-ID: <9QMB0BI-2EB5XPoSgYnMa9fQ6M8Wz6eEE8fVsEfN-F4=.27f39410-6881-4bbd-b1d2-d9bbf2a64fb7@github.com> On Tue, 12 Oct 2021 13:06:00 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> ayang review2 - optimize remove() > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @kstefanj for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5786 From sjohanss at openjdk.java.net Wed Oct 13 08:38:48 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 13 Oct 2021 08:38:48 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: <7fRFoui1k5KgwjLf5HZLXeWpsgvJGW4vEDr5NRf8bRU=.833a1864-1ccd-4d4b-8b91-d78dd1120acb@github.com> On Wed, 13 Oct 2021 05:46:12 GMT, Yude Lin wrote: > Hi Stefan, > > I looked at the PoC code. My understanding is you're updating the BOT as objects that cross card boundaries are allocated in a PLAB. I haven't try this particular approach. But my first reaction when I found this issue is also to process the plabs in the pause. (I chose a lazier approach, that is, during gc pause, update BOT for plabs allocated in the last gc pause. Lazy or not, I think there is little difference. The lazy approach needs an additional phase, and some code to coordinate parallel BOT update, which has overhead; whereas updating BOT as objects are allocated into a plab, might waste some work, because in mixed gc, there might be some old regions we never ever need to scan?) > Yes, my approach would generate a complete BOT for all old regions and it is true that parts of it might never be scanned (if there are no outgoing pointers). On the other hand no additional book-keeping is needed and we have the objects crossing thresholds at hand. > Anyway, I like the idea of removing all cost from the pause time, which is what the current approach tries to achieve. I don't think there will be lot more additional concurrent work than there currently is. Because if we don't update BOT concurrently, the refinement threads still has to update a large part of BOT. So in effect it transfers the work from concurrent refine to concurrent BOT update. As you can see in an earlier graph, the concurrent refinement rates actually increased. But this is to compare concurrent BOT update vs no BOT update at all. If we were to compare concurrent BOT update vs paused BOT update, yes, there will be additional concurrent work. But I think concurrent work should be favored over pause-time work, generally speaking. By the way, I'm working on an update on the patch. It will reuse the concurrent refinement threads and dirty card queue infrastructure, as suggested in an earlier discussion. The patch looks less scary without the additional threads and card set data structures. I hope that will lessen your worry about this solution. Thanks! > I also like removing time from the GC pause, but we need to keep a balance. If the additional work outside the pause is significant larger it is not as clear of a win. Not saying we don't want to do this but we should carefully look at the options. I also believe that this will be more efficient than what we currently have, just want to make sure it is worth the additional complexity. So hearing that you plan to simplify this quite a bit is really good. One question, how do we make sure that as much as possible of the BOT is updated concurrently before the next GC? Thanks, Stefan > Regards, Yude ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Wed Oct 13 09:02:49 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 09:02:49 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 10:05:07 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with four additional commits since the last revision: > > - Fixed a bug in array claim > - Fixed a bug that causes premature deactivate > - Renaming variables > - Renaming > > Hi Stefan, > > Anyway, I like the idea of removing all cost from the pause time, which is what the current approach tries to achieve. I don't think there will be lot more additional concurrent work than there currently is. Because if we don't update BOT concurrently, the refinement threads still has to update a large part of BOT. So in effect it transfers the work from concurrent refine to concurrent BOT update. As you can see in an earlier graph, the concurrent refinement rates actually increased. But this is to compare concurrent BOT update vs no BOT update at all. If we were to compare concurrent BOT update vs paused BOT update, yes, there will be additional concurrent work. But I think concurrent work should be favored over pause-time work, generally speaking. By the ? There should be some balance though; I particularly like the idea about only doing refinement work for areas that we actually collected remembered set entries. > > I also like removing time from the GC pause, but we need to keep a balance. If the additional work outside the pause is significant larger it is not as clear of a win. Not saying we don't want to do this but we should carefully look at the options. > > I also believe that this will be more efficient than what we currently have, just want to make sure it is worth the additional complexity. So hearing that you plan to simplify this quite a bit is really good. ? > One question, how do we make sure that as much as possible of the BOT is updated concurrently before the next GC? > The idea is to make sure that new cards into areas not yet updated are processed in an expedited way (i.e. "immediately") - since card processing automatically updates the BOTs, we only need to make sure they are processed without waiting for the regular mechanism to kick in. One could also enqueue the "first" card in newly allocated PLABs in special queues that are processed with priority. There are a few options as usual, and we would certainly like to find a good one wrt to several aspects. Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From sjohanss at openjdk.java.net Wed Oct 13 09:33:59 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 13 Oct 2021 09:33:59 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 08:59:21 GMT, Thomas Schatzl wrote: > > One question, how do we make sure that as much as possible of the BOT is updated concurrently before the next GC? > > The idea is to make sure that new cards into areas not yet updated are processed in an expedited way (i.e. "immediately") - since card processing automatically updates the BOTs, we only need to make sure they are processed without waiting for the regular mechanism to kick in. > Ok, good, because just using the normal refinement mechanism might be to slow. > One could also enqueue the "first" card in newly allocated PLABs in special queues that are processed with priority. There are a few options as usual, and we would certainly like to find a good one wrt to several aspects. > I agree there are few different ways to solve this, and we should seek to find the best one both from a performance and maintainability perspective. Stefan > Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Wed Oct 13 11:14:50 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 11:14:50 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> References: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> Message-ID: On Fri, 8 Oct 2021 20:16:45 GMT, Vishal Chand wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable > - Changes as per the first set of comments The change looks good now (keeping in mind that for some questions we are waiting for a second reviewer to chime in), however there are some things we need to do first: * complete testing; while I have pushed the change through our perf test suite with no statistically significant regressions when using compiled-in 512 bytes card size vs. configurable 512 bytes card size, and ran with different (smaller) card sizes I would like to confirm the improvements you reported for the 1024 bytes case on specjbb2015, and analyze a few of the particular results. This will take a bit. * for the new product flag (if we make it product, I am going to ask about this internally) we need a CSR completed before pushing. I started one at https://bugs.openjdk.java.net/browse/JDK-8275142, please have a look. If we decide to make this non-product, then we can just close the CSR again. * it would be nice to not be required to amend the CSR later to fix the bounds of the `GCCardSizeInBytes` flag (when it stays a product flag) when G1 supports different heap region sizes > 32M. There is already a draft PR out for this (https://github.com/openjdk/jdk/pull/5909), and a branch that contains a quickly merged repo (https://github.com/openjdk/jdk/compare/master...tschatzl:submit/virtualize-g1card-config-card-set-size?expand=1). Are there any problems with waiting a bit for this change on PR#5909? Maybe you are also interested to try out the combination of PR#5909 and this one, allowing card table entry sizes from 128 to 1024 and any combination of region size iirc. In PR#5909 there is also the question of how large regions G1 should allow with that - the patch currently allows up to 512M regions, but theoretically there is no limit - do you have any opinion on that? Thanks, Thomas src/hotspot/share/gc/parallel/objectStartArray.hpp line 60: > 58: > 59: // This maximum is derived from that we need an extra bit for possible > 60: // offsets in the byte for backskip values (this is a hard limit) Suggestion: // Maximum size an offset table entry can cover. This maximum is derived from that we need an extra bit for possible // offsets in the byte for backskip values, leaving 2^7 possible offsets. Mininum object alignment is 8 bytes (2^3), so we can at most represent 2^10 offsets within a BOT value. (We *could* make this maximum dependent on `ObjectAlignmentInBytes`, but I do not know if increasing ObjectAlignmentInBytes gives any advantage. So at most defer this investigation to some other time as I'm already keeping busy some machines) ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From tschatzl at openjdk.java.net Wed Oct 13 12:25:57 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 12:25:57 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Sat, 9 Oct 2021 03:53:35 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code More unnecessary changes during refactoring I did not notice earlier. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 51: > 49: } > 50: > 51: uint next_num_elems(uint prev_num_elems) { use `override` here. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 55: > 53: } > 54: > 55: uint elem_size () const {return _elem_size;} This one should be removed, already defined (exactly the same) in the base class. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 127: > 125: return sizeof(*this) + > 126: _segmented_array.num_buffers() * sizeof(G1CardSetBuffer) > 127: + _segmented_array.num_available_nodes() * _segmented_array.elem_size(); Please keep the operator in the preceeding line; weird indentation. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 133: > 131: return (_segmented_array.num_available_nodes() > 132: - (_segmented_array.num_allocated_nodes() - _num_pending_nodes)) > 133: * _segmented_array.elem_size(); I prefer to keep the operator in the preceeding line. It is also okay to break through the 80 character line width limit now and then - it's not a very hard limit. src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 135: > 133: * _segmented_array.elem_size(); > 134: } > 135: inline uint num_buffers() { return _segmented_array.num_buffers(); } missing newline before `num_buffers` src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 77: > 75: size_t mem_size() const { return sizeof(*this) + (size_t)_num_elems * _elem_size; } > 76: > 77: uint length() { This method is unused in the current code. Please remove. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 88: > 86: > 87: > 88: Two extra newlines src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 128: > 126: class G1SegmentedArrayAllocOptions { > 127: protected: > 128: uint _elem_size; Newline after visibility specifier. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 134: > 132: uint _alignment; > 133: > 134: uint exponential_expand(uint prev_num_elems) { Unused in this class - remove or use the sub-classes' implementation for now. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 150: > 148: } > 149: > 150: uint next_num_elems(uint prev_num_elems) { Probably it's best to define this as virtual abstract and override as needed in subclasses. Or just keep the implementation from `G1CardSetAllocOptions` here for now. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 197: > 195: G1SegmentedArrayBuffer* _last; // The last element of the list of all buffers. > 196: volatile uint _num_buffers; // Number of assigned buffers to this allocator. > 197: volatile size_t _mem_size; // Memory used by all buffers. The comments for the last two were aligned with the ones above in the original. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 210: > 208: public: > 209: uint num_available_nodes() const { return _num_available_nodes; } > 210: uint num_allocated_nodes() const { return _num_allocated_nodes; } volatile variables should be loaded via `Atomic::load()` (also in `first_array_buffer`) src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 212: > 210: uint num_allocated_nodes() const { return _num_allocated_nodes; } > 211: const G1SegmentedArrayBuffer* first_array_buffer() const { return _first; } > 212: inline uint elem_size() const; Please space out these four new getters a little - one before `first_array_buffer`, another before `elem_size` to give them some air. Also it would be nice to declare these in the same order of the members. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Wed Oct 13 12:26:01 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 12:26:01 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 08:19:11 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator >> - Rename Xxx to G1Xxx >> - Clean code >> - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums >> - Initial commit > > src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 41: > >> 39: // Collects G1CardSetAllocator options/heuristics. Called by G1CardSetAllocator >> 40: // to determine the next size of the allocated G1CardSetBuffer. >> 41: > > Superfluous newline Still the case... ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Wed Oct 13 14:46:53 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 14:46:53 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> References: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> Message-ID: On Fri, 8 Oct 2021 20:16:45 GMT, Vishal Chand wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable > - Changes as per the first set of comments Fwiw, we in the gc team agreed that this flag should be a product flag so that hopefully people will use it. So we need that CSR before integrating it :) Hth, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From zgu at openjdk.java.net Wed Oct 13 15:40:21 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 13 Oct 2021 15:40:21 GMT Subject: RFR: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges Message-ID: I believe for the cases that there is no plain read of atomic variables, we can relax memory ordering constraints for claiming tasks/ranges by workers. Test: - [x] hotspot_gc_shenandoah (fastdebug + release) on x86_64 and aarch64 Linux ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/5929/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5929&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275226 Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/5929.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5929/head:pull/5929 PR: https://git.openjdk.java.net/jdk/pull/5929 From sjohanss at openjdk.java.net Wed Oct 13 18:30:49 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 13 Oct 2021 18:30:49 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 15:11:12 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. > > It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. > > Testing: gha, gc/g1 local testing. > > Thanks, > Thomas Looks good, but I would like us to come up with better naming for the limit. src/hotspot/share/gc/g1/heapRegionRemSet.cpp line 53: > 51: > 52: void HeapRegionRemSet::initialize(HeapWord* heap_base_address) { > 53: _split_card_shift = MIN2((uint)HeapRegion::LogCardsPerRegion, per_card_region_card_limit()) + CardTable::card_shift; This caught my eye a bit and the reason I think is that `per_card_region_card_limit()` sounds like a limit in actual cards, but it is in fact a "log" value. Could we call it something like `G1CardSetContainer::LogCardsPerRegionLimit` and access it directly? ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5895 From tschatzl at openjdk.java.net Wed Oct 13 19:42:15 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 13 Oct 2021 19:42:15 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. > > It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. > > Testing: gha, gc/g1 local testing. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanss review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5895/files - new: https://git.openjdk.java.net/jdk/pull/5895/files/d59d3fc5..765ea501 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=00-01 Stats: 47 lines in 6 files changed: 32 ins; 12 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5895.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5895/head:pull/5895 PR: https://git.openjdk.java.net/jdk/pull/5895 From sjohanss at openjdk.java.net Wed Oct 13 19:46:47 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 13 Oct 2021 19:46:47 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v2] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 19:42:15 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. >> >> It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. >> >> Testing: gha, gc/g1 local testing. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > sjohanss review Looks good. src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 181: > 179: } > 180: > 181: // Maximum size of the entries of any G1CardSetContainer in bits. This first can be removed now. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5895 From duke at openjdk.java.net Wed Oct 13 20:33:50 2021 From: duke at openjdk.java.net (Vishal Chand) Date: Wed, 13 Oct 2021 20:33:50 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> References: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> Message-ID: On Fri, 8 Oct 2021 20:16:45 GMT, Vishal Chand wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable > - Changes as per the first set of comments src/hotspot/share/gc/g1/g1CardTable.hpp line 79: > 77: static const size_t WordAllClean = SIZE_MAX; > 78: static const size_t WordAllDirty = 0; > 79: static const size_t LogOfMaxCardsPerRegion = BitsPerByte * sizeof(G1CardSetArray::EntryDataType); @tschatzl Do we need this code once JDK-8275056 (Virtualize G1CardSet containers over heap region) gets integrated? From my understanding, this won't be a restriction from heap region point of view. Do I need to remove this and the changes in `g1CardTable.cpp `? ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From mli at openjdk.java.net Thu Oct 14 05:35:49 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 14 Oct 2021 05:35:49 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 12:03:10 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine code > > src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 128: > >> 126: class G1SegmentedArrayAllocOptions { >> 127: protected: >> 128: uint _elem_size; > > Newline after visibility specifier. Do you mean "before"? ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Thu Oct 14 06:54:59 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 14 Oct 2021 06:54:59 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: References: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> Message-ID: <2cty1sK3wSwf5pUGudbVy7wgkX4vAhyldeXuBtmtzZ4=.4ae6ce45-c213-4c66-bbe2-7cbfd74bed94@github.com> On Wed, 13 Oct 2021 20:30:33 GMT, Vishal Chand wrote: >> Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: >> >> - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable >> - Changes as per the first set of comments > > src/hotspot/share/gc/g1/g1CardTable.hpp line 79: > >> 77: static const size_t WordAllClean = SIZE_MAX; >> 78: static const size_t WordAllDirty = 0; >> 79: static const size_t LogOfMaxCardsPerRegion = BitsPerByte * sizeof(G1CardSetArray::EntryDataType); > > @tschatzl Do we need this code once JDK-8275056 (Virtualize G1CardSet containers over heap region) gets integrated? From my understanding, this won't be a restriction from heap region point of view. Do I need to remove this and the changes in `g1CardTable.cpp `? Yes. The change you will need will be very similar to https://github.com/openjdk/jdk/commit/70dcca62c4fd6657729beb3c2b985eb342b5788b (slightly modified because of review comments); but please wait until it is in. No hurry though, we'll need to complete the CSR before we can integrate anyway. Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From shade at openjdk.java.net Thu Oct 14 08:34:52 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 14 Oct 2021 08:34:52 GMT Subject: RFR: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges In-Reply-To: References: Message-ID: <2KXtqgqHRH8hpgNUw3Z-iQa8_Wt9k_IdOh8eoWoyFa0=.4ab69119-d9fb-4d0e-8fa8-2ad8a146259c@github.com> On Wed, 13 Oct 2021 15:33:23 GMT, Zhengyu Gu wrote: > I believe for the cases that there is no plain read on atomic variables, we can relax memory ordering constraints for claiming tasks/ranges by workers. > > Test: > - [x] hotspot_gc_shenandoah (fastdebug + release) on x86_64 and aarch64 Linux Yes, all these look like plain atomic-counter CASes. Nothing seems to depend on their memory semantics. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5929 From tschatzl at openjdk.java.net Thu Oct 14 08:41:15 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 14 Oct 2021 08:41:15 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v3] In-Reply-To: References: Message-ID: <8uudE_Q3n6R8VW4z45UKQrMbTkxxgl1J0498mLRfw38=.6208791a-0799-41f0-914d-26e9f5a3fc40@github.com> > Hi all, > > can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. > > It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. > > Testing: gha, gc/g1 local testing. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanss review2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5895/files - new: https://git.openjdk.java.net/jdk/pull/5895/files/765ea501..615bf7c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5895.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5895/head:pull/5895 PR: https://git.openjdk.java.net/jdk/pull/5895 From sjohanss at openjdk.java.net Thu Oct 14 08:41:15 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 14 Oct 2021 08:41:15 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v2] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 19:42:15 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. >> >> It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. >> >> Testing: gha, gc/g1 local testing. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > sjohanss review ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5895 From mli at openjdk.java.net Thu Oct 14 09:05:53 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 14 Oct 2021 09:05:53 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 11:44:55 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine code > > src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 150: > >> 148: } >> 149: >> 150: uint next_num_elems(uint prev_num_elems) { > > Probably it's best to define this as virtual abstract and override as needed in subclasses. Or just keep the implementation from `G1CardSetAllocOptions` here for now. I'm afraid I have missed something more important, _alloc_options in G1SegmentedArray should be a pointer rather than value, as its behaviour should be polymorphic, so I also made more changes to address this issue in g1CardSetMemory.cpp, g1CardSet.cpp/hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Thu Oct 14 09:12:13 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 14 Oct 2021 09:12:13 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v5] In-Reply-To: References: Message-ID: > To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. > > This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine code; fix polymorphic issue in G1SegmentedArray's alloc_options ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5478/files - new: https://git.openjdk.java.net/jdk/pull/5478/files/69d7007e..6510e8cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=03-04 Stats: 85 lines in 6 files changed: 29 ins; 34 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/5478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5478/head:pull/5478 PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Thu Oct 14 11:26:51 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 14 Oct 2021 11:26:51 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: <2lvDaoLWppfdh7SJ3xY2LgLWmswWg2AweBeGPqZZi0I=.f0414a2b-1614-425e-8f2f-2f5ebdf9e1d7@github.com> On Thu, 14 Oct 2021 05:33:16 GMT, Hamlin Li wrote: >> src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 128: >> >>> 126: class G1SegmentedArrayAllocOptions { >>> 127: protected: >>> 128: uint _elem_size; >> >> Newline after visibility specifier. > > Do you mean "before"? Keep it as is, it's fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Thu Oct 14 11:31:00 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 14 Oct 2021 11:31:00 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 09:03:14 GMT, Hamlin Li wrote: >> src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 150: >> >>> 148: } >>> 149: >>> 150: uint next_num_elems(uint prev_num_elems) { >> >> Probably it's best to define this as virtual abstract and override as needed in subclasses. Or just keep the implementation from `G1CardSetAllocOptions` here for now. > > I'm afraid I have missed something more important, _alloc_options in G1SegmentedArray should be a pointer rather than value, as its behaviour should be polymorphic, so I also made more changes to address this issue in g1CardSetMemory.cpp, g1CardSet.cpp/hpp. At the same time, I also do a little improvement on the allocation of G1CardSetAllocOptions in G1CardSetConfiguration, it was allocated every time mem_object_alloc_options is invoked, now it's only allocated once in G1CardSetConfiguration, hope I'm doing the right thing here. Please keep not absolutely necessary changes to separate CRs (or *at least* separate commits in the same CR). These are very quickly reviewed if small. However, adding these to large refactorings is definitely the wrong thing to do, making reviewers spend extraordinary amount of time to separate them from the refactoring. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Thu Oct 14 11:42:50 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 14 Oct 2021 11:42:50 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v4] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 11:27:14 GMT, Thomas Schatzl wrote: >> I'm afraid I have missed something more important, _alloc_options in G1SegmentedArray should be a pointer rather than value, as its behaviour should be polymorphic, so I also made more changes to address this issue in g1CardSetMemory.cpp, g1CardSet.cpp/hpp. At the same time, I also do a little improvement on the allocation of G1CardSetAllocOptions in G1CardSetConfiguration, it was allocated every time mem_object_alloc_options is invoked, now it's only allocated once in G1CardSetConfiguration, hope I'm doing the right thing here. > > Please keep not absolutely necessary changes to separate CRs (or *at least* separate commits in the same CR). These are very quickly reviewed if small. However, adding these to large refactorings is definitely the wrong thing to do, making reviewers spend extraordinary amount of time to separate them from the refactoring. For this one, I think it's necessary. As you suggested I should have put this part in a separate commit, sorry for the inconvenience, I will pay attention in future commits. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From zgu at openjdk.java.net Thu Oct 14 12:56:51 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 14 Oct 2021 12:56:51 GMT Subject: Integrated: 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 15:33:23 GMT, Zhengyu Gu wrote: > I believe for the cases that there is no plain read on atomic variables, we can relax memory ordering constraints for claiming tasks/ranges by workers. > > Test: > - [x] hotspot_gc_shenandoah (fastdebug + release) on x86_64 and aarch64 Linux This pull request has now been integrated. Changeset: 3b0b6adc Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/3b0b6adc3d547fcf4b971536d2404c342d18046f Stats: 6 lines in 4 files changed: 0 ins; 0 del; 6 mod 8275226: Shenandoah: Relax memory constraint for worker claiming tasks/ranges Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/5929 From duke at openjdk.java.net Thu Oct 14 13:12:53 2021 From: duke at openjdk.java.net (Vishal Chand) Date: Thu, 14 Oct 2021 13:12:53 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: <2cty1sK3wSwf5pUGudbVy7wgkX4vAhyldeXuBtmtzZ4=.4ae6ce45-c213-4c66-bbe2-7cbfd74bed94@github.com> References: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> <2cty1sK3wSwf5pUGudbVy7wgkX4vAhyldeXuBtmtzZ4=.4ae6ce45-c213-4c66-bbe2-7cbfd74bed94@github.com> Message-ID: On Thu, 14 Oct 2021 06:51:28 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1CardTable.hpp line 79: >> >>> 77: static const size_t WordAllClean = SIZE_MAX; >>> 78: static const size_t WordAllDirty = 0; >>> 79: static const size_t LogOfMaxCardsPerRegion = BitsPerByte * sizeof(G1CardSetArray::EntryDataType); >> >> @tschatzl Do we need this code once JDK-8275056 (Virtualize G1CardSet containers over heap region) gets integrated? From my understanding, this won't be a restriction from heap region point of view. Do I need to remove this and the changes in `g1CardTable.cpp `? > > Yes. The change you will need will be very similar to https://github.com/openjdk/jdk/commit/70dcca62c4fd6657729beb3c2b985eb342b5788b (slightly modified because of review comments); but please wait until it is in. No hurry though, we'll need to complete the CSR before we can integrate anyway. > > Thomas okay, got it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From duke at openjdk.java.net Thu Oct 14 13:28:54 2021 From: duke at openjdk.java.net (Vishal Chand) Date: Thu, 14 Oct 2021 13:28:54 GMT Subject: RFR: 8272773: Investigate making card table size configurable [v3] In-Reply-To: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> References: <7PSP0DR_gCbUuCBsasvRIo_mbTIS8IdC_-FWvrsxN-c=.fa3d56a8-74a2-4f59-934f-d2e763a4734d@github.com> Message-ID: On Fri, 8 Oct 2021 20:16:45 GMT, Vishal Chand wrote: >> Hi, >> >> Please review the changes to make CardTable entry size configurable. The changes primarily consists of: >> >> 1. Addition of a cmdline flag **GCCardSizeInBytes** to make the card size startup time configurable. >> 2. Setting the card size based on the flag in G1, Parallel and Serial GC memory initialization paths. >> 3. Setting BlockOffsetTable size and ObjectStartArray size based on the card size. > > Vishal Chand has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'card-size-configurable' of https://github.com/vish-chan/jdk into card-size-configurable > - Changes as per the first set of comments Are there any problems with waiting a bit for this change on PR#5909? [Vishal] No issues. I think it would be a cleaner and better approach. Maybe you are also interested to try out the combination of PR#5909 and this one, allowing card table entry sizes from 128 to 1024 and any combination of region size iirc. [Vishal] Yes, I'll try on my end different combinations of card sizes and region sizes. I'll report my observations. In PR#5909 there is also the question of how large regions G1 should allow with that - the patch currently allows up to 512M regions, but theoretically there is no limit - do you have any opinion on that? [Vishal] Currently, I have no strong opinion regarding the max. region size. I'll run specjbb2015 with different region sizes > 32m with different card sizes. I'll report if I find anything interesting. Thanks, Vishal ------------- PR: https://git.openjdk.java.net/jdk/pull/5838 From ayang at openjdk.java.net Thu Oct 14 18:51:57 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 14 Oct 2021 18:51:57 GMT Subject: RFR: 8275298: Remove unnecessary weak_oops_do call in adjust weak roots phase Message-ID: This PR consists of two logical steps in two commits: 1. change `weak_oops_do` to `verify_no_references_recorded` to check discovered lists (DL) are indeed empty during adjust-weak-roots phase 2. Move the assertion to the end of ref-processing, since elements on DL are not really related to "weak roots" Test: tier1-6 ------------- Commit messages: - move assert - ref-dl-roots Changes: https://git.openjdk.java.net/jdk/pull/5957/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5957&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275298 Stats: 37 lines in 9 files changed: 4 ins; 30 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5957/head:pull/5957 PR: https://git.openjdk.java.net/jdk/pull/5957 From rkennke at redhat.com Thu Oct 14 20:41:33 2021 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Oct 2021 22:41:33 +0200 Subject: RFC: Separate/refactor forward pointer access Message-ID: <4f0843d1-66d0-4b18-5cd2-1f59635dd300@redhat.com> Hello GC-devs, I implemented a refactoring and separation of the forward-pointer access that currently is in oopDesc. My original intent was to have this as an optimization (see rationale in the PR below in oopForwarding.hpp), but alas, I could not show it to improve any performance. However, maybe we want to have it anyway, on the basis of cleanliness and separation of concerns: https://github.com/openjdk/jdk/pull/5955 I like that it encapsulates and scopes header access and forwarding pointer decoding. I also like that it's separated out of oopDesc and markWord. In some places, it replaces otherwise aweful raw decoding of forwarding pointer (those should be fixed, no matter what). And I also like that it avoids double-loading the header, and compiles better code, even if it does not make a dent in performance. Opinions about it? If it gets rejected, no problem at all. I actually almost wanted to abandon it, but then thought it cannot hurt to ask first. Also, in any case, I would like to fix the mess that is in g1FullGCCompactionPoint.cpp and src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp, I stumbled across this multiple times already, and couldn't really make heads or tails with it. We shouldn't reset the header of non-forwarded objects there, just to be able to make == NULL comparison of a raw-decoded forward pointer elsewhere. If this PR gets rejected, I'd fix it separately. If we agree that it's useful, I'd formalize it and open an RFR. Thanks, Roman From ayang at openjdk.java.net Thu Oct 14 22:30:51 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 14 Oct 2021 22:30:51 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v5] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 09:12:13 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code; fix polymorphic issue in G1SegmentedArray's alloc_options Changes requested by ayang (Reviewer). src/hotspot/share/gc/g1/g1CardSet.cpp line 94: > 92: _bitmap_hash_mask = ~(~(0) << _log2_num_cards_in_howl_bitmap); > 93: > 94: init_card_set_alloc_options(); There's much code duplication btw the two constructors of `G1CardSetConfiguration::G1CardSetConfiguration`. Now that this PR touches it, it could be good if this can be dealt with, instead of repeating more code, `init_card_set_alloc_options();` specifically. src/hotspot/share/gc/g1/g1CardSet.hpp line 118: > 116: // Returns the memory allocation options for the memory objects on the card set heap. The returned > 117: // array must be freed by the caller. > 118: const G1CardSetAllocOptions* mem_object_alloc_options(uint idx); Now that this method doesn't do mem alloc, the comment should be revised. src/hotspot/share/gc/g1/g1CardSetMemory.cpp line 131: > 129: num_available_nodes, > 130: percent_of(num_allocated_nodes - _num_pending_nodes, num_available_nodes), > 131: first_array_buffer != nullptr ? first_array_buffer->num_elems() : 0, How about extracting the logic from the prinf function? Sth like: const uint highest = _segmented_array.first_array_buffer() != nullptr ? _segmented_array.first_array_buffer()->num_elems() : 0; src/hotspot/share/gc/g1/g1CardSetMemory.inline.hpp line 44: > 42: Elem* G1CardSetAllocator::allocate() { > 43: uint elem_size = _segmented_array.elem_size(); > 44: assert(elem_size > 0, "instance size not set."); The var declaration is unnecessary. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 127: > 125: static const uint BufferAlignment = 4; > 126: static const uint MinimumBufferSize = 8; > 127: static const uint MaximumBufferSize = UINT_MAX / 2; It's not obvious to me why they are public. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 129: > 127: static const uint MaximumBufferSize = UINT_MAX / 2; > 128: > 129: G1SegmentedArrayAllocOptions(uint elem_size, uint initial_num_elems = MinimumBufferSize, I only see one place calling this constructor, specifying all args. The default arg-value can be drop if they are not used, IMO. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 211: > 209: Elem* G1SegmentedArray::allocate() { > 210: uint es = elem_size(); > 211: assert(es > 0, "instance size not set."); Unnecessary var declaration. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Fri Oct 15 01:05:51 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 15 Oct 2021 01:05:51 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v5] In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 21:53:08 GMT, Albert Mingkun Yang wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> refine code; fix polymorphic issue in G1SegmentedArray's alloc_options > > src/hotspot/share/gc/g1/g1CardSet.cpp line 94: > >> 92: _bitmap_hash_mask = ~(~(0) << _log2_num_cards_in_howl_bitmap); >> 93: >> 94: init_card_set_alloc_options(); > > There's much code duplication btw the two constructors of `G1CardSetConfiguration::G1CardSetConfiguration`. Now that this PR touches it, it could be good if this can be dealt with, instead of repeating more code, `init_card_set_alloc_options();` specifically. Per discussion with Thomas, it's better to stick to the scheme that we only do simplest refactoring when do refactoring, I'm afraid that this refactoring is already too complicated, so can I do it in another issue if you don't mind? ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Fri Oct 15 01:24:23 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 15 Oct 2021 01:24:23 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v6] In-Reply-To: References: Message-ID: <9j1Dl1hG94lC-nWtMG7wtbNuAkS08TOwGX9Q3H1z13o=.779de5d2-2ec1-49da-bd9b-e1d132dca477@github.com> > To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. > > This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: refine code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5478/files - new: https://git.openjdk.java.net/jdk/pull/5478/files/6510e8cf..992e44dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=04-05 Stats: 13 lines in 5 files changed: 2 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/5478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5478/head:pull/5478 PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Fri Oct 15 08:14:48 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 15 Oct 2021 08:14:48 GMT Subject: RFR: 8275298: Remove unnecessary weak_oops_do call in adjust weak roots phase In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 18:43:44 GMT, Albert Mingkun Yang wrote: > This PR consists of two logical steps in two commits: > > 1. change `weak_oops_do` to `verify_no_references_recorded` to check discovered lists (DL) are indeed empty during adjust-weak-roots phase > 2. Move the assertion to the end of ref-processing, since elements on DL are not really related to "weak roots" > > Test: tier1-6 Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5957 From tschatzl at openjdk.java.net Fri Oct 15 11:25:04 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 15 Oct 2021 11:25:04 GMT Subject: RFR: 8275277: assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not Message-ID: Hi all, can I have reviews for this fix of an incomplete assert? When checking whether the forwardee equals the object, we first need to check whether the object is already forwarded, otherwise we might get false positives. See CR for more details (example). Testing: gha, failing tests do not fail after 2k repetitions Thanks, Thomas ------------- Commit messages: - Fix assertion Changes: https://git.openjdk.java.net/jdk/pull/5965/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5965&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275277 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5965.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5965/head:pull/5965 PR: https://git.openjdk.java.net/jdk/pull/5965 From ayang at openjdk.java.net Fri Oct 15 12:23:00 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 15 Oct 2021 12:23:00 GMT Subject: RFR: 8275277: assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 10:12:56 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this fix of an incomplete assert? > > When checking whether the forwardee equals the object, we first need to check whether the object is already forwarded, otherwise we might get false positives. See CR for more details (example). > > Testing: gha, failing tests do not fail after 2k repetitions > > Thanks, > Thomas Ofc `obj` could be outside `cset`, and it's dangerous to call `forwardee` directly... Thank you for the analysis and the fix. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5965 From stefank at openjdk.java.net Fri Oct 15 12:23:14 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 15 Oct 2021 12:23:14 GMT Subject: RFR: 8275333: Print count in "Too many recored phases?" assert Message-ID: Just a small change to get some more information when this assert fails. ------------- Commit messages: - 8275333: Print count in "Too many recored phases?" assert Changes: https://git.openjdk.java.net/jdk/pull/5966/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5966&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275333 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5966.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5966/head:pull/5966 PR: https://git.openjdk.java.net/jdk/pull/5966 From rkennke at openjdk.java.net Fri Oct 15 13:04:47 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Fri, 15 Oct 2021 13:04:47 GMT Subject: RFR: 8275277: assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 10:12:56 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this fix of an incomplete assert? > > When checking whether the forwardee equals the object, we first need to check whether the object is already forwarded, otherwise we might get false positives. See CR for more details (example). > > Testing: gha, failing tests do not fail after 2k repetitions > > Thanks, > Thomas I've stumbled over the same thing, and came up with same solution. Looks good! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5965 From eosterlund at openjdk.java.net Fri Oct 15 13:26:57 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 15 Oct 2021 13:26:57 GMT Subject: RFR: 8275333: Print count in "Too many recored phases?" assert In-Reply-To: References: Message-ID: <0SFxN94o2hmq8NfOgef-rO7NkHzjtdCvMfNlhTyeJT0=.a4d1e1f6-5409-4b04-92c2-8fa1add94d3d@github.com> On Fri, 15 Oct 2021 12:12:58 GMT, Stefan Karlsson wrote: > Just a small change to get some more information when this assert fails. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5966 From tschatzl at openjdk.java.net Fri Oct 15 13:32:53 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 15 Oct 2021 13:32:53 GMT Subject: RFR: 8275333: Print count in "Too many recored phases?" assert In-Reply-To: References: Message-ID: <-bbbSvUG6NJMQrmsviSVV8A8fMi4yQV2s_gFQuRqSgg=.fd0f90ff-e514-4775-9099-94501f5513e3@github.com> On Fri, 15 Oct 2021 12:12:58 GMT, Stefan Karlsson wrote: > Just a small change to get some more information when this assert fails. Would be nice to fix the typo in the message to (recor*d*ed). Lgtm - I do not need to see the typo fix again if you do it. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5966 From coleenp at openjdk.java.net Fri Oct 15 15:49:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 15 Oct 2021 15:49:08 GMT Subject: RFR: 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Message-ID: Move the initialization and potential class loading of the MethodType out of eatMemory so that we don't get this OOME while loading this class. Tested with tier5 and 7. ------------- Commit messages: - 8257534: vmTestbase/gc/lock/jvmti/alloc/jvmtialloclock03/TestDescription.java failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Changes: https://git.openjdk.java.net/jdk/pull/5969/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5969&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257534 Stats: 12 lines in 1 file changed: 5 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5969/head:pull/5969 PR: https://git.openjdk.java.net/jdk/pull/5969 From tschatzl at openjdk.java.net Sat Oct 16 11:09:52 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Sat, 16 Oct 2021 11:09:52 GMT Subject: RFR: 8275277: assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 12:20:01 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> can I have reviews for this fix of an incomplete assert? >> >> When checking whether the forwardee equals the object, we first need to check whether the object is already forwarded, otherwise we might get false positives. See CR for more details (example). >> >> Testing: gha, failing tests do not fail after 2k repetitions >> >> Thanks, >> Thomas > > Ofc `obj` could be outside `cset`, and it's dangerous to call `forwardee` directly... Thank you for the analysis and the fix. Thanks @albertnetymk @rkennke for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5965 From tschatzl at openjdk.java.net Sat Oct 16 11:09:52 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Sat, 16 Oct 2021 11:09:52 GMT Subject: Integrated: 8275277: assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 10:12:56 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this fix of an incomplete assert? > > When checking whether the forwardee equals the object, we first need to check whether the object is already forwarded, otherwise we might get false positives. See CR for more details (example). > > Testing: gha, failing tests do not fail after 2k repetitions > > Thanks, > Thomas This pull request has now been integrated. Changeset: bfcf6a29 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/bfcf6a29a16bc12d77a897fbec304868957c3188 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8275277: assert(dest_attr.is_in_cset() == (obj->forwardee() == obj)) failed: Only evac-failed objects must be in the collection set here but is not Reviewed-by: ayang, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/5965 From ayang at openjdk.java.net Sun Oct 17 22:44:50 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Sun, 17 Oct 2021 22:44:50 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v6] In-Reply-To: <9j1Dl1hG94lC-nWtMG7wtbNuAkS08TOwGX9Q3H1z13o=.779de5d2-2ec1-49da-bd9b-e1d132dca477@github.com> References: <9j1Dl1hG94lC-nWtMG7wtbNuAkS08TOwGX9Q3H1z13o=.779de5d2-2ec1-49da-bd9b-e1d132dca477@github.com> Message-ID: On Fri, 15 Oct 2021 01:24:23 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code This PR incorporates some cleanup/small improvement into the main refactoring, extraction of the segmented array class. Such additional and unnecessary changes make reviewing this PR much harder that it should be. I will give a concrete example. `G1CardSetAllocator::num_buffers` used to live in `inline.hpp`, but was moved the header and updated to use the new segmented array. It could be argued that this is more consistent together with its neighbor (`mem_size` and `wasted_mem_size`), so it's a fine change. However, embedding this change inside this relatively invasive refactoring is *very* distracting; what could have been a one-line change was scattered in multiple places. src/hotspot/share/gc/g1/g1SegmentedArray.hpp line 175: > 173: template > 174: class G1SegmentedArray { > 175: // G1CardSetAllocOptions provides parameters for allocation buffer The name, `G1CardSetAllocOptions`, is incorrect. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Mon Oct 18 01:42:18 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 18 Oct 2021 01:42:18 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v7] In-Reply-To: References: Message-ID: > To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. > > This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: correct comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5478/files - new: https://git.openjdk.java.net/jdk/pull/5478/files/992e44dd..32a79333 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5478&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5478.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5478/head:pull/5478 PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Mon Oct 18 01:42:22 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 18 Oct 2021 01:42:22 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v6] In-Reply-To: <9j1Dl1hG94lC-nWtMG7wtbNuAkS08TOwGX9Q3H1z13o=.779de5d2-2ec1-49da-bd9b-e1d132dca477@github.com> References: <9j1Dl1hG94lC-nWtMG7wtbNuAkS08TOwGX9Q3H1z13o=.779de5d2-2ec1-49da-bd9b-e1d132dca477@github.com> Message-ID: On Fri, 15 Oct 2021 01:24:23 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > refine code Thanks Albert, I agree, this is a real lesson for me. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From stefank at openjdk.java.net Mon Oct 18 07:11:17 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Oct 2021 07:11:17 GMT Subject: RFR: 8275333: Print count in "Too many recored phases?" assert [v2] In-Reply-To: References: Message-ID: > Just a small change to get some more information when this assert fails. Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5966/files - new: https://git.openjdk.java.net/jdk/pull/5966/files/751ecf5b..419a77f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5966&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5966&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5966.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5966/head:pull/5966 PR: https://git.openjdk.java.net/jdk/pull/5966 From stefank at openjdk.java.net Mon Oct 18 07:11:18 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Oct 2021 07:11:18 GMT Subject: RFR: 8275333: Print count in "Too many recored phases?" assert [v2] In-Reply-To: <-bbbSvUG6NJMQrmsviSVV8A8fMi4yQV2s_gFQuRqSgg=.fd0f90ff-e514-4775-9099-94501f5513e3@github.com> References: <-bbbSvUG6NJMQrmsviSVV8A8fMi4yQV2s_gFQuRqSgg=.fd0f90ff-e514-4775-9099-94501f5513e3@github.com> Message-ID: On Fri, 15 Oct 2021 13:29:54 GMT, Thomas Schatzl wrote: >> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > Would be nice to fix the typo in the message to (recor*d*ed). > > Lgtm - I do not need to see the typo fix again if you do it. @tschatzl I haven't noticed it before. I'll fix that. Thanks both for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/5966 From sjohanss at openjdk.java.net Mon Oct 18 08:35:48 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 18 Oct 2021 08:35:48 GMT Subject: RFR: 8275298: Remove unnecessary weak_oops_do call in adjust weak roots phase In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 18:43:44 GMT, Albert Mingkun Yang wrote: > This PR consists of two logical steps in two commits: > > 1. change `weak_oops_do` to `verify_no_references_recorded` to check discovered lists (DL) are indeed empty during adjust-weak-roots phase > 2. Move the assertion to the end of ref-processing, since elements on DL are not really related to "weak roots" > > Test: tier1-6 Looks good ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5957 From sjohanss at openjdk.java.net Mon Oct 18 08:41:50 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 18 Oct 2021 08:41:50 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define In-Reply-To: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: On Thu, 7 Oct 2021 14:25:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that simplifies performance work with evacuation failure handling a little? In particular, it adds a define called `EVAC_FAILURE_INJECTOR` (on by default in non-product builds) that allows to compile in/out the relevant injector code also in product mode (if manually enabled). > > Actually, this PR suggests two variants for this: one that also automatically enables flags when `EVAC_FAILURE_INJECTOR` is selected (beaa6c3), and one that requires the developer also change the options from develop/notproduct to product to be available (9f07ffd). > > The first is maybe makes the change a bit too hacky in `g1_globals.hpp` (unless there are ways to do that better, i.e. I could move the `GC_G1_EVACUATION_FAILURE_FLAGS` somewhere, or there is a much better preprocessor trick here, so I would like to have you decide. > > Testing: gha, manual checking that in product mode by default no evacuation failure handling is in, but with the flag, and otherwise the same as before, tier1-5 > > Thanks, > Thomas Looks ok ;) ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5851 From duke at openjdk.java.net Mon Oct 18 09:32:40 2021 From: duke at openjdk.java.net (Yude Lin) Date: Mon, 18 Oct 2021 09:32:40 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v5] In-Reply-To: References: Message-ID: > A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). > > What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. Yude Lin has updated the pull request incrementally with three additional commits since the last revision: - Removed additional thread and card set code - Switch to dcq and refinement threads to manage the plab cards - Trivial ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5039/files - new: https://git.openjdk.java.net/jdk/pull/5039/files/1fc721f1..c4331668 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5039&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5039&range=03-04 Stats: 1235 lines in 22 files changed: 100 ins; 1094 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/5039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5039/head:pull/5039 PR: https://git.openjdk.java.net/jdk/pull/5039 From duke at openjdk.java.net Mon Oct 18 09:46:51 2021 From: duke at openjdk.java.net (Yude Lin) Date: Mon, 18 Oct 2021 09:46:51 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v4] In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 08:59:21 GMT, Thomas Schatzl wrote: >> Yude Lin has updated the pull request incrementally with four additional commits since the last revision: >> >> - Fixed a bug in array claim >> - Fixed a bug that causes premature deactivate >> - Renaming variables >> - Renaming > >> > Hi Stefan, >> > Anyway, I like the idea of removing all cost from the pause time, which is what the current approach tries to achieve. I don't think there will be lot more additional concurrent work than there currently is. Because if we don't update BOT concurrently, the refinement threads still has to update a large part of BOT. So in effect it transfers the work from concurrent refine to concurrent BOT update. As you can see in an earlier graph, the concurrent refinement rates actually increased. But this is to compare concurrent BOT update vs no BOT update at all. If we were to compare concurrent BOT update vs paused BOT update, yes, there will be additional concurrent work. But I think concurrent work should be favored over pause-time work, generally speaking. By the > > ? > > There should be some balance though; I particularly like the idea about only doing refinement work for areas that we actually collected remembered set entries. > >> >> I also like removing time from the GC pause, but we need to keep a balance. If the additional work outside the pause is significant larger it is not as clear of a win. Not saying we don't want to do this but we should carefully look at the options. >> >> I also believe that this will be more efficient than what we currently have, just want to make sure it is worth the additional complexity. So hearing that you plan to simplify this quite a bit is really good. > > ? > >> One question, how do we make sure that as much as possible of the BOT is updated concurrently before the next GC? >> > > The idea is to make sure that new cards into areas not yet updated are processed in an expedited way (i.e. "immediately") - since card processing automatically updates the BOTs, we only need to make sure they are processed without waiting for the regular mechanism to kick in. > > One could also enqueue the "first" card in newly allocated PLABs in special queues that are processed with priority. There are a few options as usual, and we would certainly like to find a good one wrt to several aspects. > > Thomas @tschatzl @kstefanj Updated the patch to use concurrent refinement threads and dirty card queue to manage the plab cards. FYI Let me know what you think. Thanks! Yude ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From stefank at openjdk.java.net Mon Oct 18 11:23:54 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Oct 2021 11:23:54 GMT Subject: RFR: 8275333: Print count in "Too many recored phases?" assert [v2] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 07:11:17 GMT, Stefan Karlsson wrote: >> Just a small change to get some more information when this assert fails. > > Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/5966 From stefank at openjdk.java.net Mon Oct 18 11:23:55 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 18 Oct 2021 11:23:55 GMT Subject: Integrated: 8275333: Print count in "Too many recored phases?" assert In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 12:12:58 GMT, Stefan Karlsson wrote: > Just a small change to get some more information when this assert fails. This pull request has now been integrated. Changeset: 45ebf85c Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/45ebf85ca9a1e071955ba2e3cb32449bfbd85d14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8275333: Print count in "Too many recored phases?" assert Reviewed-by: eosterlund, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5966 From ayang at openjdk.java.net Mon Oct 18 14:40:49 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 18 Oct 2021 14:40:49 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define In-Reply-To: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: On Thu, 7 Oct 2021 14:25:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that simplifies performance work with evacuation failure handling a little? In particular, it adds a define called `EVAC_FAILURE_INJECTOR` (on by default in non-product builds) that allows to compile in/out the relevant injector code also in product mode (if manually enabled). > > Actually, this PR suggests two variants for this: one that also automatically enables flags when `EVAC_FAILURE_INJECTOR` is selected (beaa6c3), and one that requires the developer also change the options from develop/notproduct to product to be available (9f07ffd). > > The first is maybe makes the change a bit too hacky in `g1_globals.hpp` (unless there are ways to do that better, i.e. I could move the `GC_G1_EVACUATION_FAILURE_FLAGS` somewhere, or there is a much better preprocessor trick here, so I would like to have you decide. > > Testing: gha, manual checking that in product mode by default no evacuation failure handling is in, but with the flag, and otherwise the same as before, tier1-5 > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/g1/g1_globals.hpp line 36: > 34: #elif !defined(EVAC_FAILURE_INJECTOR) > 35: #define EVAC_FAILURE_INJECTOR 0 > 36: #endif Since the intended use case to include evac-fail code in a release build for perf evalucation, instead of accepting an already-defined `EVAC_FAILURE_INJECTOR`, one can bluntly reject it to make the intention more explicitly: this `#define` is the authoritative source of `EVAC_FAILURE_INJECTOR`. Sth along the lines of: #ifdef EVAC_FAILURE_INJECTOR #error "EVAC_FAILURE_INJECTOR defined" #endif #ifdef PRODUCT ... When the need to cope with externally defined `EVAC_FAILURE_INJECTOR` arises (I doubt it), we can revisit this at that time. Ofc, this is quite subjective. ------------- PR: https://git.openjdk.java.net/jdk/pull/5851 From ayang at openjdk.java.net Mon Oct 18 16:04:53 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 18 Oct 2021 16:04:53 GMT Subject: RFR: 8275298: Remove unnecessary weak_oops_do call in adjust weak roots phase In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 18:43:44 GMT, Albert Mingkun Yang wrote: > This PR consists of two logical steps in two commits: > > 1. change `weak_oops_do` to `verify_no_references_recorded` to check discovered lists (DL) are indeed empty during adjust-weak-roots phase > 2. Move the assertion to the end of ref-processing, since elements on DL are not really related to "weak roots" > > Test: tier1-6 Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/5957 From ayang at openjdk.java.net Mon Oct 18 16:04:53 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 18 Oct 2021 16:04:53 GMT Subject: Integrated: 8275298: Remove unnecessary weak_oops_do call in adjust weak roots phase In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 18:43:44 GMT, Albert Mingkun Yang wrote: > This PR consists of two logical steps in two commits: > > 1. change `weak_oops_do` to `verify_no_references_recorded` to check discovered lists (DL) are indeed empty during adjust-weak-roots phase > 2. Move the assertion to the end of ref-processing, since elements on DL are not really related to "weak roots" > > Test: tier1-6 This pull request has now been integrated. Changeset: 4d383b9f Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/4d383b9fcd2e1cb3afde17a37bc2dc5a37247d04 Stats: 37 lines in 9 files changed: 4 ins; 30 del; 3 mod 8275298: Remove unnecessary weak_oops_do call in adjust weak roots phase Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/5957 From kbarrett at openjdk.java.net Mon Oct 18 17:43:55 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Oct 2021 17:43:55 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v3] In-Reply-To: <8uudE_Q3n6R8VW4z45UKQrMbTkxxgl1J0498mLRfw38=.6208791a-0799-41f0-914d-26e9f5a3fc40@github.com> References: <8uudE_Q3n6R8VW4z45UKQrMbTkxxgl1J0498mLRfw38=.6208791a-0799-41f0-914d-26e9f5a3fc40@github.com> Message-ID: On Thu, 14 Oct 2021 08:41:15 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. >> >> It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. >> >> Testing: gha, gc/g1 local testing. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > sjohanss review2 Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/g1/g1CardSetContainers.cpp line 30: > 28: #include "utilities/globalDefinitions.hpp" > 29: > 30: // The only limitation there is is from the G1CardSetArray. s/there is is/is/ src/hotspot/share/gc/g1/g1CardSetContainers.hpp line 181: > 179: } > 180: > 181: // Log of largest card index that can be stored in any G1CardSetContainer comment misindented src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 65: > 63: > 64: void HeapRegionRemSet::split_card(OopOrNarrowOopStar from, uint& card_region, uint& card_within_region) const { > 65: uintptr_t offset = pointer_delta(from, _heap_base_address, 1); Why `uintptr_t` here? `pointer_delta` returns `size_t`. Changing this would also suggest changing the type of `_split_card_mask`. src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 67: > 65: uintptr_t offset = pointer_delta(from, _heap_base_address, 1); > 66: card_region = offset >> _split_card_shift; > 67: card_within_region = (offset & _split_card_mask) >> CardTable::card_shift; Maybe assert that the narrowing conversion is ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/5895 From kbarrett at openjdk.java.net Mon Oct 18 17:53:05 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 18 Oct 2021 17:53:05 GMT Subject: RFR: 8275426: PretouchTask num_chunks calculation can overflow Message-ID: Please review this change to part of the calculation of the number of threads to apply to a PretouchTask when using a gang of worker threads. The previous calculation of the number of chunks in the range to be touched can overflow in the numerator. (This may only be a realistic problem on 32bit platforms. On 64bit platforms the value constraint on the chunk size and plausible or architectural limits on the size of the range probably prevent such overflow from occurring.) Testing: mach5 tier1 Locally (linux-x64) ran with logging of the pretouch parameters enabled, with various chunk sizes configured, and hand-checked the logged values. ------------- Commit messages: - change num_chunks calculation Changes: https://git.openjdk.java.net/jdk/pull/5993/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5993&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275426 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5993/head:pull/5993 PR: https://git.openjdk.java.net/jdk/pull/5993 From ayang at openjdk.java.net Mon Oct 18 19:30:48 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 18 Oct 2021 19:30:48 GMT Subject: RFR: 8275426: PretouchTask num_chunks calculation can overflow In-Reply-To: References: Message-ID: <1_bR8yuOvVIVs6P9rS1lSlq7s51-iiD_VjiF7QMUAqA=.5314ee8c-337f-49c0-ac12-20925df7b7e3@github.com> On Mon, 18 Oct 2021 17:43:58 GMT, Kim Barrett wrote: > Please review this change to part of the calculation of the number of > threads to apply to a PretouchTask when using a gang of worker threads. > > The previous calculation of the number of chunks in the range to be touched > can overflow in the numerator. (This may only be a realistic problem on > 32bit platforms. On 64bit platforms the value constraint on the chunk size > and plausible or architectural limits on the size of the range probably > prevent such overflow from occurring.) > > Testing: > mach5 tier1 > Locally (linux-x64) ran with logging of the pretouch parameters enabled, > with various chunk sizes configured, and hand-checked the logged values. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5993 From tschatzl at openjdk.java.net Mon Oct 18 20:26:56 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 18 Oct 2021 20:26:56 GMT Subject: RFR: 8275426: PretouchTask num_chunks calculation can overflow In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:43:58 GMT, Kim Barrett wrote: > Please review this change to part of the calculation of the number of > threads to apply to a PretouchTask when using a gang of worker threads. > > The previous calculation of the number of chunks in the range to be touched > can overflow in the numerator. (This may only be a realistic problem on > 32bit platforms. On 64bit platforms the value constraint on the chunk size > and plausible or architectural limits on the size of the range probably > prevent such overflow from occurring.) > > Testing: > mach5 tier1 > Locally (linux-x64) ran with logging of the pretouch parameters enabled, > with various chunk sizes configured, and hand-checked the logged values. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5993 From mli at openjdk.java.net Tue Oct 19 01:24:53 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 19 Oct 2021 01:24:53 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 09:37:42 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator >> - Rename Xxx to G1Xxx >> - Clean code >> - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums >> - Initial commit > > Some additional note: > >> > Current(original) implementation just drop the newly allocated G1SegmentedArrayBuffer if current thread fails, seems it's fine as the race should be rare, should we add the faield one to free list? seems adding to freelist will bring some benefit. >> >>Yes, that's also what `G1CardSetAllocator` does. At least there, the race isn't that rare. > > You need to consider that as soon there are (real, not just faked ones) evacuation failures, all subsequent allocations of potentially all threads will fail. The segmented array somewhat deals with that by increasing the buffer size, and potentially you are not always failing in the same region... > > Thanks, > Thomas @tschatzl Hi Thomas, Would you mind to help take another review when available? Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Tue Oct 19 09:42:20 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 09:42:20 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. > > It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. > > Testing: gha, gc/g1 local testing. > > 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/5895/files - new: https://git.openjdk.java.net/jdk/pull/5895/files/615bf7c2..2825a499 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=02-03 Stats: 32 lines in 6 files changed: 21 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/5895.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5895/head:pull/5895 PR: https://git.openjdk.java.net/jdk/pull/5895 From tschatzl at openjdk.java.net Tue Oct 19 09:49:53 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 09:49:53 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v3] In-Reply-To: References: <8uudE_Q3n6R8VW4z45UKQrMbTkxxgl1J0498mLRfw38=.6208791a-0799-41f0-914d-26e9f5a3fc40@github.com> Message-ID: <4748kAfeCTYqpI7fMgCaIcAIsY-m3MkUK13Qy0fU3vs=.e9a3cad5-3c53-454d-bc83-f85d8bd6b7a7@github.com> On Mon, 18 Oct 2021 17:40:36 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> sjohanss review2 > > src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp line 67: > >> 65: uintptr_t offset = pointer_delta(from, _heap_base_address, 1); >> 66: card_region = offset >> _split_card_shift; >> 67: card_within_region = (offset & _split_card_mask) >> CardTable::card_shift; > > Maybe assert that the narrowing conversion is ok. If fixed this by adding code in `HeapRegionRemSet::initialize()`. This should be sufficient vs. checking every time. ------------- PR: https://git.openjdk.java.net/jdk/pull/5895 From tschatzl at openjdk.java.net Tue Oct 19 10:44:18 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 10:44:18 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define [v2] In-Reply-To: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: > Hi all, > > can I have reviews for this change that simplifies performance work with evacuation failure handling a little? In particular, it adds a define called `EVAC_FAILURE_INJECTOR` (on by default in non-product builds) that allows to compile in/out the relevant injector code also in product mode (if manually enabled). > > Actually, this PR suggests two variants for this: one that also automatically enables flags when `EVAC_FAILURE_INJECTOR` is selected (beaa6c3), and one that requires the developer also change the options from develop/notproduct to product to be available (9f07ffd). > > The first is maybe makes the change a bit too hacky in `g1_globals.hpp` (unless there are ways to do that better, i.e. I could move the `GC_G1_EVACUATION_FAILURE_FLAGS` somewhere, or there is a much better preprocessor trick here, so I would like to have you decide. > > Testing: gha, manual checking that in product mode by default no evacuation failure handling is in, but with the flag, and otherwise the same as before, tier1-5 > > 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/5851/files - new: https://git.openjdk.java.net/jdk/pull/5851/files/beaa6c34..c6a94fe8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5851&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5851&range=00-01 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5851.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5851/head:pull/5851 PR: https://git.openjdk.java.net/jdk/pull/5851 From tschatzl at openjdk.java.net Tue Oct 19 10:44:22 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 10:44:22 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define [v2] In-Reply-To: References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: On Mon, 18 Oct 2021 14:37:56 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> ayang review > > src/hotspot/share/gc/g1/g1_globals.hpp line 36: > >> 34: #elif !defined(EVAC_FAILURE_INJECTOR) >> 35: #define EVAC_FAILURE_INJECTOR 0 >> 36: #endif > > Since the intended use case to include evac-fail code in a release build for perf evalucation, instead of accepting an already-defined `EVAC_FAILURE_INJECTOR`, one can bluntly reject it to make the intention more explicitly: this `#define` is the authoritative source of `EVAC_FAILURE_INJECTOR`. Sth along the lines of: > > > #ifdef EVAC_FAILURE_INJECTOR > #error "EVAC_FAILURE_INJECTOR defined" > #endif > #ifdef PRODUCT > ... > > When the need to cope with externally defined `EVAC_FAILURE_INJECTOR` arises (I doubt it), we can revisit this at that time. > > Ofc, this is quite subjective. I do not mind either way, I mostly wanted to use the same constructs as we do for the task queue code. Changed it to your suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/5851 From tschatzl at openjdk.java.net Tue Oct 19 10:48:54 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 10:48:54 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v7] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 01:42:18 GMT, Hamlin Li wrote: >> To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. >> >> This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > correct comments Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5478 From ayang at openjdk.java.net Tue Oct 19 11:10:01 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 19 Oct 2021 11:10:01 GMT Subject: RFR: 8275416: G1: remove unnecesary make_referent_alive in precleaning phase Message-ID: Simple change of removing marking work in G1 precleaning. Evaluation using a contrived example shows ~20% reduction in precleaning. Test: hotspot_gc ------------- Commit messages: - g1-make-reference-alive Changes: https://git.openjdk.java.net/jdk/pull/6003/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6003&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275416 Stats: 42 lines in 3 files changed: 2 ins; 26 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6003.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6003/head:pull/6003 PR: https://git.openjdk.java.net/jdk/pull/6003 From mli at openjdk.java.net Tue Oct 19 12:28:03 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 19 Oct 2021 12:28:03 GMT Subject: RFR: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator [v3] In-Reply-To: References: Message-ID: On Fri, 8 Oct 2021 09:37:42 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into generalize-g1CardSetBuffer-and-Allocator >> - Rename Xxx to G1Xxx >> - Clean code >> - Fix wrong length() in SegmentedArrayBuffer, cause it might grow more than _elem_nums >> - Initial commit > > Some additional note: > >> > Current(original) implementation just drop the newly allocated G1SegmentedArrayBuffer if current thread fails, seems it's fine as the race should be rare, should we add the faield one to free list? seems adding to freelist will bring some benefit. >> >>Yes, that's also what `G1CardSetAllocator` does. At least there, the race isn't that rare. > > You need to consider that as soon there are (real, not just faked ones) evacuation failures, all subsequent allocations of potentially all threads will fail. The segmented array somewhat deals with that by increasing the buffer size, and potentially you are not always failing in the same region... > > Thanks, > Thomas Thanks @tschatzl @albertnetymk for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From mli at openjdk.java.net Tue Oct 19 12:28:05 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 19 Oct 2021 12:28:05 GMT Subject: Integrated: 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator In-Reply-To: References: Message-ID: On Sat, 11 Sep 2021 05:05:47 GMT, Hamlin Li wrote: > To finish https://bugs.openjdk.java.net/browse/JDK-8254739, we need a segmented array to store a growing regions index array, in the initial version of that patch, a newly home made segmented array was used, but the memory efficiency is not as good as expected, G1CardSetAllocator is a potential candidate to fullfill the requirement, but need some enhancement. > > This is a try to enhance G1CardSetAllocator(and G1CardSetBuffer, G1CardSetBufferList) to support element size less pointer size, and strip this basic function as a more generic segmented array (G1SegmentedArray). This pull request has now been integrated. Changeset: d17d81a8 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/d17d81a8b2a6336f37e17f31413a62c7adf49936 Stats: 819 lines in 8 files changed: 494 ins; 299 del; 26 mod 8273626: G1: Factor out concurrent segmented array from G1CardSetAllocator Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5478 From tschatzl at openjdk.java.net Tue Oct 19 12:48:57 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 12:48:57 GMT Subject: RFR: 8275416: G1: remove unnecesary make_referent_alive in precleaning phase In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 11:02:17 GMT, Albert Mingkun Yang wrote: > Simple change of removing marking work in G1 precleaning. Evaluation using a contrived example shows ~20% reduction in precleaning. > > Test: hotspot_gc Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6003 From ayang at openjdk.java.net Tue Oct 19 14:11:15 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 19 Oct 2021 14:11:15 GMT Subject: RFR: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr Message-ID: Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. Test: build ------------- Commit messages: - remset_is_tracked Changes: https://git.openjdk.java.net/jdk/pull/6013/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6013&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275511 Stats: 23 lines in 5 files changed: 0 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/6013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6013/head:pull/6013 PR: https://git.openjdk.java.net/jdk/pull/6013 From tschatzl at openjdk.java.net Tue Oct 19 14:12:20 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 14:12:20 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v5] In-Reply-To: References: Message-ID: <14cthBMEV7tbAQLstd0sWtKQPQyYtYPIfojoqOJ0olk=.642036ef-a5f8-4fa4-bd36-86db7ee6b9eb@github.com> > Hi all, > > can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. > > It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. > > Testing: gha, gc/g1 local testing. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix windows compilation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5895/files - new: https://git.openjdk.java.net/jdk/pull/5895/files/2825a499..139ad54a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5895&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5895.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5895/head:pull/5895 PR: https://git.openjdk.java.net/jdk/pull/5895 From tschatzl at openjdk.java.net Tue Oct 19 14:18:50 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 14:18:50 GMT Subject: RFR: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:55:25 GMT, Albert Mingkun Yang wrote: > Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. > > Test: build Please also rename `G1CollectedHeap::verify_region_attr_remset_update` to `G1CollectedHeap::verify_region_attr_remset_is_tracked`. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6013 From ayang at openjdk.java.net Tue Oct 19 14:26:17 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 19 Oct 2021 14:26:17 GMT Subject: RFR: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr [v2] In-Reply-To: References: Message-ID: > Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. > > Test: build Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6013/files - new: https://git.openjdk.java.net/jdk/pull/6013/files/53b86c84..b8bd4304 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6013&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6013&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6013/head:pull/6013 PR: https://git.openjdk.java.net/jdk/pull/6013 From tschatzl at openjdk.java.net Tue Oct 19 14:28:53 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 14:28:53 GMT Subject: RFR: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 14:26:17 GMT, Albert Mingkun Yang wrote: >> Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6013 From ayang at openjdk.java.net Tue Oct 19 14:46:52 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 19 Oct 2021 14:46:52 GMT Subject: RFR: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5697 From duke at openjdk.java.net Tue Oct 19 14:49:59 2021 From: duke at openjdk.java.net (Andrey Turbanov) Date: Tue, 19 Oct 2021 14:49:59 GMT Subject: Integrated: 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Sat, 25 Sep 2021 11:15:35 GMT, Andrey Turbanov wrote: > Collections.sort is just a wrapper, so it is better to use an instance method directly. This pull request has now been integrated. Changeset: a579483c Author: Andrey Turbanov Committer: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/a579483c88e94bdaa787d109e5ae204e7fb308c0 Stats: 26 lines in 7 files changed: 0 ins; 13 del; 13 mod 8274899: Replace usages of Collections.sort with List.sort call in jdk.hotspot.agent Reviewed-by: sspitsyn, cjplummer, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5697 From hseigel at openjdk.java.net Tue Oct 19 14:50:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 19 Oct 2021 14:50:53 GMT Subject: RFR: 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 15:40:47 GMT, Coleen Phillimore wrote: > Move the initialization and potential class loading of the MethodType out of eatMemory so that we don't get this OOME while loading this class. > Tested with tier5 and 7. The changes look good and trivial. Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5969 From rkennke at openjdk.java.net Tue Oct 19 16:26:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 19 Oct 2021 16:26:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access Message-ID: Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); or similar constructs. Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. Testing: - [x] tier - [ ] tier2 - [x] hotspot_gc ------------- Commit messages: - Update some copyright headers - Add missing includes - Merge branch 'master' into optimize-fwdptr - Add missing includes - Rename mwd -> fwd - Add missing file - Move remaining forwarding methods to OopForwarding - Renames, cleanups - Initial implementation of MarkWordDecoder Changes: https://git.openjdk.java.net/jdk/pull/5955/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275527 Stats: 351 lines in 27 files changed: 170 ins; 79 del; 102 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Tue Oct 19 16:26:05 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 19 Oct 2021 16:26:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [ ] tier2 > - [x] hotspot_gc I like it. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5955 From stefank at openjdk.java.net Tue Oct 19 21:02:05 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 19 Oct 2021 21:02:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc I like how the mark/is_marked/decode_pointer code gets cleaned up. And having an OopForwading class probably makes sense for parts of the code. I'm less excited about the way the explicitly stack allocated OopForwarding objects make the code less readable. Take these two examples: assert(old->is_objArray(), "invariant"); - assert(old->is_forwarded(), "invariant"); + assert(OopForwarding(old).is_forwarded(), "invariant"); oop new_obj = obj->is_forwarded() ? obj->forwardee() : _young_gen->copy_to_survivor_space(obj); OopForwarding fwd(obj); oop new_obj = fwd.is_forwarded() ? fwd.forwardee() : _young_gen->copy_to_survivor_space(obj); I think both snippets were nicer to read in the earlier code. And there's a lot of those kind of changes in this patch. Maybe there's a hybrid approach where we could still have oopDesc::is_forwarded, oopDesc::forwardee, etc. but also have OopForwarding objects for those places that really need them? And then minimize the amount of places we use `OopForwarding fwd(obj)` and `OopForwarding(obj)->forwardee()` in the code? ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5955 From mli at openjdk.java.net Wed Oct 20 08:48:17 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 20 Oct 2021 08:48:17 GMT Subject: RFR: 8274988 G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions Message-ID: This is a follow-up of JDK-8273626. (something mentioned in Description was already done in JDK-8273626) Some other cleanups need to be done: Some fields of G1SegmentedArrayAllocOptions better be reloated to G1CardSetAllocOptions, and some fields are const, and also adds some assert. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6032/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6032&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274988 Stats: 16 lines in 2 files changed: 8 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6032.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6032/head:pull/6032 PR: https://git.openjdk.java.net/jdk/pull/6032 From mli at openjdk.java.net Wed Oct 20 08:53:29 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 20 Oct 2021 08:53:29 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration Message-ID: 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6033/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6033&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275381 Stats: 62 lines in 2 files changed: 27 ins; 21 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6033/head:pull/6033 PR: https://git.openjdk.java.net/jdk/pull/6033 From mli at openjdk.java.net Wed Oct 20 08:56:24 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 20 Oct 2021 08:56:24 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race Message-ID: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> This is a follow-up of JDK-8273626. Current (original) implementation just drops the newly allocated G1SegmentedArrayBuffer if current thread fails race, but seems reuse (e.g adding to freelist) will bring some benefit. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6034/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6034&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274987 Stats: 25 lines in 2 files changed: 17 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6034/head:pull/6034 PR: https://git.openjdk.java.net/jdk/pull/6034 From mli at openjdk.java.net Wed Oct 20 09:04:25 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 20 Oct 2021 09:04:25 GMT Subject: RFR: 8275607 G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all Message-ID: This is a follow-up of JDK-8273626. G1CardSetAllocator::drop_all should call call G1SegmentedArray::drop_all to put all buffers into buffer free list, which is the original behavior of G1CardSetAllocator. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/6035/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6035&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275607 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6035/head:pull/6035 PR: https://git.openjdk.java.net/jdk/pull/6035 From mli at openjdk.java.net Wed Oct 20 09:13:31 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 20 Oct 2021 09:13:31 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v2] In-Reply-To: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: > This is a follow-up of JDK-8273626. > > Current (original) implementation just drops the newly allocated G1SegmentedArrayBuffer if current thread fails race, but seems reuse (e.g adding to freelist) will bring some benefit. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Fix compilation error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6034/files - new: https://git.openjdk.java.net/jdk/pull/6034/files/a534aceb..0f719443 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6034&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6034&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6034/head:pull/6034 PR: https://git.openjdk.java.net/jdk/pull/6034 From mli at openjdk.java.net Wed Oct 20 09:48:35 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 20 Oct 2021 09:48:35 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v3] In-Reply-To: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: > This is a follow-up of JDK-8273626. > > Current (original) implementation just drops the newly allocated G1SegmentedArrayBuffer if current thread fails race, but seems reuse (e.g adding to freelist) will bring some benefit. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Fix cransh on Mac; remove unnecessary code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6034/files - new: https://git.openjdk.java.net/jdk/pull/6034/files/0f719443..39d20268 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6034&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6034&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/6034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6034/head:pull/6034 PR: https://git.openjdk.java.net/jdk/pull/6034 From tschatzl at openjdk.java.net Wed Oct 20 10:30:06 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 10:30:06 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc @rkennke : could you close the superfluous CRs for this issue? You filed this one 9 times in total... (probably due to network issues yesterday). Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Wed Oct 20 10:41:08 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 10:41:08 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Never mind, already did that. I did not check if any of the duplicates contain more information than the one used for this PR though. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Wed Oct 20 10:41:08 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Oct 2021 10:41:08 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 10:36:17 GMT, Thomas Schatzl wrote: > Never mind, already did that. I did not check if any of the duplicates contain more information than the one used for this PR though. Oh dear! Thank you! Yes, when I tried to file the issue, bugs.o.j.n was down and/or very slow. Apparently every attempt actually went through, without actually sending back a confirmation. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From ayang at openjdk.java.net Wed Oct 20 11:33:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 20 Oct 2021 11:33:06 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). Overriding the markword to return null for non-forwarded objs is indeed a bit hacky. However, from a caller's perspective, this is the most intuitive one. Taking `G1FullGCCompactTask::G1CompactRegionClosure::apply` as an example: HeapWord* destination = cast_from_oop(obj->forwardee()); if (destination == NULL) { // Object not moving return size; } ... Copy::aligned_conjoint_words(obj_addr, destination, size); `destination` is either null (obj is not moved) or the new location after moving; rather smooth and straightforward control flow. I wonder if we can use this pattern without overriding the markdown. Here's a straw man proposal. oop oopDesc::forwardee() const { auto mark_word = mark(); bool is_forwarded = mark_word.is_marked(); if (!is_forwarded) { return nullptr; } return cast_to_oop(mark_word.decode_pointer()); } The intention is to load the markword only once. Additionally, callers can continue using the `is_forwarded() / forwardee()` pair, or switch to the `forwardee() == nullptr` pattern on a case-by-case basis if desired. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Wed Oct 20 11:37:06 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Oct 2021 11:37:06 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 20:58:49 GMT, Stefan Karlsson wrote: > I like how the mark/is_marked/decode_pointer code gets cleaned up. And having an OopForwading class probably makes sense for parts of the code. > > I'm less excited about the way the explicitly stack allocated OopForwarding objects make the code less readable. Take these two examples: > > ``` > assert(old->is_objArray(), "invariant"); > - assert(old->is_forwarded(), "invariant"); > + assert(OopForwarding(old).is_forwarded(), "invariant"); > ``` > > ``` > oop new_obj = obj->is_forwarded() ? obj->forwardee() > : _young_gen->copy_to_survivor_space(obj); > OopForwarding fwd(obj); > oop new_obj = fwd.is_forwarded() ? fwd.forwardee() > : _young_gen->copy_to_survivor_space(obj); > ``` > > I think both snippets were nicer to read in the earlier code. And there's a lot of those kind of changes in this patch. > > Maybe there's a hybrid approach where we could still have oopDesc::is_forwarded, oopDesc::forwardee, etc. but also have OopForwarding objects for those places that really need them? And then minimize the amount of places we use `OopForwarding fwd(obj)` and `OopForwarding(obj)->forwardee()` in the code? In the first snippet, there is only one usage of the mark-word, i.e. no problem to simplify that. However, in the 2nd snippet, the point is that we can avoid loading the mark-word twice, and if we want to do that, we need an enclosing scope. The alternative would be to do something like: markWord mark = obj->mark(); oop fwd = mark->is_forwarded() ? mark->forwardee() : something_else(); ... which is pretty much the same as what I proposed, except that the markWord and the logic is encapsulated in OopForwarding. Notice that in some cases we actually already do that - those are the 'messy' cases where we deliberately load the mark-word once, and drag it through the code that needs it (sometimes not only for performance but also for correctness in the face of concurrency) - and the use is_marked() and decode_pointer() on it. Given that I have not been able to show performance benefits, I could revert cases like you mentioned to their original form, and consolidate the implementation into markWord, unless we prefer the most efficient solution everywhere. ? ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Wed Oct 20 11:46:13 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 11:46:13 GMT Subject: RFR: 8274910: Compile in G1 evacuation failure injection code based on define [v2] In-Reply-To: References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: On Mon, 18 Oct 2021 14:38:05 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> ayang review > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @kstefanj for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5851 From tschatzl at openjdk.java.net Wed Oct 20 11:46:13 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 11:46:13 GMT Subject: Integrated: 8274910: Compile in G1 evacuation failure injection code based on define In-Reply-To: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> References: <8NWuQDITOKneGUOrwu-OoBBJiF6Zmcd41SLtGfmU4do=.e368e3ff-ef2f-4108-a2d7-67be028af844@github.com> Message-ID: On Thu, 7 Oct 2021 14:25:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that simplifies performance work with evacuation failure handling a little? In particular, it adds a define called `EVAC_FAILURE_INJECTOR` (on by default in non-product builds) that allows to compile in/out the relevant injector code also in product mode (if manually enabled). > > Actually, this PR suggests two variants for this: one that also automatically enables flags when `EVAC_FAILURE_INJECTOR` is selected (beaa6c3), and one that requires the developer also change the options from develop/notproduct to product to be available (9f07ffd). > > The first is maybe makes the change a bit too hacky in `g1_globals.hpp` (unless there are ways to do that better, i.e. I could move the `GC_G1_EVACUATION_FAILURE_FLAGS` somewhere, or there is a much better preprocessor trick here, so I would like to have you decide. > > Testing: gha, manual checking that in product mode by default no evacuation failure handling is in, but with the flag, and otherwise the same as before, tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 50a57238 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/50a57238a8e34a976354b1de91c14cddacb3d88f Stats: 122 lines in 6 files changed: 77 ins; 29 del; 16 mod 8274910: Compile in G1 evacuation failure injection code based on define Reviewed-by: sjohanss, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5851 From tschatzl at openjdk.java.net Wed Oct 20 12:00:12 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 12:00:12 GMT Subject: RFR: 8275607 G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:57:28 GMT, Hamlin Li wrote: > This is a follow-up of JDK-8273626. > > G1CardSetAllocator::drop_all should call call G1SegmentedArray::drop_all to put all buffers into buffer free list, which is the original behavior of G1CardSetAllocator. Lgtm. Thanks for fixing this. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6035 From tschatzl at openjdk.java.net Wed Oct 20 12:01:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 12:01:07 GMT Subject: RFR: 8274988 G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:41:01 GMT, Hamlin Li wrote: > This is a follow-up of JDK-8273626. (something mentioned in Description was already done in JDK-8273626) > Some other cleanups need to be done: > Some fields of G1SegmentedArrayAllocOptions better be reloated to G1CardSetAllocOptions, and some fields are const, and also adds some assert. Marked as reviewed by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1CardSetMemory.hpp line 57: > 55: > 56: virtual uint next_num_elems(uint prev_num_elems) const override { > 57: assert(_alignment == BufferAlignment, "Must be"); I think this is unnecessary - we pass that value in the constructor and it is `const`, so there is a high chance this is correct. Lgtm otherwise, I do not need to re-review if you decide to drop this assert. ------------- PR: https://git.openjdk.java.net/jdk/pull/6032 From tschatzl at openjdk.java.net Wed Oct 20 12:07:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 12:07:07 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:45:38 GMT, Hamlin Li wrote: > 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1CardSet.cpp line 51: > 49: G1RemSetArrayOfCardsEntries, > 50: (double)G1RemSetCoarsenHowlBitmapToHowlFullPercent / 100, > 51: 0, Mabye add a `/* max_buckets_in_howl */` comment here to the right of the value. src/hotspot/share/gc/g1/g1CardSet.hpp line 67: > 65: void init(uint inline_ptr_bits_per_card, > 66: uint num_cards_in_array, > 67: double cards_in_bitmap_threshold, To avoid confusion with the actual "threshold" variables I would prefer if these were named "threshold_percent" (or ratio because our percent values are typically ranging from 0 to 100). At least it's confusing in the `init` implementation when it reads: _something = some_variable * something I.e. `something` not directly assigned to `_something` like other code. ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From tschatzl at openjdk.java.net Wed Oct 20 12:22:09 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 12:22:09 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v3] In-Reply-To: References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: On Wed, 20 Oct 2021 09:48:35 GMT, Hamlin Li wrote: >> This is a follow-up of JDK-8273626. >> >> Current (original) implementation just drops the newly allocated G1SegmentedArrayBuffer if current thread fails race, but seems reuse (e.g adding to freelist) will bring some benefit. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix cransh on Mac; remove unnecessary code Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 70: > 68: template > 69: void G1SegmentedArrayBufferList::add(G1SegmentedArrayBuffer& elem) { > 70: _list.prepend(elem); Not sure why the `prepend` is used here, but probably because of the previous implementation which has been dead code. I do not see an advantage pushing this element onto the bottom of the stack. I.e. I'd just `push()` it. Note that this change (in general) also breaks the assumptions stated in the documentation of `G1SegmentedArrayBufferList` - that's not a problem as far as I can see (push/pop use the correct synchronization), but the text needs to be adapted. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 87: > 85: G1SegmentedArrayBuffer* result = _list.pop(); > 86: if (result != nullptr) { > 87: Atomic::sub(&_num_buffers, (size_t)1,memory_order_relaxed); This is to use the same method in this and the next line? Anyway, there should be a space before the `memory_order_relaxed`. Since `add()` also uses `inc()` this does not seem consistent. Or is there another reason? I would just keep it as is. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 143: > 141: if (old != prev) { > 142: next->set_next(nullptr); > 143: // reuse the newly allocated or poped buffer by adding it into free buffer list. s/poped/popped ------------- PR: https://git.openjdk.java.net/jdk/pull/6034 From stefank at openjdk.java.net Wed Oct 20 12:59:08 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 20 Oct 2021 12:59:08 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc I don't think we should make the code more complicated by using the micro optimized version unless we can measure the benefits. IMHO, it is harder to read and it makes it more difficult to know if the read-once of was done for correctness purposes or not. I understand that that other reviewers might disagree with my view, and if that's the case, then I'll back off. Some concrete feedback on the current patch: I don't like that we store the oop in the OopForwarding. That oop gets snuck into functions via the fwd variable. That makes it less obvious that the functions depend on the old oop. Code like the following becomes more obscure, when you don't immediately see that it operates on the original (old) object: const oop forward_ptr = fwd.forward_to_atomic(obj, memory_order_relaxed); if (forward_ptr == NULL) { I wonder if it wouldn't make sense to make forward_to_atomic static, just like the forward_to is static? That way we wouldn't have to store _obj in OopForwarding, and I think the code would be more decoupled and easier to read. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From stefank at openjdk.java.net Wed Oct 20 14:01:12 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 20 Oct 2021 14:01:12 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5 and here it is on-top of your branch: https://github.com/openjdk/jdk/compare/master...stefank:pr_5955 ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Wed Oct 20 14:17:05 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 20 Oct 2021 14:17:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc > Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: [stefank at 58732bc](https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5) > > and here it is on-top of your branch: [master...stefank:pr_5955](https://github.com/openjdk/jdk/compare/master...stefank:pr_5955) > Here's what this would look like with a static OopForwarding. The OopForwarding objects are kept local to the function they are created in: [stefank at 58732bc](https://github.com/stefank/jdk/commit/58732bcfbc5b86ba872ea86cb224d6007be70da5) > > and here it is on-top of your branch: [master...stefank:pr_5955](https://github.com/openjdk/jdk/compare/master...stefank:pr_5955) Thanks! Yes this is indeed better. I will merge into this PR as soon as I get to it. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From ayang at openjdk.java.net Wed Oct 20 15:13:07 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 20 Oct 2021 15:13:07 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v5] In-Reply-To: <14cthBMEV7tbAQLstd0sWtKQPQyYtYPIfojoqOJ0olk=.642036ef-a5f8-4fa4-bd36-86db7ee6b9eb@github.com> References: <14cthBMEV7tbAQLstd0sWtKQPQyYtYPIfojoqOJ0olk=.642036ef-a5f8-4fa4-bd36-86db7ee6b9eb@github.com> Message-ID: On Tue, 19 Oct 2021 14:12:20 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. >> >> It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. >> >> Testing: gha, gc/g1 local testing. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix windows compilation `_heap_base_address` feels more natural to live in `G1CollectedHeap`. Anyway, this is very subjective. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5895 From ayang at openjdk.java.net Wed Oct 20 15:26:08 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 20 Oct 2021 15:26:08 GMT Subject: RFR: 8275607 G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:57:28 GMT, Hamlin Li wrote: > This is a follow-up of JDK-8273626. > > G1CardSetAllocator::drop_all should call call G1SegmentedArray::drop_all to put all buffers into buffer free list, which is the original behavior of G1CardSetAllocator. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6035 From ayang at openjdk.java.net Wed Oct 20 15:30:10 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 20 Oct 2021 15:30:10 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:45:38 GMT, Hamlin Li wrote: > 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. Instead of introducing a `init` method, I think [delegating constructor](https://en.cppreference.com/w/cpp/language/constructor) is designed for this use case. ------------- Changes requested by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6033 From ayang at openjdk.java.net Wed Oct 20 15:35:09 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 20 Oct 2021 15:35:09 GMT Subject: RFR: 8274988 G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:41:01 GMT, Hamlin Li wrote: > This is a follow-up of JDK-8273626. (something mentioned in Description was already done in JDK-8273626) > Some other cleanups need to be done: > Some fields of G1SegmentedArrayAllocOptions better be reloated to G1CardSetAllocOptions, and some fields are const, and also adds some assert. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6032 From tschatzl at openjdk.java.net Wed Oct 20 15:38:24 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 15:38:24 GMT Subject: RFR: 8275055: Improve HeapRegionRemSet::split_card() [v5] In-Reply-To: References: <14cthBMEV7tbAQLstd0sWtKQPQyYtYPIfojoqOJ0olk=.642036ef-a5f8-4fa4-bd36-86db7ee6b9eb@github.com> Message-ID: On Wed, 20 Oct 2021 15:09:56 GMT, Albert Mingkun Yang wrote: > `_heap_base_address` feels more natural to live in `G1CollectedHeap`. Anyway, this is very subjective. The local cached copy is intentional: we do not want the extra indirection via `G1CollectedHeap::heap()`; otherwise we could simply use `G1CollectedHeap::heap()->reserved().start()` there instead. Thanks @albertnetymk @kstefanj and @kimbarrett for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5895 From tschatzl at openjdk.java.net Wed Oct 20 15:38:26 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 20 Oct 2021 15:38:26 GMT Subject: Integrated: 8275055: Improve HeapRegionRemSet::split_card() In-Reply-To: References: Message-ID: On Mon, 11 Oct 2021 15:11:12 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small change that improves HeapRegionRemSet::split_card() by reducing the number of (direct and indirect) memory accesses for it. It is hard to actually measure improvements because it's only called in concurrent code. So no particular improvements measured. > > It also prepares that method for virtualizing the remembered set containers, allowing arbitrarily large heap region sizes [JDK-8275056](https://bugs.openjdk.java.net/browse/JDK-8275056). This change is required then because the splitting of a card index into "region" and "card within region" should not be dependent on *heap regions*. > > Testing: gha, gc/g1 local testing. > > Thanks, > Thomas This pull request has now been integrated. Changeset: 7e28bdd1 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/7e28bdd1eb8276a5f78802febc9bd6f1cf597f55 Stats: 85 lines in 7 files changed: 82 ins; 0 del; 3 mod 8275055: Improve HeapRegionRemSet::split_card() Reviewed-by: sjohanss, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/5895 From mli at openjdk.java.net Thu Oct 21 01:19:09 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 01:19:09 GMT Subject: RFR: 8275607 G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all In-Reply-To: References: Message-ID: <4OC8GWsLn0OOFnBoWYAHZvFOI7Xe4bcK215wpLON9lU=.c65b956c-42cf-4cc7-839a-8f9b70907726@github.com> On Wed, 20 Oct 2021 11:56:37 GMT, Thomas Schatzl wrote: >> This is a follow-up of JDK-8273626. >> >> G1CardSetAllocator::drop_all should call call G1SegmentedArray::drop_all to put all buffers into buffer free list, which is the original behavior of G1CardSetAllocator. > > Lgtm. Thanks for fixing this. Thanks @tschatzl @albertnetymk for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/6035 From mli at openjdk.java.net Thu Oct 21 01:19:09 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 01:19:09 GMT Subject: Integrated: 8275607 G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:57:28 GMT, Hamlin Li wrote: > This is a follow-up of JDK-8273626. > > G1CardSetAllocator::drop_all should call call G1SegmentedArray::drop_all to put all buffers into buffer free list, which is the original behavior of G1CardSetAllocator. This pull request has now been integrated. Changeset: c7a80e60 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/c7a80e60e2e201b573d4653fa978df527addc8a6 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8275607: G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/6035 From mli at openjdk.java.net Thu Oct 21 01:22:37 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 01:22:37 GMT Subject: RFR: 8274988 G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions [v2] In-Reply-To: References: Message-ID: > This is a follow-up of JDK-8273626. (something mentioned in Description was already done in JDK-8273626) > Some other cleanups need to be done: > Some fields of G1SegmentedArrayAllocOptions better be reloated to G1CardSetAllocOptions, and some fields are const, and also adds some assert. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary asserts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6032/files - new: https://git.openjdk.java.net/jdk/pull/6032/files/e9235916..c593e311 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6032&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6032&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6032.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6032/head:pull/6032 PR: https://git.openjdk.java.net/jdk/pull/6032 From mli at openjdk.java.net Thu Oct 21 01:22:40 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 01:22:40 GMT Subject: RFR: 8274988 G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions [v2] In-Reply-To: References: Message-ID: <-YmzlmRTf5kqgm5BPjgb9MTl8veuPy9olYWV1M_0g_I=.326fb905-e948-44bd-b107-cb8954f8679c@github.com> On Wed, 20 Oct 2021 11:58:19 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unnecessary asserts > > Marked as reviewed by tschatzl (Reviewer). Thanks @tschatzl @albertnetymk for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/6032 From mli at openjdk.java.net Thu Oct 21 01:22:42 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 01:22:42 GMT Subject: Integrated: 8274988 G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:41:01 GMT, Hamlin Li wrote: > This is a follow-up of JDK-8273626. (something mentioned in Description was already done in JDK-8273626) > Some other cleanups need to be done: > Some fields of G1SegmentedArrayAllocOptions better be reloated to G1CardSetAllocOptions, and some fields are const, and also adds some assert. This pull request has now been integrated. Changeset: a120937e Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/a120937e8194a897ed4af9e7a2e33beb857987e5 Stats: 15 lines in 2 files changed: 7 ins; 4 del; 4 mod 8274988: G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/6032 From mli at openjdk.java.net Thu Oct 21 01:57:09 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 01:57:09 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v3] In-Reply-To: References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: On Wed, 20 Oct 2021 12:14:29 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix cransh on Mac; remove unnecessary code > > src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 70: > >> 68: template >> 69: void G1SegmentedArrayBufferList::add(G1SegmentedArrayBuffer& elem) { >> 70: _list.prepend(elem); > > Not sure why the `prepend` is used here, but probably because of the previous implementation which has been dead code. > I do not see an advantage pushing this element onto the bottom of the stack. I.e. I'd just `push()` it. > > Note that this change (in general) also breaks the assumptions stated in the documentation of `G1SegmentedArrayBufferList` - that's not a problem as far as I can see (push/pop use the correct synchronization), but the text needs to be adapted. Do you mean modify it to something like: // Set of (free) G1SegmentedArrayBuffers. // Every action may be performed by multiple threads at the same time. // Counts and memory usage are current on a best-effort basis if accessed concurrently. ------------- PR: https://git.openjdk.java.net/jdk/pull/6034 From mli at openjdk.java.net Thu Oct 21 02:06:00 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 02:06:00 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 15:26:59 GMT, Albert Mingkun Yang wrote: > Instead of introducing a `init` method, I think [delegating constructor](https://en.cppreference.com/w/cpp/language/constructor) is designed for this use case. Thanks for discussing for this, I thought so at first, but I finally choose to use init instead, the reason in my mind is that _num_buckets_in_howl = G1CardSetHowl::num_buckets(_max_cards_in_card_set, _num_cards_in_array, max_buckets_in_howl); is specifically what's intended by G1CardSetConfiguration(/*with arguments*/), but _num_buckets_in_howl = G1RemSetHowlNumBuckets; is what's intended by G1CardSetConfiguration(). So I think it's better to use another method init(...), rather than mix the logic of G1CardSetConfiguration() into G1CardSetConfiguration(/*with arguments*/). How do you think about it? ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From mli at openjdk.java.net Thu Oct 21 04:01:05 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 04:01:05 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v3] In-Reply-To: References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: On Wed, 20 Oct 2021 09:48:35 GMT, Hamlin Li wrote: >> This is a follow-up of JDK-8273626. >> >> Current (original) implementation just drops the newly allocated G1SegmentedArrayBuffer if current thread fails race, but seems reuse (e.g adding to freelist) will bring some benefit. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix cransh on Mac; remove unnecessary code src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 144: > 142: next->set_next(nullptr); > 143: // reuse the newly allocated or poped buffer by adding it into free buffer list. > 144: _free_buffer_list->add(*next); Should we add GlobalCounter::write_synchronize() here? ------------- PR: https://git.openjdk.java.net/jdk/pull/6034 From stefank at openjdk.java.net Thu Oct 21 07:47:05 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 21 Oct 2021 07:47:05 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access In-Reply-To: References: Message-ID: On Thu, 14 Oct 2021 16:37:02 GMT, Roman Kennke wrote: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc A few more comments: src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 112: > 110: // since it will be restored by preserved marks. > 111: object->init_mark(); > 112: } else { Could you explain why this was removed? src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp line 142: > 140: OopForwarding fwd(o); > 141: if (!fwd.is_forwarded()) { > 142: return copy_unmarked_to_survivor_space(o, fwd); I wonder if this copy_unmarked should be renamed to copy_unforwarded? src/hotspot/share/gc/serial/defNewGeneration.cpp line 56: > 54: #include "oops/instanceRefKlass.hpp" > 55: #include "oops/oop.inline.hpp" > 56: #include "oops/oopForwarding.hpp" The patch is inconsistent w.r.t. the include order between oop.inline.hpp and oopForwarding.hpp. src/hotspot/share/oops/oopForwarding.hpp line 83: > 81: #endif > 82: #endif > 83: } This should preferable be in a .cpp file, though it seems excessive to introduce one just for this case. Since it is only used by the forward_to functions, maybe add it to the suggested oopForwarding.inline.hpp file? src/hotspot/share/oops/oopForwarding.hpp line 125: > 123: return cast_to_oop(old_mark.decode_pointer()); > 124: } > 125: } The forward_to functions uses functions in oop.inline.hpp. They need to be split out into a oopForwarding.inline.hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Thu Oct 21 07:58:16 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 21 Oct 2021 07:58:16 GMT Subject: RFR: 8275266: Virtualize G1CardSet containers over heap region Message-ID: Hi all, can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). There is also a CSR to look at. Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. Thanks, Thomas ------------- Commit messages: - Virtual heap regions in remembered sets Changes: https://git.openjdk.java.net/jdk/pull/6059/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275266 Stats: 212 lines in 10 files changed: 126 ins; 67 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Thu Oct 21 08:11:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 21 Oct 2021 08:11:07 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v3] In-Reply-To: References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: On Thu, 21 Oct 2021 03:58:03 GMT, Hamlin Li wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix cransh on Mac; remove unnecessary code > > src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 144: > >> 142: next->set_next(nullptr); >> 143: // reuse the newly allocated or poped buffer by adding it into free buffer list. >> 144: _free_buffer_list->add(*next); > > Should we add GlobalCounter::write_synchronize() here? If it's true, I'm a little bit concern about the performance. I think you are right about needing `write_synchronize` here - I mixed this up with `G1CardSetAllocator` which has the intermediate `_pending_list` to avoid excessive `write_synchronize` calls. If you think this is too expensive (it might well be!), let's just keep the `delete` for now. We can revisit this change when we have more measurements about this. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/6034 From mli at openjdk.java.net Thu Oct 21 09:20:09 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 21 Oct 2021 09:20:09 GMT Subject: RFR: 8274987 G1: reuse the newly allocated G1SegmentedArrayBuffer even if current thread failed the race [v3] In-Reply-To: References: <5kHIlEWS2ZQzEEGEaGaQx4yhH97CyGKHP09OPN3ZiE0=.3402bb69-9595-43ec-93de-80f71c5a67c0@github.com> Message-ID: On Thu, 21 Oct 2021 08:08:23 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 144: >> >>> 142: next->set_next(nullptr); >>> 143: // reuse the newly allocated or poped buffer by adding it into free buffer list. >>> 144: _free_buffer_list->add(*next); >> >> Should we add GlobalCounter::write_synchronize() here? If it's true, I'm a little bit concern about the performance. > > I think you are right about needing `write_synchronize` here - I mixed this up with `G1CardSetAllocator` which has the intermediate `_pending_list` to avoid excessive `write_synchronize` calls. > > If you think this is too expensive (it might well be!), let's just keep the `delete` for now. We can revisit this change when we have more measurements about this. > > Thanks, > Thomas Got it, Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/6034 From ayang at openjdk.java.net Thu Oct 21 10:36:20 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Oct 2021 10:36:20 GMT Subject: RFR: 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset Message-ID: Trivial change of removing unused variables. Test: build ------------- Commit messages: - g1policy Changes: https://git.openjdk.java.net/jdk/pull/6062/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6062&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275714 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6062.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6062/head:pull/6062 PR: https://git.openjdk.java.net/jdk/pull/6062 From tschatzl at openjdk.java.net Thu Oct 21 10:53:14 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 21 Oct 2021 10:53:14 GMT Subject: RFR: 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 10:28:28 GMT, Albert Mingkun Yang wrote: > Trivial change of removing unused variables. > > Test: build Lgtm and trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6062 From tschatzl at openjdk.java.net Thu Oct 21 10:53:37 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 21 Oct 2021 10:53:37 GMT Subject: RFR: 8275266: Virtualize G1CardSet containers over heap region [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? > > I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. > > When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). > > Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. > > One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). > > This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. > Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). > > There is also a CSR to look at. > > Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: 32 bit compatibility - limit region size to 32M there as before. Fix test. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6059/files - new: https://git.openjdk.java.net/jdk/pull/6059/files/68f3fc2d..216504de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=00-01 Stats: 9 lines in 2 files changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From coleenp at openjdk.java.net Thu Oct 21 11:52:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 21 Oct 2021 11:52:10 GMT Subject: RFR: 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 15:40:47 GMT, Coleen Phillimore wrote: > Move the initialization and potential class loading of the MethodType out of eatMemory so that we don't get this OOME while loading this class. > Tested with tier5 and 7. Thanks Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/5969 From coleenp at openjdk.java.net Thu Oct 21 11:52:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 21 Oct 2021 11:52:10 GMT Subject: Integrated: 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" In-Reply-To: References: Message-ID: On Fri, 15 Oct 2021 15:40:47 GMT, Coleen Phillimore wrote: > Move the initialization and potential class loading of the MethodType out of eatMemory so that we don't get this OOME while loading this class. > Tested with tier5 and 7. This pull request has now been integrated. Changeset: cd07b3ca Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/cd07b3cab00e6656e73a29f82210e2dedf26df8c Stats: 12 lines in 1 file changed: 5 ins; 5 del; 2 mod 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/5969 From kbarrett at openjdk.java.net Thu Oct 21 13:34:07 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Oct 2021 13:34:07 GMT Subject: RFR: 8275426: PretouchTask num_chunks calculation can overflow In-Reply-To: <1_bR8yuOvVIVs6P9rS1lSlq7s51-iiD_VjiF7QMUAqA=.5314ee8c-337f-49c0-ac12-20925df7b7e3@github.com> References: <1_bR8yuOvVIVs6P9rS1lSlq7s51-iiD_VjiF7QMUAqA=.5314ee8c-337f-49c0-ac12-20925df7b7e3@github.com> Message-ID: <_8Oh2knLp0Y3zYfjkNw6jegU-J0bq3SP4QKdEcN918E=.ad46d76d-321a-4d26-9d70-1616ae9af9d4@github.com> On Mon, 18 Oct 2021 19:27:46 GMT, Albert Mingkun Yang wrote: >> Please review this change to part of the calculation of the number of >> threads to apply to a PretouchTask when using a gang of worker threads. >> >> The previous calculation of the number of chunks in the range to be touched >> can overflow in the numerator. (This may only be a realistic problem on >> 32bit platforms. On 64bit platforms the value constraint on the chunk size >> and plausible or architectural limits on the size of the range probably >> prevent such overflow from occurring.) >> >> Testing: >> mach5 tier1 >> Locally (linux-x64) ran with logging of the pretouch parameters enabled, >> with various chunk sizes configured, and hand-checked the logged values. > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk and @tschatzl for reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/5993 From kbarrett at openjdk.java.net Thu Oct 21 13:34:08 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 21 Oct 2021 13:34:08 GMT Subject: Integrated: 8275426: PretouchTask num_chunks calculation can overflow In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 17:43:58 GMT, Kim Barrett wrote: > Please review this change to part of the calculation of the number of > threads to apply to a PretouchTask when using a gang of worker threads. > > The previous calculation of the number of chunks in the range to be touched > can overflow in the numerator. (This may only be a realistic problem on > 32bit platforms. On 64bit platforms the value constraint on the chunk size > and plausible or architectural limits on the size of the range probably > prevent such overflow from occurring.) > > Testing: > mach5 tier1 > Locally (linux-x64) ran with logging of the pretouch parameters enabled, > with various chunk sizes configured, and hand-checked the logged values. This pull request has now been integrated. Changeset: 60cb27dc Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/60cb27dcda475a66e329359ac1ee3ffcde95c657 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8275426: PretouchTask num_chunks calculation can overflow Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/5993 From ayang at openjdk.java.net Thu Oct 21 15:50:11 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Oct 2021 15:50:11 GMT Subject: RFR: 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset In-Reply-To: References: Message-ID: <30hllN158QAE20wGWRLrpQDgV43S4jDXcI0VzF5QrvI=.bbf28362-42dc-4306-b40d-ca1baff04648@github.com> On Thu, 21 Oct 2021 10:28:28 GMT, Albert Mingkun Yang wrote: > Trivial change of removing unused variables. > > Test: build Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6062 From ayang at openjdk.java.net Thu Oct 21 15:53:08 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 21 Oct 2021 15:53:08 GMT Subject: Integrated: 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset In-Reply-To: References: Message-ID: On Thu, 21 Oct 2021 10:28:28 GMT, Albert Mingkun Yang wrote: > Trivial change of removing unused variables. > > Test: build This pull request has now been integrated. Changeset: bef8cf1b Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/bef8cf1ba14d3846977942844f341f5c5a1f44c4 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/6062 From mli at openjdk.java.net Fri Oct 22 01:09:29 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 22 Oct 2021 01:09:29 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v2] In-Reply-To: References: Message-ID: > 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Refine naming ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6033/files - new: https://git.openjdk.java.net/jdk/pull/6033/files/17e85c3a..4908ac79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6033&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6033&range=00-01 Stats: 13 lines in 2 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/6033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6033/head:pull/6033 PR: https://git.openjdk.java.net/jdk/pull/6033 From ayang at openjdk.java.net Fri Oct 22 07:45:08 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 07:45:08 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v2] In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 01:09:29 GMT, Hamlin Li wrote: >> 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Refine naming I overlooked the `_num_buckets_in_howl` issue at that time. How about using 3 constructors? Sth like: https://github.com/openjdk/jdk/compare/master...albertnetymk:2-ctor?expand=1 PS: I didn't test it much; it's just to show the gist. ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From ayang at openjdk.java.net Fri Oct 22 10:20:14 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 10:20:14 GMT Subject: RFR: 8275783: G1: fix incorrect region type documentation in HeapRegionType Message-ID: Trivial change of fixing documentation. ------------- Commit messages: - region-type Changes: https://git.openjdk.java.net/jdk/pull/6079/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6079&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275783 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6079.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6079/head:pull/6079 PR: https://git.openjdk.java.net/jdk/pull/6079 From tschatzl at openjdk.java.net Fri Oct 22 10:51:04 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 22 Oct 2021 10:51:04 GMT Subject: RFR: 8275783: G1: fix incorrect region type documentation in HeapRegionType In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:12:00 GMT, Albert Mingkun Yang wrote: > Trivial change of fixing documentation. Good and trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6079 From mli at openjdk.java.net Fri Oct 22 11:04:28 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 22 Oct 2021 11:04:28 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v3] In-Reply-To: References: Message-ID: > 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Refine code further ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6033/files - new: https://git.openjdk.java.net/jdk/pull/6033/files/4908ac79..1cfcef49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6033&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6033&range=01-02 Stats: 87 lines in 3 files changed: 33 ins; 29 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/6033.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6033/head:pull/6033 PR: https://git.openjdk.java.net/jdk/pull/6033 From mli at openjdk.java.net Fri Oct 22 11:04:29 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 22 Oct 2021 11:04:29 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v2] In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 01:09:29 GMT, Hamlin Li wrote: >> 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Refine naming Thanks Albert, I like the idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From sjohanss at openjdk.java.net Fri Oct 22 11:40:10 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 22 Oct 2021 11:40:10 GMT Subject: RFR: 8275416: G1: remove unnecesary make_referent_alive in precleaning phase In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 11:02:17 GMT, Albert Mingkun Yang wrote: > Simple change of removing marking work in G1 precleaning. Evaluation using a contrived example shows ~20% reduction in precleaning. > > Test: hotspot_gc Looks good. I would love if the PR summary would contain a bit information. More or less just a copy of what's in the JBS description. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6003 From ayang at openjdk.java.net Fri Oct 22 12:53:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 12:53:06 GMT Subject: RFR: 8275783: G1: fix incorrect region type documentation in HeapRegionType In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:12:00 GMT, Albert Mingkun Yang wrote: > Trivial change of fixing documentation. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6079 From ayang at openjdk.java.net Fri Oct 22 12:53:06 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 12:53:06 GMT Subject: Integrated: 8275783: G1: fix incorrect region type documentation in HeapRegionType In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 10:12:00 GMT, Albert Mingkun Yang wrote: > Trivial change of fixing documentation. This pull request has now been integrated. Changeset: dd622e55 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/dd622e55c01966f8b2deddaba09164a0a302df2e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8275783: G1: fix incorrect region type documentation in HeapRegionType Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/6079 From ayang at openjdk.java.net Fri Oct 22 12:55:05 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 12:55:05 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v3] In-Reply-To: References: Message-ID: On Fri, 22 Oct 2021 11:04:28 GMT, Hamlin Li wrote: >> 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Refine code further I think it's better not to pollute the public API with test-only methods. Anyway, it's quite subjective. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6033 From ayang at openjdk.java.net Fri Oct 22 13:05:10 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 13:05:10 GMT Subject: RFR: 8275416: G1: remove unnecessary make_referent_alive in precleaning phase In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 11:02:17 GMT, Albert Mingkun Yang wrote: > Simple change of removing marking work in G1 precleaning. Evaluation using a contrived example shows ~20% reduction in precleaning. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6003 From ayang at openjdk.java.net Fri Oct 22 13:05:11 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 22 Oct 2021 13:05:11 GMT Subject: Integrated: 8275416: G1: remove unnecessary make_referent_alive in precleaning phase In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 11:02:17 GMT, Albert Mingkun Yang wrote: > Simple change of removing marking work in G1 precleaning. Evaluation using a contrived example shows ~20% reduction in precleaning. > > Test: hotspot_gc This pull request has now been integrated. Changeset: 4e647aa5 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/4e647aa584cf12dae76e81e203ad4f1ebc08c1a2 Stats: 42 lines in 3 files changed: 2 ins; 26 del; 14 mod 8275416: G1: remove unnecessary make_referent_alive in precleaning phase Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/6003 From tschatzl at openjdk.java.net Sun Oct 24 19:00:07 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Sun, 24 Oct 2021 19:00:07 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v3] In-Reply-To: References: Message-ID: <48KZhV3VZ9b8gUGohlcvy3yShIgmmB4UA4F7WrhE3yc=.3a82f46d-10fc-4f3c-ad3f-52649bde25fa@github.com> On Fri, 22 Oct 2021 11:04:28 GMT, Hamlin Li wrote: >> 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Refine code further Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From mli at openjdk.java.net Mon Oct 25 01:07:06 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 25 Oct 2021 01:07:06 GMT Subject: RFR: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration [v3] In-Reply-To: <48KZhV3VZ9b8gUGohlcvy3yShIgmmB4UA4F7WrhE3yc=.3a82f46d-10fc-4f3c-ad3f-52649bde25fa@github.com> References: <48KZhV3VZ9b8gUGohlcvy3yShIgmmB4UA4F7WrhE3yc=.3a82f46d-10fc-4f3c-ad3f-52649bde25fa@github.com> Message-ID: On Sun, 24 Oct 2021 18:57:05 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine code further > > Marked as reviewed by tschatzl (Reviewer). Thanks @tschatzl @albertnetymk for your reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From mli at openjdk.java.net Mon Oct 25 01:07:06 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 25 Oct 2021 01:07:06 GMT Subject: Integrated: 8275381 G1: refactor 2 constructors of G1CardSetConfiguration In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 08:45:38 GMT, Hamlin Li wrote: > 2 constructors of G1CardSetConfiguration share some code, it's better to refacoring them to simplify the code. This pull request has now been integrated. Changeset: 5dab76b9 Author: Hamlin Li URL: https://git.openjdk.java.net/jdk/commit/5dab76b939e381312ce5c89b9aebca628238a387 Stats: 66 lines in 3 files changed: 20 ins; 10 del; 36 mod 8275381: G1: refactor 2 constructors of G1CardSetConfiguration Reviewed-by: tschatzl, ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/6033 From mli at openjdk.java.net Mon Oct 25 07:54:25 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 25 Oct 2021 07:54:25 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v8] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge branch 'master' into speedup-iterate-evac-failure-objs-in-one-region - Fix compilation error on windows - Fix compilation error on windows - Fix test failures; Fix compilation failures on some platforms - Fix test failures; Fix compilation failures on some platforms - Fix compilation issues on some platform. - Use a segmented array rather than a linked list to record evacuation failure objs in one region - fix: reset state after iteration - speed up iterate evac failure objs in one region. ------------- Changes: https://git.openjdk.java.net/jdk/pull/5181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=07 Stats: 416 lines in 6 files changed: 384 ins; 1 del; 31 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Mon Oct 25 09:08:33 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 25 Oct 2021 09:08:33 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v9] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Fix wrong merge ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/43a8b590..61323729 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From sjohanss at openjdk.java.net Mon Oct 25 13:04:01 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 25 Oct 2021 13:04:01 GMT Subject: RFR: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr [v2] In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 14:26:17 GMT, Albert Mingkun Yang wrote: >> Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6013 From ayang at openjdk.java.net Mon Oct 25 13:21:11 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 25 Oct 2021 13:21:11 GMT Subject: RFR: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr [v2] In-Reply-To: References: Message-ID: <3Azg0EZiVrNtVeEN1kZ9FH6mQsnmasQPlgSSxBIhp5Y=.126d4443-c59d-4764-a560-f5cde62a3f8d@github.com> On Tue, 19 Oct 2021 14:26:17 GMT, Albert Mingkun Yang wrote: >> Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. >> >> Test: build > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6013 From ayang at openjdk.java.net Mon Oct 25 13:21:11 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 25 Oct 2021 13:21:11 GMT Subject: Integrated: 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr In-Reply-To: References: Message-ID: On Tue, 19 Oct 2021 13:55:25 GMT, Albert Mingkun Yang wrote: > Simple renaming of `G1HeapRegionAttr::_needs_remset_update` and methods/variables involved in the call chain. > > Test: build This pull request has now been integrated. Changeset: 7f94302c Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/7f94302ceca001ded89ba9a653bf176ef90b16cd Stats: 27 lines in 7 files changed: 0 ins; 0 del; 27 mod 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/6013 From mli at openjdk.java.net Mon Oct 25 14:50:39 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Mon, 25 Oct 2021 14:50:39 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v10] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Use refactored G1SegmentedArray rather than home-made Array+Node ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/61323729..44e35620 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=08-09 Stats: 301 lines in 4 files changed: 99 ins; 180 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From ayang at openjdk.java.net Mon Oct 25 18:38:15 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 25 Oct 2021 18:38:15 GMT Subject: RFR: 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size Message-ID: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> Trivial change of removing obsolete comment. ------------- Commit messages: - comment Changes: https://git.openjdk.java.net/jdk/pull/6113/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6113&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275886 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6113.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6113/head:pull/6113 PR: https://git.openjdk.java.net/jdk/pull/6113 From mli at openjdk.java.net Tue Oct 26 02:01:49 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 26 Oct 2021 02:01:49 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v11] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Add asserts, comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/44e35620..e779c3a7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=09-10 Stats: 7 lines in 4 files changed: 2 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Tue Oct 26 02:05:12 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 26 Oct 2021 02:05:12 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v7] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:44:58 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compilation error on windows > > Performance is good as is, particularly the Remove self-forwards phase is much much faster now. I added a figure to the CR [here](https://bugs.openjdk.java.net/secure/attachment/96321/20210902-remove-self-forwards-improvement.png). Really nice. > > Although there are a few existing abnormalities with this change (not newly introduced, the old code is as bad), see [JDK-8273309](https://bugs.openjdk.java.net/browse/JDK-8273309). > > There are a few things that need to be improved: > * we talked about this before, but I do not think putting `G1EvacuationFailureObjsInHR`, which is something only used in evacuation failure, into `HeapRegion`, should be done. At least at the moment, it is almost never used. > * I do not like the use and the implementation of `G1EvacuationFailureObjsInHR`: it recreates something thatt is done better elsewhere (mark stack, DCQS buffer allocator, and in particular in the remembered set cardset allocator) with less features, in a non-fitting style. > Examples are something like reuse of available chunks, concurrent freeing of chunks, automatic resizing of blocks on demand to decrease allocations and potentially other stuff seems something we would really really want. > * as far as I understand the implementation of `G1EvacuationFailureObjsInHR` ;) - there is zero documentation about the basic structure - it seems to allocate quite a lot of memory that is almost never used. Even in the case of evacuation failure it's likely to be almost empty. > `G1EvacuationFailureObjsInHR` seems to basically be a preallocated `ArrayList` of chunks (the `_array_list` member). > Afaict it uses like 1/256 of total heap size (i.e. 0.3%), that's way way too much ( 1 / (256 * sizeof(HeapWord)) * sizeof(pointer); in `G1EvacuationFailureObjsInHR.cpp:86`; the `Array` constructor in `G1EvacuationFailureObjsInHR.hpp:124)) ). We will also get into trouble about startup time about this, I'm sure. That, tbh, alone makes it a no-go if I did not miscalculate. > > Let's work on renaming and reusing the infrastructure provided by the remembered set (`G1CardSetAllocator` etc) in `g1CardSetMemory.hpp`. @tschatzl Hi Thomas, as we discussed earlier, failed object array should be attached to HeapRegion, and a new container data structure will be added in 8272978, I see 8272978 is still in progress, so for now do you think it's OK for me to just attach G1EvacuationFailureObjsInHR to HeapRegion, and later refactor it after 8272978? ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Tue Oct 26 04:47:59 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Tue, 26 Oct 2021 04:47:59 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v12] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/e779c3a7..924fec5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=10-11 Stats: 243 lines in 4 files changed: 119 ins; 119 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From sjohanss at openjdk.java.net Tue Oct 26 14:08:10 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 26 Oct 2021 14:08:10 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v5] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 09:32:40 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with three additional commits since the last revision: > > - Removed additional thread and card set code > - Switch to dcq and refinement threads to manage the plab cards > - Trivial I've looked through the patch but won't focus on reviewing this right now. I've instead spent time on running some testing on it comparing it to my approach of doing the work inside the pause. Some observations: - Both our approaches touches the hot-path and add code to `do_copy_to_survivor_space(...)`, I don't see any clear regression in object copy times for either approach which is very good. - I also see a clear reduction in scan times for both approaches, but not as big when doing the work concurrently. This could be because not everything gets updated between the pauses. - The "Total refinement" time (`-Xlog:gc+refine+stats`) also goes down with both approaches, quite significantly, but again the decrease is bigger when doing the work in the pause. This is not so surprising since no additional work is added to the refinement threads for my approach. I have also done a very hacky PoC that updates all new old regions concurrently using the G1 service thread. This approach doesn't need to touch the object copy path but instead just records that any new old region needs to be "fixed". This approach looks very good from a pause time perspective, but just using one thread doesn't scale very well. One problem I see with using the refinement threads (to allow scaling better) is that it will probably make the heuristic for scaling the number of threads a bit more complicated, because there are two types of work that should be handled. Have you thought anything about that? One way forward would be to first go with a solution doing the work inside the pause and then continue investigating how to move it to concurrent threads in an efficient and maintainable way. ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From mli at openjdk.java.net Wed Oct 27 06:33:12 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Wed, 27 Oct 2021 06:33:12 GMT Subject: RFR: 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size In-Reply-To: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> References: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> Message-ID: On Mon, 25 Oct 2021 18:29:27 GMT, Albert Mingkun Yang wrote: > Trivial change of removing obsolete comment. LGTM ------------- Marked as reviewed by mli (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6113 From tschatzl at openjdk.java.net Wed Oct 27 07:55:12 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 07:55:12 GMT Subject: RFR: 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size In-Reply-To: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> References: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> Message-ID: On Mon, 25 Oct 2021 18:29:27 GMT, Albert Mingkun Yang wrote: > Trivial change of removing obsolete comment. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6113 From ayang at openjdk.java.net Wed Oct 27 08:28:19 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 27 Oct 2021 08:28:19 GMT Subject: RFR: 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size In-Reply-To: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> References: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> Message-ID: On Mon, 25 Oct 2021 18:29:27 GMT, Albert Mingkun Yang wrote: > Trivial change of removing obsolete comment. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6113 From ayang at openjdk.java.net Wed Oct 27 08:28:19 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 27 Oct 2021 08:28:19 GMT Subject: Integrated: 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size In-Reply-To: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> References: <12DcIBtpKUVrUWovReRbrn-WZXLXK5rqBvTZYwfsW2Q=.6c126c45-c3fd-444e-ae99-301bfc813df6@github.com> Message-ID: On Mon, 25 Oct 2021 18:29:27 GMT, Albert Mingkun Yang wrote: > Trivial change of removing obsolete comment. This pull request has now been integrated. Changeset: 9e831bcc Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/9e831bccd2fc90681b32d1504eca753462afc6f6 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size Reviewed-by: mli, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/6113 From duke at openjdk.java.net Wed Oct 27 08:47:15 2021 From: duke at openjdk.java.net (Yude Lin) Date: Wed, 27 Oct 2021 08:47:15 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v5] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 14:04:58 GMT, Stefan Johansson wrote: > I've looked through the patch but won't focus on reviewing this right now. I've instead spent time on running some testing on it comparing it to my approach of doing the work inside the pause. > > Some observations: > > * Both our approaches touches the hot-path and add code to `do_copy_to_survivor_space(...)`, I don't see any clear regression in object copy times for either approach which is very good. > * I also see a clear reduction in scan times for both approaches, but not as big when doing the work concurrently. This could be because not everything gets updated between the pauses. > * The "Total refinement" time (`-Xlog:gc+refine+stats`) also goes down with both approaches, quite significantly, but again the decrease is bigger when doing the work in the pause. This is not so surprising since no additional work is added to the refinement threads for my approach. > > I have also done a very hacky PoC that updates all new old regions concurrently using the G1 service thread. This approach doesn't need to touch the object copy path but instead just records that any new old region needs to be "fixed". This approach looks very good from a pause time perspective, but just using one thread doesn't scale very well. > > One problem I see with using the refinement threads (to allow scaling better) is that it will probably make the heuristic for scaling the number of threads a bit more complicated, because there are two types of work that should be handled. Have you thought anything about that? > I admit this is a bit hacky too. I noticed it breaks the heuristics, but just wanted to put this out for more discussion before I make the heuristics more complicated. Chances are that this solution has other unresolved problems (like mutator stall) and we won't go down this path and then I don't have to work on the heuristics. Sorry for being lazy here ; ) > One way forward would be to first go with a solution doing the work inside the pause and then continue investigating how to move it to concurrent threads in an efficient and maintainable way. >From these results, it looks like maintaining a precise BOT(that is, every entry points to an actual object start, not plab start) during evacuation isn't very costly in the first place. Maybe the pause-time solution is the best move for now. So if the direction is set, how do we go about making it happen? Do we change this pr for that purpose or do you want to submit another pr? I'm happy to contribute just so you know. ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From ayang at openjdk.java.net Wed Oct 27 08:58:28 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 27 Oct 2021 08:58:28 GMT Subject: RFR: 8276047: G1: refactor G1CardSetArrayLocker Message-ID: Simple refactoring in `G1CardSetArrayLocker`: 1. rename fields to sth more explicit 2. drop `volatile` for thread-local variables 3. increment directly without treating `bool` as an integer Test: hotspot_gc ------------- Commit messages: - cleanup Changes: https://git.openjdk.java.net/jdk/pull/6134/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6134&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276047 Stats: 21 lines in 2 files changed: 3 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6134.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6134/head:pull/6134 PR: https://git.openjdk.java.net/jdk/pull/6134 From tschatzl at openjdk.java.net Wed Oct 27 09:14:12 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 09:14:12 GMT Subject: RFR: 8276047: G1: refactor G1CardSetArrayLocker In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 08:52:08 GMT, Albert Mingkun Yang wrote: > Simple refactoring in `G1CardSetArrayLocker`: > > 1. rename fields to sth more explicit > 2. drop `volatile` for thread-local variables > 3. increment directly without treating `bool` as an integer > > Test: hotspot_gc Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6134 From tschatzl at openjdk.java.net Wed Oct 27 10:04:29 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 10:04:29 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? > > I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. > > When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). > > Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. > > One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). > > This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. > Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). > > There is also a CSR to look at. > > Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8275056-virtualize-g1cardset-containers2 - 32 bit compatibility - limit region size to 32M there as before. Fix test. - Virtual heap regions in remembered sets ------------- Changes: https://git.openjdk.java.net/jdk/pull/6059/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=02 Stats: 231 lines in 10 files changed: 139 ins; 67 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From sjohanss at openjdk.java.net Wed Oct 27 10:13:15 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 27 Oct 2021 10:13:15 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v2] In-Reply-To: References: Message-ID: <1a7x39OTkZH0eibNL017xQFucVn92ZZ4m-iSBNu0YKE=.90b00990-bdb2-49ba-894b-5f596b4941c4@github.com> On Thu, 21 Oct 2021 10:53:37 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? >> >> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. >> >> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). >> >> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. >> >> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). >> >> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. >> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). >> >> There is also a CSR to look at. >> >> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > 32 bit compatibility - limit region size to 32M there as before. Fix test. Looks good, just a couple of small comments. src/hotspot/share/gc/g1/g1CardSet.cpp line 68: > 66: _bitmap_hash_mask = ~(~(0) << _log2_num_cards_in_howl_bitmap); > 67: > 68: // Heap region virtualization. Maybe some more descriptive comment, something like: Allow multiple card regions per heap region. This allows G1 to use larger heap regions without having to use a large integer type for the card index. src/hotspot/share/gc/g1/g1CardSet.cpp line 71: > 69: _log2_card_region_per_heap_region = 0; > 70: > 71: uint bits_storable = G1CardSetContainer::LogCardsPerRegionLimit; Any reason you really want this in a local variable instead of using `G1CardSetContainer::LogCardsPerRegionLimit` directly. If using a local I think the name should better match the constant. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Wed Oct 27 11:59:42 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 11:59:42 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? > > I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. > > When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). > > Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. > > One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). > > This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. > Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). > > There is also a CSR to look at. > > Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6059/files - new: https://git.openjdk.java.net/jdk/pull/6059/files/01672747..bdf9950b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=02-03 Stats: 7 lines in 1 file changed: 3 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Wed Oct 27 12:06:13 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 12:06:13 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v2] In-Reply-To: <1a7x39OTkZH0eibNL017xQFucVn92ZZ4m-iSBNu0YKE=.90b00990-bdb2-49ba-894b-5f596b4941c4@github.com> References: <1a7x39OTkZH0eibNL017xQFucVn92ZZ4m-iSBNu0YKE=.90b00990-bdb2-49ba-894b-5f596b4941c4@github.com> Message-ID: On Wed, 27 Oct 2021 08:17:34 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> 32 bit compatibility - limit region size to 32M there as before. Fix test. > > src/hotspot/share/gc/g1/g1CardSet.cpp line 68: > >> 66: _bitmap_hash_mask = ~(~(0) << _log2_num_cards_in_howl_bitmap); >> 67: >> 68: // Heap region virtualization. > > Maybe some more descriptive comment, something like: > Allow multiple card regions per heap region. This allows G1 to use larger heap regions without having to use a large integer type for the card index. There is already a comment in the .hpp file about this, so I removed the comment. > src/hotspot/share/gc/g1/g1CardSet.cpp line 71: > >> 69: _log2_card_region_per_heap_region = 0; >> 70: >> 71: uint bits_storable = G1CardSetContainer::LogCardsPerRegionLimit; > > Any reason you really want this in a local variable instead of using `G1CardSetContainer::LogCardsPerRegionLimit` directly. If using a local I think the name should better match the constant. The `G1CardSetContainer::LogCardsPerRegionLimit` identifier is too long imho :) ------------- PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Wed Oct 27 12:11:37 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 12:11:37 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v5] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? > > I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. > > When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). > > Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. > > One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). > > This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. > Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). > > There is also a CSR to look at. > > Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: sjohanss review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6059/files - new: https://git.openjdk.java.net/jdk/pull/6059/files/bdf9950b..df20ac6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=03-04 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Wed Oct 27 12:11:39 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 27 Oct 2021 12:11:39 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v4] In-Reply-To: References: Message-ID: <8H1dSTH6cKxGFgzeM0A-vMrYoMp2AufxEo5F5OLD5CU=.77b0643d-d969-40d1-abcb-b5a3f4cd2bbf@github.com> On Wed, 27 Oct 2021 11:59:42 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? >> >> I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. >> >> When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). >> >> Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. >> >> One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). >> >> This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. >> Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). >> >> There is also a CSR to look at. >> >> Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix assert after merge - the assert depends on current heap region configuration, so move it to the correct constructor Reran tier1-5 without issues (except assert problem that has been fixed in bdf9950). ------------- PR: https://git.openjdk.java.net/jdk/pull/6059 From pliden at openjdk.java.net Wed Oct 27 12:19:24 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 27 Oct 2021 12:19:24 GMT Subject: RFR: 8276055: ZGC: Defragment address space Message-ID: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. Testing: - Tier 1-7 with ZGC on Linux/x86_64 - SPECjbb2015 shows no regression - Manuel ran test that tries to fragment the address space ------------- Commit messages: - 8276055: ZGC: Defragment address space Changes: https://git.openjdk.java.net/jdk/pull/6137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276055 Stats: 69 lines in 7 files changed: 63 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6137/head:pull/6137 PR: https://git.openjdk.java.net/jdk/pull/6137 From stefan.karlsson at oracle.com Wed Oct 27 12:55:53 2021 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 27 Oct 2021 14:55:53 +0200 Subject: RFR: 8276055: ZGC: Defragment address space In-Reply-To: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: <71982c36-e356-2d2d-0ceb-b88774895beb@oracle.com> Looks good! StefanK On 2021-10-27 14:19, Per Liden wrote: > In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. > > To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. > > Testing: > - Tier 1-7 with ZGC on Linux/x86_64 > - SPECjbb2015 shows no regression > - Manuel ran test that tries to fragment the address space > > ------------- > > Commit messages: > - 8276055: ZGC: Defragment address space > > Changes: https://git.openjdk.java.net/jdk/pull/6137/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6137&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8276055 > Stats: 69 lines in 7 files changed: 63 ins; 0 del; 6 mod > Patch: https://git.openjdk.java.net/jdk/pull/6137.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/6137/head:pull/6137 > > PR: https://git.openjdk.java.net/jdk/pull/6137 From eosterlund at openjdk.java.net Wed Oct 27 13:26:12 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Oct 2021 13:26:12 GMT Subject: RFR: 8276055: ZGC: Defragment address space In-Reply-To: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: On Wed, 27 Oct 2021 12:10:25 GMT, Per Liden wrote: > In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. > > To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. > > Testing: > - Tier 1-7 with ZGC on Linux/x86_64 > - SPECjbb2015 shows no regression > - Manuel ran test that tries to fragment the address space Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6137 From pliden at openjdk.java.net Wed Oct 27 14:45:40 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 27 Oct 2021 14:45:40 GMT Subject: RFR: 8276055: ZGC: Defragment address space [v2] In-Reply-To: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: > In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. > > To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. > > Testing: > - Tier 1-7 with ZGC on Linux/x86_64 > - SPECjbb2015 shows no regression > - Manually ran test that tries to fragment the address space Per Liden has updated the pull request incrementally with one additional commit since the last revision: Renames ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6137/files - new: https://git.openjdk.java.net/jdk/pull/6137/files/cbd5b6b3..5b7b8e96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6137&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6137&range=00-01 Stats: 17 lines in 7 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/6137.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6137/head:pull/6137 PR: https://git.openjdk.java.net/jdk/pull/6137 From pliden at openjdk.java.net Wed Oct 27 14:45:42 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 27 Oct 2021 14:45:42 GMT Subject: RFR: 8276055: ZGC: Defragment address space In-Reply-To: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: On Wed, 27 Oct 2021 12:10:25 GMT, Per Liden wrote: > In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. > > To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. > > Testing: > - Tier 1-7 with ZGC on Linux/x86_64 > - SPECjbb2015 shows no regression > - Manually ran test that tries to fragment the address space Renamed a few functions after off-line discussion with @stefank and @fisk. ------------- PR: https://git.openjdk.java.net/jdk/pull/6137 From eosterlund at openjdk.java.net Wed Oct 27 14:56:11 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Oct 2021 14:56:11 GMT Subject: RFR: 8276055: ZGC: Defragment address space [v2] In-Reply-To: References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: On Wed, 27 Oct 2021 14:45:40 GMT, Per Liden wrote: >> In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. >> >> To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. >> >> Testing: >> - Tier 1-7 with ZGC on Linux/x86_64 >> - SPECjbb2015 shows no regression >> - Manually ran test that tries to fragment the address space > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Renames Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6137 From stefank at openjdk.java.net Wed Oct 27 14:56:12 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 27 Oct 2021 14:56:12 GMT Subject: RFR: 8276055: ZGC: Defragment address space [v2] In-Reply-To: References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: On Wed, 27 Oct 2021 14:45:40 GMT, Per Liden wrote: >> In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. >> >> To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. >> >> Testing: >> - Tier 1-7 with ZGC on Linux/x86_64 >> - SPECjbb2015 shows no regression >> - Manually ran test that tries to fragment the address space > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Renames Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6137 From pliden at openjdk.java.net Thu Oct 28 05:51:14 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 28 Oct 2021 05:51:14 GMT Subject: RFR: 8276055: ZGC: Defragment address space [v2] In-Reply-To: References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: On Wed, 27 Oct 2021 14:45:40 GMT, Per Liden wrote: >> In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. >> >> To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. >> >> Testing: >> - Tier 1-7 with ZGC on Linux/x86_64 >> - SPECjbb2015 shows no regression >> - Manually ran test that tries to fragment the address space > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Renames Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/6137 From pliden at openjdk.java.net Thu Oct 28 05:51:14 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 28 Oct 2021 05:51:14 GMT Subject: Integrated: 8276055: ZGC: Defragment address space In-Reply-To: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> References: <1aqPQd7KsLY49PeSuspGNVGQWqbmorRyLDEKJe9ATNQ=.578c87d4-85c0-47e8-b706-3a8ba797676c@github.com> Message-ID: On Wed, 27 Oct 2021 12:10:25 GMT, Per Liden wrote: > In ZGC, small pages are allocated from the beginning of the address space (low addresses), while medium and large pages are allocated from the end of the address space (high addresses). However, small pages can sometimes end up on a high address if a medium or a large page was split into small pages. Over time this can cause the address space to become fragmented, with the risk of eventually running out of address space for new large allocations. > > To mitigate this, we can defragment the address space by letting small pages at high addresses be remapped to lower addresses. That's what this patch does. > > Testing: > - Tier 1-7 with ZGC on Linux/x86_64 > - SPECjbb2015 shows no regression > - Manually ran test that tries to fragment the address space This pull request has now been integrated. Changeset: 1750a6e2 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/1750a6e2c06960b734f646018fc99b336bd966a5 Stats: 80 lines in 8 files changed: 63 ins; 0 del; 17 mod 8276055: ZGC: Defragment address space Reviewed-by: eosterlund, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/6137 From pliden at openjdk.java.net Thu Oct 28 05:55:19 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 28 Oct 2021 05:55:19 GMT Subject: RFR: 8276067: ZGC: Remove unused function alloc_high_address_at_most() Message-ID: The function ZMemoryManager::alloc_high_address_at_most() is unused and can be removed. ------------- Commit messages: - 8276067: ZGC: Remove unused function alloc_high_address_at_most() Changes: https://git.openjdk.java.net/jdk/pull/6146/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6146&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276067 Stats: 26 lines in 2 files changed: 0 ins; 26 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/6146.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6146/head:pull/6146 PR: https://git.openjdk.java.net/jdk/pull/6146 From eosterlund at openjdk.java.net Thu Oct 28 06:55:08 2021 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 28 Oct 2021 06:55:08 GMT Subject: RFR: 8276067: ZGC: Remove unused function alloc_high_address_at_most() In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 05:46:45 GMT, Per Liden wrote: > The function ZMemoryManager::alloc_high_address_at_most() is unused and can be removed. Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6146 From sjohanss at openjdk.java.net Thu Oct 28 08:03:12 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 28 Oct 2021 08:03:12 GMT Subject: RFR: 8272083: G1: Record iterated range for BOT performance during card scan [v5] In-Reply-To: References: Message-ID: <1YuGbnoygPsmF7I3sb-s-W-yr-EKcOIfIdRuyETrsFQ=.3c2b9ba9-c153-4062-8ccb-d9b309894d99@github.com> On Wed, 27 Oct 2021 08:44:39 GMT, Yude Lin wrote: > > One problem I see with using the refinement threads (to allow scaling better) is that it will probably make the heuristic for scaling the number of threads a bit more complicated, because there are two types of work that should be handled. Have you thought anything about that? > > I admit this is a bit hacky too. I noticed it breaks the heuristics, but just wanted to put this out for more discussion before I make the heuristics more complicated. Chances are that this solution has other unresolved problems (like mutator stall) and we won't go down this path and then I don't have to work on the heuristics. Sorry for being lazy here ; ) > This is totally fine and it's really good to get things out for discussion early. This was not meant as a complaint but rather a question if you had any ideas in the area. I think figuring out a good solution for where (which threads, probably refinement thread) and when (the heuristic) is key for making a concurrent solution efficient and maintainable. > > One way forward would be to first go with a solution doing the work inside the pause and then continue investigating how to move it to concurrent threads in an efficient and maintainable way. > > From these results, it looks like maintaining a precise BOT(that is, every entry points to an actual object start, not plab start) during evacuation isn't very costly in the first place. Maybe the pause-time solution is the best move for now. > > So if the direction is set, how do we go about making it happen? Do we change this pr for that purpose or do you want to submit another pr? I'm happy to contribute just so you know. Since I have a pretty cleaned up PoC, I think moving forward with that one is probably good: https://github.com/openjdk/jdk/compare/master...kstefanj:rnd-explicit-bot-updates There are some things I need to clean up more before sending out for review. I think I will create a new enhancement for this and we can rename this enhancement to something like: Move precise BOT updates in evacuation to concurrent phase It would be great if you can help with reviewing that change and also test to see that it helps your uses-cases. How does that sound? ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From stefank at openjdk.java.net Thu Oct 28 10:02:11 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 28 Oct 2021 10:02:11 GMT Subject: RFR: 8276067: ZGC: Remove unused function alloc_high_address_at_most() In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 05:46:45 GMT, Per Liden wrote: > The function ZMemoryManager::alloc_high_address_at_most() is unused and can be removed. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6146 From pliden at openjdk.java.net Thu Oct 28 10:13:13 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 28 Oct 2021 10:13:13 GMT Subject: RFR: 8276067: ZGC: Remove unused function alloc_high_address_at_most() In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 05:46:45 GMT, Per Liden wrote: > The function ZMemoryManager::alloc_high_address_at_most() is unused and can be removed. Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/6146 From pliden at openjdk.java.net Thu Oct 28 10:13:14 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 28 Oct 2021 10:13:14 GMT Subject: Integrated: 8276067: ZGC: Remove unused function alloc_high_address_at_most() In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 05:46:45 GMT, Per Liden wrote: > The function ZMemoryManager::alloc_high_address_at_most() is unused and can be removed. This pull request has now been integrated. Changeset: d88b89f8 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/d88b89f89643dd97092b1debf98e871f873e8f9c Stats: 26 lines in 2 files changed: 0 ins; 26 del; 0 mod 8276067: ZGC: Remove unused function alloc_high_address_at_most() Reviewed-by: eosterlund, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/6146 From rkennke at openjdk.java.net Thu Oct 28 11:44:45 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 11:44:45 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v2] In-Reply-To: References: Message-ID: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Revert unnecessary changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5955/files - new: https://git.openjdk.java.net/jdk/pull/5955/files/ec0a4bad..75fdec35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=00-01 Stats: 327 lines in 28 files changed: 60 ins; 171 del; 96 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 11:47:52 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 11:47:52 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v3] In-Reply-To: References: Message-ID: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix Parallel GC mistake ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5955/files - new: https://git.openjdk.java.net/jdk/pull/5955/files/75fdec35..a9f0c845 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From tschatzl at openjdk.java.net Thu Oct 28 12:14:19 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 12:14:19 GMT Subject: RFR: 8276100: Remove G1SegmentedArray constructor name parameter Message-ID: Hi all, can I have reviews for this trivial(?) change to remove an unused parameter to the G1SegmentedArray constructor? Testing: local compilation Thanks, Thomas ------------- Commit messages: - Initial version Changes: https://git.openjdk.java.net/jdk/pull/6154/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6154&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276100 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6154.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6154/head:pull/6154 PR: https://git.openjdk.java.net/jdk/pull/6154 From ayang at openjdk.java.net Thu Oct 28 12:23:13 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 28 Oct 2021 12:23:13 GMT Subject: RFR: 8276100: Remove G1SegmentedArray constructor name parameter In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 12:06:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial(?) change to remove an unused parameter to the G1SegmentedArray constructor? > > Testing: local compilation > > Thanks, > Thomas LGTM and trivial. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6154 From tschatzl at openjdk.java.net Thu Oct 28 12:23:17 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 12:23:17 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v12] In-Reply-To: References: Message-ID: On Tue, 26 Oct 2021 04:47:59 GMT, Hamlin Li wrote: >> This is a try to optimize evcuation failure for regions. >> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. >> >> I have tested it with following parameters, >> >> - -XX:+ParallelGCThreads=1/32/64 >> - -XX:G1EvacuationFailureALotInterval=1 >> - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 >> >> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. >> >> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR There are quite a few comments from me about this change, and at some point I decided to provide a change that would cover these and more suggestions I had (note that this change might contradict some of the other suggestions - sometimes this happens when actually tinkering and seeing the whole code); communicating via text is too cumbersome. The commit containing the direction I think the change should go is available at https://github.com/openjdk/jdk/commit/b793f5bfb9e15f938fefe2e64b16eb56818bc695 . Mostly it is about hiding the code for preparing and iterating the sorted list of objects that failed evacuation. Maybe `G1EvacFailureObjsInHR` should be renamed to something like `G1EvacFailedObjectsSet` (I do not think the `HR` postfix is important). As for the other question, for now I think it is good to keep the `G1EvacFailureObjsInHR` in `HeapRegion`. Please have a look. src/hotspot/share/gc/g1/g1EvacFailure.cpp line 73: > 71: assert(_hr->is_in(obj_addr), "sanity"); > 72: > 73: // The object failed to move. One could add an assert that `_last_forwarded_object <= obj`. This was implicit in the object walk earlier, but not any more and is only guaranteed by the object sorting. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.cpp line 35: > 33: > 34: const uint G1EvacFailureObjsInHR::MaxBufferLength = > 35: static_cast(1u << (HeapRegion::LogOfHRGrainBytes-LogHeapWordSize)); I am not sure this `static_cast` is necessary: shifting an `uint` gives an uint, but I did not check... src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.cpp line 84: > 82: for (uint i = 0; i < _objs_num; i++) { > 83: assert(i == 0 ? (prev <= _offset_array[i]) : (prev < _offset_array[i]), > 84: "must be, %u, %u, %u", i, prev, _offset_array[i]); As suggested, I would move this check that addresses passed to `do_object` must be ascending into `do_object`. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.cpp line 86: > 84: "must be, %u, %u, %u", i, prev, _offset_array[i]); > 85: assert(prev < _max_offset, "must be, %u", prev); > 86: closure->do_object(cast_from_offset(prev = _offset_array[i])); Please avoid assignments within unrelated statements :) I almost overlooked that. I.e. just move `prev` one line above. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.cpp line 118: > 116: compact(); > 117: sort(); > 118: iterate_internal(closure); I would prefer if all these methods would not operate on the (temporarily used) member `_offset_array`. I would prefer if this method kept this offset array local and passed it through these methods - that would make the code much more obvious to follow. Also then it would be obvious that `_offset_array` is actually local, with allocation and deallocation placed here. It's not obvious that `compact` not only compacts the segmented array, but also allocates it. Maybe a better name for `compact` would be `join_segments` too. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.hpp line 39: > 37: > 38: public: > 39: typedef uint Elem; I am not sure if this indirection is necessary; if so, document what it is though. And why an `uint` is sufficient. Maybe use something more descriptive than `Elem`, e.g. `OopOffsetInRegion`. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.hpp line 48: > 46: static const G1SegmentedArrayAllocOptions _alloc_options; > 47: // This free list is shared among evacuation failure process in all regions. > 48: static G1SegmentedArrayBufferList _free_buffer_list; If not already done, please file an issue that the `_free_buffer_list` is never (partially) reclaimed. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.hpp line 51: > 49: > 50: const Elem _max_offset; > 51: const uint _region_idx; Both `_max_offset` and `_region_idx` are only used in verification code. Please make `DEBUG_ONLY`. `_max_offset` could be replaced by a method recalculating the value since we are talking about a simple shift. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.hpp line 64: > 62: return cast_to_oop(_bottom + offset); > 63: } > 64: Elem cast_from_oop_addr(oop obj) { Missing newline. src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.hpp line 90: > 88: > 89: // Verify elements in the buffer > 90: void visit_elem(void* elem); Please name this `verify_elems` or so. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5181 From rkennke at openjdk.java.net Thu Oct 28 12:35:37 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 12:35:37 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v4] In-Reply-To: References: Message-ID: > Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: > fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); > > or similar constructs. > > Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). > > I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. > > Testing: > - [x] tier > - [x] tier2 > - [x] hotspot_gc Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Move forward impl into markWord and add assert ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5955/files - new: https://git.openjdk.java.net/jdk/pull/5955/files/a9f0c845..9c2ed2ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5955&range=02-03 Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5955.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5955/head:pull/5955 PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 12:41:13 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 12:41:13 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v4] In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 12:35:37 GMT, Roman Kennke wrote: >> Accessing the forward pointer overlay of object headers is currently done in a somewhat crude way. oopDesc::forwardee() and oopeDesc::is_forwarded() both load the header-word. This seems kinda bad, because they are most often used in conjunction, e.g.: >> fwd = obj->forwarded() ? obj->forwardee() : promote_obj(); >> >> or similar constructs. >> >> Also, in some places, the forwardee is accessed in a more direct fashion using markWord::decode_pointer(), or as HeapWord*, sometimes is_forwarded() is determined by forwardee() == NULL checks (and crude overrides to prepare non-forwarded headers to return NULL in such checks, see g1Full* source files). >> >> I propose to extract and refactor forward pointer access in a way to better support above pattern. In-fact I originally wrote this with performance-enhancement in mind (see oopForwarding.hpp header for more details), but I could not show any actual performance improvements, so let's consider this purely on cleanliness and separation-of-concerns basis. >> >> Testing: >> - [x] tier >> - [x] tier2 >> - [x] hotspot_gc > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Move forward impl into markWord and add assert I've removed OopForwarding altogether, and only kept the actual refactorings and cleanups. Can you please re-review? ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From rkennke at openjdk.java.net Thu Oct 28 12:41:14 2021 From: rkennke at openjdk.java.net (Roman Kennke) Date: Thu, 28 Oct 2021 12:41:14 GMT Subject: RFR: 8275527: Separate/refactor forward pointer access [v4] In-Reply-To: References: Message-ID: <9xpY2oFvx_vNWmeextHoveVIarXOJ4IUPtXQeLV6VqY=.02c0abc9-a5de-4309-909c-16aaf129b4bf@github.com> On Thu, 21 Oct 2021 07:30:44 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Move forward impl into markWord and add assert > > src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp line 112: > >> 110: // since it will be restored by preserved marks. >> 111: object->init_mark(); >> 112: } else { > > Could you explain why this was removed? The G1 Full GC code decoded the fwdptr without checking if object is actually forwarded (i.e. by checking the lowest two mark word bits), and then compare the result with NULL. In order for this to work, it modifies the mark word of not forwarded objects to prototype mark. This is all quite messy and can be avoided by checking is_forwarded() before actually decoding the fwdptr. ------------- PR: https://git.openjdk.java.net/jdk/pull/5955 From duke at openjdk.java.net Thu Oct 28 12:49:13 2021 From: duke at openjdk.java.net (duke) Date: Thu, 28 Oct 2021 12:49:13 GMT Subject: Withdrawn: 8273122: ZGC: Load forwarding entries without acquire semantics In-Reply-To: References: Message-ID: On Mon, 30 Aug 2021 09:17:12 GMT, Hao Tang wrote: > JDK-8272138 introduced an unbound membar release() between the object copy and the forwarding table insertion. > > Thread A (Relocation): > copy(); > release(); > cas_forwarding_table(); > cas_self_heal(); > > The membar guarantees that the contents of the forwarded object are ready after a forwarding entry is loaded. Since load_object_content(ref) depends on the result of load_forwarding_table(), load_acquire can be safely changed to a simple load. > > Thread B (Remapping/Relocation): > ref = load_forwarding_table(); // acquire (current version) -> relaxed (our proposal) > load_object_content(ref); > > Our experiment on heapothesys demonstrates >5% time reduction spent on concurrent mark/relocation on AArch64. > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.java.net/jdk pull/5298/head:pull/5298` \ > `$ git checkout pull/5298` > > Update a local copy of the PR: \ > `$ git checkout pull/5298` \ > `$ git pull https://git.openjdk.java.net/jdk pull/5298/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 5298` > > View PR using the GUI difftool: \ > `$ git pr show -t 5298` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.java.net/jdk/pull/5298.diff > >
This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5298 From tschatzl at openjdk.java.net Thu Oct 28 12:53:32 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 12:53:32 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v6] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? > > I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. > > When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). > > Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. > > One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). > > This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. > Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). > > There is also a CSR to look at. > > Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Limit ergonomics to 32m regions ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6059/files - new: https://git.openjdk.java.net/jdk/pull/6059/files/df20ac6a..adf5f7b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=04-05 Stats: 11 lines in 4 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Thu Oct 28 12:53:33 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 12:53:33 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v2] In-Reply-To: <1a7x39OTkZH0eibNL017xQFucVn92ZZ4m-iSBNu0YKE=.90b00990-bdb2-49ba-894b-5f596b4941c4@github.com> References: <1a7x39OTkZH0eibNL017xQFucVn92ZZ4m-iSBNu0YKE=.90b00990-bdb2-49ba-894b-5f596b4941c4@github.com> Message-ID: On Wed, 27 Oct 2021 10:09:52 GMT, Stefan Johansson wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> 32 bit compatibility - limit region size to 32M there as before. Fix test. > > Looks good, just a couple of small comments. After some discussion with @kstefanj we thought it would be best to limit the ergonomics to 32M regions (the previous maximum) since the choice of heap region size affects several other internal tuning (chunk sizing for scanning remembered sets, parallelism). Their impact has not been explored too much. The user may still manually select larger sizes up to 512M at the moment, assuming that *if* you override the defaults, we assume that you will measure the impact appropriately. Of course, feedback by users about their choice is appreciated. ------------- PR: https://git.openjdk.java.net/jdk/pull/6059 From tschatzl at openjdk.java.net Thu Oct 28 13:01:14 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 13:01:14 GMT Subject: Integrated: 8276100: Remove G1SegmentedArray constructor name parameter In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 12:06:04 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial(?) change to remove an unused parameter to the G1SegmentedArray constructor? > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: 85d8cd85 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/85d8cd85665d92d67bbc88399baaa8fe7eba14a6 Stats: 5 lines in 3 files changed: 0 ins; 2 del; 3 mod 8276100: Remove G1SegmentedArray constructor name parameter Reviewed-by: ayang ------------- PR: https://git.openjdk.java.net/jdk/pull/6154 From tschatzl at openjdk.java.net Thu Oct 28 13:01:14 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 13:01:14 GMT Subject: RFR: 8276100: Remove G1SegmentedArray constructor name parameter In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 12:20:10 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> can I have reviews for this trivial(?) change to remove an unused parameter to the G1SegmentedArray constructor? >> >> Testing: local compilation >> >> Thanks, >> Thomas > > LGTM and trivial. Thanks for your review @albertnetymk ------------- PR: https://git.openjdk.java.net/jdk/pull/6154 From tschatzl at openjdk.java.net Thu Oct 28 14:54:36 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 14:54:36 GMT Subject: RFR: 8275056: Virtualize G1CardSet containers over heap region [v7] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that virtualizes `G1CardSet` "regions" over a heap region, allowing the use of multiple "`G1CardSet` card regions" across a single heap region? > > I.e. `HeapRegionRemSet`, which is the interface to a region's card set, simply uses multiple indexes for the remembered set of a single source heap region if necessary. E.g. on a 128MB region, heap region 0's cards would be stored as (what I call) "card region" indexes 0..3 as appropriate in its `_card_set`. > > When retrieving the values, the appropriate retransformation is done (during `HeapRegionRemSet::iterate_for_merge()`). > > Assigning `HeapRegionRemSet` to handle all this multiplexing required some move of the `G1CardSet::iterate_for_merge` method to `HeapRegionRemSet`, which is why there are more changes than expected. > > One change I would like to have opinions on is storing the amount of card regions per region into `G1CardSetConfiguration`, maybe it is better to put this into `HeapRegionRemSet` - but I did not want to start a `HeapRegionRemSetConfiguration` (maybe also put the cached values introduced in the `split_card` optimization there as well?). > > This allows unlimited actual heap region size. Currently set to 512MB (what we would set ergonomically if on a 1 TB heap), but that's just a random number basically. > Feel free to suggest a different maximum heap region size if any. We could also keep the ergonomics use a smaller heap region size (e.g. 32M as before). > > There is also a CSR to look at. > > Testing: tier1-5, some perf testing on region sizes up to 512M with slight improvements in specjbb2015 with larger region sizes. > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang review1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6059/files - new: https://git.openjdk.java.net/jdk/pull/6059/files/adf5f7b4..54a0358c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6059&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/6059.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6059/head:pull/6059 PR: https://git.openjdk.java.net/jdk/pull/6059 From duke at openjdk.java.net Thu Oct 28 15:13:10 2021 From: duke at openjdk.java.net (Yude Lin) Date: Thu, 28 Oct 2021 15:13:10 GMT Subject: RFR: 8272083: G1: Move precise BOT updates in evacuation to concurrent phase [v5] In-Reply-To: References: Message-ID: On Mon, 18 Oct 2021 09:32:40 GMT, Yude Lin wrote: >> A fix to the problem in 8272083 is to use a per-worker pointer to indicate where the worker has scanned up to, similar to the _scanned_to variable. The difference is this pointer (I call it _iterated_to) records the end of the object and _scanned_to records the end of the scan. Since we always scan with increasing addresses, the end of the latest object scanned is also the address where BOT has fixed up to. So we avoid having to fix below this address when calling block_start(). This implementation approximately reduce the number of calls to set_offset_array() during scan_heap_roots() 2-10 times (in my casual test with -XX:G1ConcRefinementGreenZone=1000000). >> >> What this approach not solving is random access to BOT. So far I haven't found anything having this pattern. > > Yude Lin has updated the pull request incrementally with three additional commits since the last revision: > > - Removed additional thread and card set code > - Switch to dcq and refinement threads to manage the plab cards > - Trivial > Since I have a pretty cleaned up PoC, I think moving forward with that one is probably good: > master...kstefanj:rnd-explicit-bot-updates > > There are some things I need to clean up more before sending out for review. I think I will create a new enhancement for this and we can rename this enhancement to something like: > Move precise BOT updates in evacuation to concurrent phase > > It would be great if you can help with reviewing that change and also test to see that it helps your uses-cases. How does that sound? Yep, that sounds fair. Will change the name of this issue. Looking forward to see your updates! ------------- PR: https://git.openjdk.java.net/jdk/pull/5039 From tschatzl at openjdk.java.net Thu Oct 28 16:17:35 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 28 Oct 2021 16:17:35 GMT Subject: RFR: 8276107: Preventive collections trigger before maxing out heap Message-ID: Hi all, can I have reviews for this small fix for an issue where preventive gcs that are supposed to prevent evacuation failure were also started if there were only not enough free committed regions available but more than enough uncommitted regions to expand the heap (to avoid the evacuation failure). Testing: gha Thanks, Thomas ------------- Commit messages: - Do not start preventive gc before completely out of regions Changes: https://git.openjdk.java.net/jdk/pull/6160/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6160&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276107 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6160/head:pull/6160 PR: https://git.openjdk.java.net/jdk/pull/6160 From mli at openjdk.java.net Fri Oct 29 04:35:03 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 04:35:03 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v13] In-Reply-To: References: Message-ID: <4UfBZKncN-Zg4kyk8NR1gtvmxtqKsCEr2RArf8TKScM=.0c6b3ec5-7959-4256-9195-4b4c117502f1@github.com> > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Refactor as Thomas suggested ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/924fec5b..00708263 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=11-12 Stats: 459 lines in 8 files changed: 233 ins; 216 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 04:38:15 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 04:38:15 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v13] In-Reply-To: <4UfBZKncN-Zg4kyk8NR1gtvmxtqKsCEr2RArf8TKScM=.0c6b3ec5-7959-4256-9195-4b4c117502f1@github.com> References: <4UfBZKncN-Zg4kyk8NR1gtvmxtqKsCEr2RArf8TKScM=.0c6b3ec5-7959-4256-9195-4b4c117502f1@github.com> Message-ID: On Fri, 29 Oct 2021 04:35:03 GMT, Hamlin Li wrote: >> This is a try to optimize evcuation failure for regions. >> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. >> >> I have tested it with following parameters, >> >> - -XX:+ParallelGCThreads=1/32/64 >> - -XX:G1EvacuationFailureALotInterval=1 >> - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 >> >> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. >> >> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Refactor as Thomas suggested Thanks a lot Thomas, I like the refacoring :) Based on your comments and code, I made some adjustment. For renaming visit_elem, as it's a callback by G1SegmentedArrayBuffer, so I add some comments instead. BTW, Not sure why, but seems the rename from g1EvacFailureObjsInHR.cpp to g1EvacFailureObjectsSet.cpp is not recongnized by git. ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 04:51:10 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 04:51:10 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v12] In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 15:30:01 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR > > src/hotspot/share/gc/g1/g1EvacFailureObjsInHR.hpp line 48: > >> 46: static const G1SegmentedArrayAllocOptions _alloc_options; >> 47: // This free list is shared among evacuation failure process in all regions. >> 48: static G1SegmentedArrayBufferList _free_buffer_list; > > If not already done, please file an issue that the `_free_buffer_list` is never (partially) reclaimed. Created https://bugs.openjdk.java.net/browse/JDK-8276148 to track it ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 06:41:37 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 06:41:37 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v14] In-Reply-To: References: Message-ID: <-l3aIohRk_H1-YwZPEQxxg2Bz-c8rSoCae0rFk_bBds=.41e1a116-aabd-426e-85fc-93973eefe206@github.com> > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Fix compilation error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/00708263..c4ca77c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From sjohanss at openjdk.java.net Fri Oct 29 08:31:24 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 29 Oct 2021 08:31:24 GMT Subject: RFR: 8276098: Do precise BOT updates in G1 evacuation phase Message-ID: <_eI_dg5LYqniToNWZXg9m8ncqs4MwEh0UAIhehnXFOM=.2bee9f37-0758-4999-8d33-2c5127b5ee04@github.com> Please review this change to do precise BOT updates in the G1 evacuation phase. **Summary** In G1 young collections the BOT is updated for objects copied to old generation regions. Prior to this fix the BOT updates are very crude and only done for each new PLAB and for direct allocations (large allocation outside the PLABs). The BOT is then updated to be more precise during concurrent refinement and when scanning the heap in later GCs. This leads to both more time spent doing concurrent refinement as well as prolonged "scan heap" phases in the following GCs. With this change we instead update the BOT to be complete and precise while doing the copy. This way we can reduce the time in the following phases quite significantly. This comes with a slight regression in object copy times, but from my measurements the overall gain is worth the complexity and extra time spent in object copy. Doing this more precise BOT updating requires us to not rely on a global threshold for updating the BOT but instead calculate where the updates are done, this allows us to remove a lock in the old generation allocation path which is only present to guard this threshold. So with this change we can remove the different allocation paths used for young and old regions. **Testing** All testing look good: - [x] Mach5 tier1-5 - [x] Local stress testing - [x] Performance testing and pause time comparisons ------------- Commit messages: - Keep _bot_part threshold in sync - Cleanups and comments. - Do explicit BOT updates for OLD regions when evacuating. Changes: https://git.openjdk.java.net/jdk/pull/6166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6166&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276098 Stats: 245 lines in 13 files changed: 176 ins; 53 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6166/head:pull/6166 PR: https://git.openjdk.java.net/jdk/pull/6166 From mli at openjdk.java.net Fri Oct 29 08:39:10 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 08:39:10 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v7] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:44:58 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compilation error on windows > > Performance is good as is, particularly the Remove self-forwards phase is much much faster now. I added a figure to the CR [here](https://bugs.openjdk.java.net/secure/attachment/96321/20210902-remove-self-forwards-improvement.png). Really nice. > > Although there are a few existing abnormalities with this change (not newly introduced, the old code is as bad), see [JDK-8273309](https://bugs.openjdk.java.net/browse/JDK-8273309). > > There are a few things that need to be improved: > * we talked about this before, but I do not think putting `G1EvacuationFailureObjsInHR`, which is something only used in evacuation failure, into `HeapRegion`, should be done. At least at the moment, it is almost never used. > * I do not like the use and the implementation of `G1EvacuationFailureObjsInHR`: it recreates something thatt is done better elsewhere (mark stack, DCQS buffer allocator, and in particular in the remembered set cardset allocator) with less features, in a non-fitting style. > Examples are something like reuse of available chunks, concurrent freeing of chunks, automatic resizing of blocks on demand to decrease allocations and potentially other stuff seems something we would really really want. > * as far as I understand the implementation of `G1EvacuationFailureObjsInHR` ;) - there is zero documentation about the basic structure - it seems to allocate quite a lot of memory that is almost never used. Even in the case of evacuation failure it's likely to be almost empty. > `G1EvacuationFailureObjsInHR` seems to basically be a preallocated `ArrayList` of chunks (the `_array_list` member). > Afaict it uses like 1/256 of total heap size (i.e. 0.3%), that's way way too much ( 1 / (256 * sizeof(HeapWord)) * sizeof(pointer); in `G1EvacuationFailureObjsInHR.cpp:86`; the `Array` constructor in `G1EvacuationFailureObjsInHR.hpp:124)) ). We will also get into trouble about startup time about this, I'm sure. That, tbh, alone makes it a no-go if I did not miscalculate. > > Let's work on renaming and reusing the infrastructure provided by the remembered set (`G1CardSetAllocator` etc) in `g1CardSetMemory.hpp`. @tschatzl Hi Thomas, is there any way I can reproduce this compilation error (drop_all reference) on my local? I use "bash configure; make images CONF=rel", there is no error on linux x86_64. ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From sjohanss at openjdk.java.net Fri Oct 29 08:40:17 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 29 Oct 2021 08:40:17 GMT Subject: RFR: 8276107: Preventive collections trigger before maxing out heap In-Reply-To: References: Message-ID: On Thu, 28 Oct 2021 16:09:36 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small fix for an issue where preventive gcs that are supposed to prevent evacuation failure were also started if there were only not enough free committed regions available but more than enough uncommitted regions to expand the heap (to avoid the evacuation failure). > > Testing: gha, tier1-3 > > Thanks, > Thomas Looks good. I think we should also update the logging below to include `num_free_or_available_regions()` or maybe even better to just add available, but that would require a new getter if I'm not misstaken. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6160 From sjohanss at openjdk.java.net Fri Oct 29 08:58:08 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 29 Oct 2021 08:58:08 GMT Subject: RFR: 8276047: G1: refactor G1CardSetArrayLocker In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 08:52:08 GMT, Albert Mingkun Yang wrote: > Simple refactoring in `G1CardSetArrayLocker`: > > 1. rename fields to sth more explicit > 2. drop `volatile` for thread-local variables > 3. increment directly without treating `bool` as an integer > > Test: hotspot_gc Nice cleanup, looks good! ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6134 From ayang at openjdk.java.net Fri Oct 29 09:10:13 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 29 Oct 2021 09:10:13 GMT Subject: RFR: 8276047: G1: refactor G1CardSetArrayLocker In-Reply-To: References: Message-ID: <8MOlCRU4dj0leEcSdvrqyfZLAKPTQ3-3wWQeF_cg9Rw=.d2f44cab-4336-4247-b0ac-f272230f42c2@github.com> On Wed, 27 Oct 2021 08:52:08 GMT, Albert Mingkun Yang wrote: > Simple refactoring in `G1CardSetArrayLocker`: > > 1. rename fields to sth more explicit > 2. drop `volatile` for thread-local variables > 3. increment directly without treating `bool` as an integer > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/6134 From ayang at openjdk.java.net Fri Oct 29 09:10:14 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 29 Oct 2021 09:10:14 GMT Subject: Integrated: 8276047: G1: refactor G1CardSetArrayLocker In-Reply-To: References: Message-ID: On Wed, 27 Oct 2021 08:52:08 GMT, Albert Mingkun Yang wrote: > Simple refactoring in `G1CardSetArrayLocker`: > > 1. rename fields to sth more explicit > 2. drop `volatile` for thread-local variables > 3. increment directly without treating `bool` as an integer > > Test: hotspot_gc This pull request has now been integrated. Changeset: 24cf4800 Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/24cf48000ac154eac67b617e2a63557f21032907 Stats: 21 lines in 2 files changed: 3 ins; 4 del; 14 mod 8276047: G1: refactor G1CardSetArrayLocker Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/6134 From tschatzl at openjdk.java.net Fri Oct 29 09:31:52 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 29 Oct 2021 09:31:52 GMT Subject: RFR: 8276107: Preventive collections trigger before maxing out heap [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this small fix for an issue where preventive gcs that are supposed to prevent evacuation failure were also started if there were only not enough free committed regions available but more than enough uncommitted regions to expand the heap (to avoid the evacuation failure). > > Testing: gha, tier1-3 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix log message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6160/files - new: https://git.openjdk.java.net/jdk/pull/6160/files/a9e53bc2..86f1aff3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6160&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6160&range=00-01 Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/6160.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6160/head:pull/6160 PR: https://git.openjdk.java.net/jdk/pull/6160 From sjohanss at openjdk.java.net Fri Oct 29 09:31:54 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 29 Oct 2021 09:31:54 GMT Subject: RFR: 8276107: Preventive collections trigger before maxing out heap In-Reply-To: References: Message-ID: <_IoohcHzKrWN1L68AvSreITt1rMb4RBsXzF_2V152VQ=.6cde4ba0-9b6e-4699-b09c-ee086128ebf6@github.com> On Thu, 28 Oct 2021 16:09:36 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this small fix for an issue where preventive gcs that are supposed to prevent evacuation failure were also started if there were only not enough free committed regions available but more than enough uncommitted regions to expand the heap (to avoid the evacuation failure). > > Testing: gha, tier1-3 > > Thanks, > Thomas ? ------------- PR: https://git.openjdk.java.net/jdk/pull/6160 From tschatzl at openjdk.java.net Fri Oct 29 10:10:24 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 29 Oct 2021 10:10:24 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v14] In-Reply-To: <-l3aIohRk_H1-YwZPEQxxg2Bz-c8rSoCae0rFk_bBds=.41e1a116-aabd-426e-85fc-93973eefe206@github.com> References: <-l3aIohRk_H1-YwZPEQxxg2Bz-c8rSoCae0rFk_bBds=.41e1a116-aabd-426e-85fc-93973eefe206@github.com> Message-ID: On Fri, 29 Oct 2021 06:41:37 GMT, Hamlin Li wrote: >> This is a try to optimize evcuation failure for regions. >> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. >> >> I have tested it with following parameters, >> >> - -XX:+ParallelGCThreads=1/32/64 >> - -XX:G1EvacuationFailureALotInterval=1 >> - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 >> >> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. >> >> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix compilation error Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 51: > 49: } > 50: > 51: G1EvacFailureObjectsSet::OffsetInRegion G1EvacFailureObjectsSet::cast_to_offset(oop obj) const { This should probably be `to_offset` to match `from_offset` (forgot that) - this is not a cast to me (changing the interpretation of a bit pattern) but a transformation (changing the bit pattern for storage savings). So `cast` seems to be the wrong word to me here. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 54: > 52: const HeapWord* o = cast_from_oop(obj); > 53: size_t offset = pointer_delta(o, _bottom); > 54: assert_is_valid_offset(offset); The `from_offset` call below already does this assert. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 62: > 60: DEBUG_ONLY(_region_idx(region_idx) COMMA) > 61: _bottom(bottom), > 62: _offsets("", &_alloc_options, &_free_buffer_list) { Fwiw, I recently removed the first parameter of `G1SegmentedArray`. Please make sure you merge with tip before pushing. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 75: > 73: // Helper class to join, sort and iterate over the previously collected segmented > 74: // array of objects that failed evacuation. > 75: class G1EvacFailureObjectsIterator { Note that this is not an `Iterator` in C++ STL sense, so it is a good idea to not name it like that. I understand that Hotspot code (and even the recent remembered set code - there is a CR to fix that) adds to the confusion, but it would be nice to not add to the confusion. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 78: > 76: typedef G1EvacFailureObjectsSet::OffsetInRegion OffsetInRegion; > 77: friend class G1SegmentedArray; > 78: friend class G1SegmentedArrayBuffer; I prefer to make `visit_*` public here instead of the friends. This is an internal class not visible outside, and we actually use it as a closure. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 80: > 78: friend class G1SegmentedArrayBuffer; > 79: > 80: G1EvacFailureObjectsSet* _collector; Probably rename `_collector` to `_objects_set` or so to match the type better. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 101: > 99: void iterate_internal(ObjectClosure* closure) { > 100: for (uint i = 0; i < _array_length; i++) { > 101: _collector->assert_is_valid_offset(_offset_array[i]); This assert duplicates the one in `from_offset` below. Please remove. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 125: > 123: _collector->assert_is_valid_offset(*ptr); > 124: } > 125: #endif I intentionally removed this `visit_elem` method in the original suggestion because I thought that to be too much checking. It is kind of obvious that we only store data in here. We check that these are valid offsets both when writing to and reading from the array, so this seems to be unnecessary triple-checking. Fwiw, in Hotspot code we do not use the `visit_` prefix but `do_` (and pass something that ends with a `Closure`, not a `Visitor` in the `iterate*` methods). I am aware that in design pattern lingo this is the Visitor pattern, but Hotspot is probably much older than that and it is somewhat jarring to have some code use this terminology and others use another one. A change here needs to be discussed with a wider audience. src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp line 134: > 132: _array_length(0) { } > 133: > 134: ~G1EvacFailureObjectsIterator() { } Please remove the empty unnecessary destructor. src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp line 66: > 64: } > 65: } > 66: As mentioned above, I do not think this one is necessary at this point. src/hotspot/share/gc/g1/heapRegion.cpp line 113: > 111: void HeapRegion::record_evac_failure_obj(oop obj) { > 112: _evac_failure_objs.record(obj); > 113: } This should probably be placed in the `.inline.hpp` file as it is called in performance sensitive code. src/hotspot/share/gc/g1/heapRegion.cpp line 117: > 115: void HeapRegion::iterate_evac_failure_objs(ObjectClosure* closure) { > 116: _evac_failure_objs.iterate(closure); > 117: } (This one is fine to be placed in the cpp file - the additional single call per `HeapRegion` does not matter) src/hotspot/share/gc/g1/heapRegion.hpp line 560: > 558: // Update the region state after a failed evacuation. > 559: void handle_evacuation_failure(); > 560: // Records evac failure objs during evaucation, this will help speed up iteration s/evucation/evacuation. Please try to avoid "evac failure objs" in text as it seems strange to me grammatically, and isn't particularly obvious what this is to readers not working on this all the time. Just say "Record an object that failed evacuation within this region.` I do not think the second part of the sentence is necessary, i.e. talking about speeding up something here. src/hotspot/share/gc/g1/heapRegion.hpp line 563: > 561: // of these objs later in *remove self forward* phase of post evacuation. > 562: void record_evac_failure_obj(oop obj); > 563: // Iterates evac failure objs which are recorded during evcauation. s/evauation/evacuation Better would probably be "Applies the given closure to all previously recorded objects that failed evacuation in ascending address order" ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From tschatzl at openjdk.java.net Fri Oct 29 10:15:15 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 29 Oct 2021 10:15:15 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v7] In-Reply-To: References: Message-ID: On Fri, 10 Sep 2021 12:44:58 GMT, Thomas Schatzl wrote: >> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix compilation error on windows > > Performance is good as is, particularly the Remove self-forwards phase is much much faster now. I added a figure to the CR [here](https://bugs.openjdk.java.net/secure/attachment/96321/20210902-remove-self-forwards-improvement.png). Really nice. > > Although there are a few existing abnormalities with this change (not newly introduced, the old code is as bad), see [JDK-8273309](https://bugs.openjdk.java.net/browse/JDK-8273309). > > There are a few things that need to be improved: > * we talked about this before, but I do not think putting `G1EvacuationFailureObjsInHR`, which is something only used in evacuation failure, into `HeapRegion`, should be done. At least at the moment, it is almost never used. > * I do not like the use and the implementation of `G1EvacuationFailureObjsInHR`: it recreates something thatt is done better elsewhere (mark stack, DCQS buffer allocator, and in particular in the remembered set cardset allocator) with less features, in a non-fitting style. > Examples are something like reuse of available chunks, concurrent freeing of chunks, automatic resizing of blocks on demand to decrease allocations and potentially other stuff seems something we would really really want. > * as far as I understand the implementation of `G1EvacuationFailureObjsInHR` ;) - there is zero documentation about the basic structure - it seems to allocate quite a lot of memory that is almost never used. Even in the case of evacuation failure it's likely to be almost empty. > `G1EvacuationFailureObjsInHR` seems to basically be a preallocated `ArrayList` of chunks (the `_array_list` member). > Afaict it uses like 1/256 of total heap size (i.e. 0.3%), that's way way too much ( 1 / (256 * sizeof(HeapWord)) * sizeof(pointer); in `G1EvacuationFailureObjsInHR.cpp:86`; the `Array` constructor in `G1EvacuationFailureObjsInHR.hpp:124)) ). We will also get into trouble about startup time about this, I'm sure. That, tbh, alone makes it a no-go if I did not miscalculate. > > Let's work on renaming and reusing the infrastructure provided by the remembered set (`G1CardSetAllocator` etc) in `g1CardSetMemory.hpp`. > @tschatzl Hi Thomas, is there any way I can reproduce this compilation error (drop_all reference) on my local? I use "bash configure; make images CONF=rel", there is no error on linux x86_64. Probably try to compile with `--disable-precompiled-headers` (i.e. add to `configure` options). I had this issue yesterday too, but it went away after some changes (and I've been running our CI successfully with my changes). Dug into that a bit deeper - can you try https://github.com/tschatzl/jdk/commit/bc79db0cd8c4eff8b0273e50046b212d201467c0 ? The `g1SegmentedArray.inline.hpp` was not included in `heapregion.inline.hpp`, and that test was missing tons of includes anyway. Also we should clean up the `.hpp` files to not use methods from `.inline.hpp` - if so, they need to be moved to the `.inline.hpp` file too. ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 10:48:17 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 10:48:17 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v14] In-Reply-To: <-l3aIohRk_H1-YwZPEQxxg2Bz-c8rSoCae0rFk_bBds=.41e1a116-aabd-426e-85fc-93973eefe206@github.com> References: <-l3aIohRk_H1-YwZPEQxxg2Bz-c8rSoCae0rFk_bBds=.41e1a116-aabd-426e-85fc-93973eefe206@github.com> Message-ID: On Fri, 29 Oct 2021 06:41:37 GMT, Hamlin Li wrote: >> This is a try to optimize evcuation failure for regions. >> I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. >> >> I have tested it with following parameters, >> >> - -XX:+ParallelGCThreads=1/32/64 >> - -XX:G1EvacuationFailureALotInterval=1 >> - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 >> >> It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. >> >> It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. > > Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix compilation error I tried --disable-precompiled-headers before, sometimes it helps to locate this kind of issue, but not for this time. I will try your modification later. Thansk a lot ------------- PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 11:07:36 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 11:07:36 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v15] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Fix compilation error ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/c4ca77c5..ab04f1ce Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=13-14 Stats: 27 lines in 6 files changed: 21 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 11:36:30 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 11:36:30 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v16] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'openjdk:master' into speedup-iterate-evac-failure-objs-in-one-region - Fix compilation error - Fix compilation error - Refactor as Thomas suggested - Rename from g1EvacuationFailureObjsInHR to g1EvacFailureObjsInHR - Add asserts, comments - Use refactored G1SegmentedArray rather than home-made Array+Node - Fix wrong merge - Merge branch 'master' into speedup-iterate-evac-failure-objs-in-one-region - Fix compilation error on windows - ... and 7 more: https://git.openjdk.java.net/jdk/compare/15fd8a30...37120376 ------------- Changes: https://git.openjdk.java.net/jdk/pull/5181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=15 Stats: 380 lines in 12 files changed: 342 ins; 5 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From mli at openjdk.java.net Fri Oct 29 12:20:42 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Fri, 29 Oct 2021 12:20:42 GMT Subject: RFR: 8254739: G1: Optimize evacuation failure for regions with few failed objects [v17] In-Reply-To: References: Message-ID: > This is a try to optimize evcuation failure for regions. > I record every evacuation failure object per region (by G1EvacuationFailureObjsInHR), and then iterate (which indeed includes compact/sort/iteration) these objects directly in RemoveSelfForwardPtrHRClosure. > > I have tested it with following parameters, > > - -XX:+ParallelGCThreads=1/32/64 > - -XX:G1EvacuationFailureALotInterval=1 > - -XX:G1EvacuationFailureALotCount=2/10/100/1000/10000/100000 > > It saves "Remove Self Forwards" time all the time ,and in most condition it saves "Evacuate Collection Set" time. > > It brings some performance degradation when -XX:G1EvacuationFailureALotCount is low, such as *2*. To improve this a little, we can record the number evacuation failure object per region, and not record these objects when the number hit some limit. But I'm not sure if it's necessary to do so, as I think such condition is so extreme to be met in real environment, although I'm not quite sure. Hamlin Li has updated the pull request incrementally with one additional commit since the last revision: Refine code based on Thomas' suggestion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5181/files - new: https://git.openjdk.java.net/jdk/pull/5181/files/37120376..82c172a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5181&range=15-16 Stats: 80 lines in 7 files changed: 11 ins; 42 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/5181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5181/head:pull/5181 PR: https://git.openjdk.java.net/jdk/pull/5181 From lkorinth at openjdk.java.net Fri Oct 29 12:25:29 2021 From: lkorinth at openjdk.java.net (Leo Korinth) Date: Fri, 29 Oct 2021 12:25:29 GMT Subject: RFR: 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Message-ID: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com> Code seems to compile without the field. ------------- Commit messages: - 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Changes: https://git.openjdk.java.net/jdk/pull/6171/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6171&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276121 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6171.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6171/head:pull/6171 PR: https://git.openjdk.java.net/jdk/pull/6171 From duke at openjdk.java.net Fri Oct 29 13:20:22 2021 From: duke at openjdk.java.net (duke) Date: Fri, 29 Oct 2021 13:20:22 GMT Subject: Withdrawn: 8272611: Use parallel heap inspection when print classhisto info in gc log In-Reply-To: References: Message-ID: On Wed, 18 Aug 2021 07:35:50 GMT, Bin Liao wrote: > This patch helps to enhance the heap inspection with parallel threads when print classhisto info in gc log. > > I have built it on linux x86_64 and run test-tier1 successfully > > --------- > ### Progress > - [x] Change must not contain extraneous whitespace > - [x] Commit message must refer to an issue > - [ ] Change must be properly reviewed > > > > ### Reviewing >
Using git > > Checkout this PR locally: \ > `$ git fetch https://git.openjdk.java.net/jdk pull/5158/head:pull/5158` \ > `$ git checkout pull/5158` > > Update a local copy of the PR: \ > `$ git checkout pull/5158` \ > `$ git pull https://git.openjdk.java.net/jdk pull/5158/head` > >
>
Using Skara CLI tools > > Checkout this PR locally: \ > `$ git pr checkout 5158` > > View PR using the GUI difftool: \ > `$ git pr show -t 5158` > >
>
Using diff file > > Download this PR as a diff file: \ > https://git.openjdk.java.net/jdk/pull/5158.diff > >
This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/5158 From ayang at openjdk.java.net Fri Oct 29 13:32:14 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Fri, 29 Oct 2021 13:32:14 GMT Subject: RFR: 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp In-Reply-To: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com> References: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com> Message-ID: On Fri, 29 Oct 2021 12:18:22 GMT, Leo Korinth wrote: > Code seems to compile without the field. LGTM and trivial. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6171 From tschatzl at openjdk.java.net Fri Oct 29 13:48:10 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 29 Oct 2021 13:48:10 GMT Subject: RFR: 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp In-Reply-To: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com> References: <83doPVtb6cQqk0irFRALy78z3JWngJZ9uIgZYc2dkn4=.a55a665f-85fd-441b-a5d5-dd5c0eb42aab@github.com> Message-ID: On Fri, 29 Oct 2021 12:18:22 GMT, Leo Korinth wrote: > Code seems to compile without the field. Ship it (without the 24h wait). ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6171 From manc at openjdk.java.net Fri Oct 29 22:37:29 2021 From: manc at openjdk.java.net (Man Cao) Date: Fri, 29 Oct 2021 22:37:29 GMT Subject: RFR: 8275080: G1CollectedHeap::expand() returns the wrong value Message-ID: Hi all, Could we get reviews for this minor bug fix? See https://bugs.openjdk.java.net/browse/JDK-8275080 for details. It is authored by colleague Jonathan Joo, and he tested locally with jtreg tier1 and DaCapo benchmarks. ------------- Commit messages: - Fix expand output Changes: https://git.openjdk.java.net/jdk/pull/6178/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6178&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275080 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6178.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6178/head:pull/6178 PR: https://git.openjdk.java.net/jdk/pull/6178 From zgu at openjdk.java.net Sat Oct 30 13:03:28 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Sat, 30 Oct 2021 13:03:28 GMT Subject: RFR: 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Message-ID: There is subtle race when concurrent GC comes out of final mark safepoint: an allocation failure occurred before control thread checks OOM conditional, that triggers degenerated GC enters "mark" degenerated point. Degenerated GC re-executes final mark, then switching off SATB, but it is already off, because concurrent GC already completed final mark, that triggers the assertion. The solution is to consult concurrent_mark_in_progress flag when selects degen-point. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - v0 Changes: https://git.openjdk.java.net/jdk/pull/6179/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6179&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276201 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6179.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6179/head:pull/6179 PR: https://git.openjdk.java.net/jdk/pull/6179 From tschatzl at openjdk.java.net Sat Oct 30 20:39:40 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Sat, 30 Oct 2021 20:39:40 GMT Subject: RFR: 8275080: G1CollectedHeap::expand() returns the wrong value In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 22:27:05 GMT, Man Cao wrote: > Hi all, > > Could we get reviews for this minor bug fix? See https://bugs.openjdk.java.net/browse/JDK-8275080 for details. > It is authored by colleague Jonathan Joo, and he tested locally with jtreg tier1 and DaCapo benchmarks. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6178 From kbarrett at openjdk.java.net Sun Oct 31 02:58:11 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 31 Oct 2021 02:58:11 GMT Subject: RFR: 8275080: G1CollectedHeap::expand() returns the wrong value In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 22:27:05 GMT, Man Cao wrote: > Hi all, > > Could we get reviews for this minor bug fix? See https://bugs.openjdk.java.net/browse/JDK-8275080 for details. > It is authored by colleague Jonathan Joo, and he tested locally with jtreg tier1 and DaCapo benchmarks. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6178 From manc at openjdk.java.net Sun Oct 31 05:01:12 2021 From: manc at openjdk.java.net (Man Cao) Date: Sun, 31 Oct 2021 05:01:12 GMT Subject: Integrated: 8275080: G1CollectedHeap::expand() returns the wrong value In-Reply-To: References: Message-ID: <6b-LPUxeD2TqvoScnx1PO0dplb6UQkb5NSuU4oJgC78=.94c4c214-c747-4ca7-8abb-2cf0d51f544c@github.com> On Fri, 29 Oct 2021 22:27:05 GMT, Man Cao wrote: > Hi all, > > Could we get reviews for this minor bug fix? See https://bugs.openjdk.java.net/browse/JDK-8275080 for details. > It is authored by colleague Jonathan Joo, and he tested locally with jtreg tier1 and DaCapo benchmarks. This pull request has now been integrated. Changeset: bf2e9ee9 Author: Man Cao URL: https://git.openjdk.java.net/jdk/commit/bf2e9ee9d321ed289466b2410f12ad10504d01a2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8275080: G1CollectedHeap::expand() returns the wrong value Co-authored-by: Jonathan Joo Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/6178 From manc at openjdk.java.net Sun Oct 31 05:05:13 2021 From: manc at openjdk.java.net (Man Cao) Date: Sun, 31 Oct 2021 05:05:13 GMT Subject: RFR: 8275080: G1CollectedHeap::expand() returns the wrong value In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 22:27:05 GMT, Man Cao wrote: > Hi all, > > Could we get reviews for this minor bug fix? See https://bugs.openjdk.java.net/browse/JDK-8275080 for details. > It is authored by colleague Jonathan Joo, and he tested locally with jtreg tier1 and DaCapo benchmarks. Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/6178