September 2020 - hotspot-gc-dev

RFR: 8253220: Epsilon: clean up unused code/declarations
by Aleksey Shipilev 16 Sep '20

16 Sep '20

Static analysis shows a few #include statements in gc/epsilon that are not needed. Testing: Linux x86_64 fastdebug gc/epsilon ------------- Commit messages: - 8253220: Epsilon: clean up unused code/declarations Changes: https://git.openjdk.java.net/jdk/pull/199/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=199&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253220 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/199.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/199/head:pull/199 PR: https://git.openjdk.java.net/jdk/pull/199

3 3

RFR: 8253222: Shenandoah: unused AlwaysTrueClosure after JDK-8246591
by Aleksey Shipilev 16 Sep '20

16 Sep '20

Static analysis shows the AlwaysTrueClosure is not needed in `ShenandoahRootScanner::roots_do` after JDK-8246591. Testing: Linux x86_64 tier1_gc_shenandoah ------------- Commit messages: - 8253222: Shenandoah: unused AlwaysTrueClosure after JDK-8246591 Changes: https://git.openjdk.java.net/jdk/pull/201/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=201&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253222 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/201.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/201/head:pull/201 PR: https://git.openjdk.java.net/jdk/pull/201

2 2

Re: RFR: 8252114: Windows-AArch64: Enable and test ZGC and ShenandoahGC [v2]
by Roman Kennke 15 Sep '20

15 Sep '20

On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith <mbeckwit(a)openjdk.org> wrote: >> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will enable and run microbenchmarks and scaling >> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015 (heap and multi-JVM) scaling tests for both >> the GCs. > > Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision: > > x$OPENJDK_TARGET_CPU" = "xaarch64" > > Incorporating Aleksey's comments to incorporate 'x' Looks good to me. Thanks! ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/97

1 0

RFR: 8253169: [BACKOUT] Improve large object handling during evacuation
by Kim Barrett 15 Sep '20

15 Sep '20

Revert "8027545: Improve object array chunking test in G1's copy_to_survivor_space" Revert "8158045: Improve large object handling during evacuation" Revert "8027761: Investigate fast-path for scanning only objects with references during gc" This reverts commit dafcf1056f5cb1772eb61fca9ee46fe24c83fc09. ------------- Commit messages: - Revert "8027545: Improve object array chunking test in G1's copy_to_survivor_space" Changes: https://git.openjdk.java.net/jdk/pull/181/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=181&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253169 Stats: 467 lines in 8 files changed: 28 ins; 405 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/181.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/181/head:pull/181 PR: https://git.openjdk.java.net/jdk/pull/181

3 4

Re: RFR: 8253169: [BACKOUT] Improve large object handling during evacuation
by Kim Barrett 15 Sep '20

15 Sep '20

On Tue, 15 Sep 2020 13:50:33 GMT, Kim Barrett <kbarrett(a)openjdk.org> wrote: >> Revert "8027545: Improve object array chunking test in G1's copy_to_survivor_space" >> Revert "8158045: Improve large object handling during evacuation" >> Revert "8027761: Investigate fast-path for scanning only objects with references during gc" >> >> This reverts commit dafcf1056f5cb1772eb61fca9ee46fe24c83fc09. > > Revert "8027545: Improve object array chunking test in G1's copy_to_survivor_space" > Revert "8158045: Improve large object handling during evacuation" > Revert "8027761: Investigate fast-path for scanning only objects with references during gc" Currently doing test builds of all Oracle supported platforms. ------------- PR: https://git.openjdk.java.net/jdk/pull/181

1 0

Integrated: 8027545: Improve object array chunking test in G1's copy_to_survivor_space
by Kim Barrett 15 Sep '20

15 Sep '20

On Wed, 9 Sep 2020 07:24:27 GMT, Kim Barrett <kbarrett(a)openjdk.org> wrote: > This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. This pull request has now been integrated. Changeset: dafcf105 Author: Kim Barrett <kbarrett(a)openjdk.org> URL: https://git.openjdk.java.net/jdk/commit/dafcf105 Stats: 467 lines in 8 files changed: 28 ins; 405 del; 34 mod 8027545: Improve object array chunking test in G1's copy_to_survivor_space 8158045: Improve large object handling during evacuation 8027761: Investigate fast-path for scanning only objects with references during gc Generate multiple partial array tasks for large objArrays. Reviewed-by: sjohanss, ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/90

1 0

Re: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v3]
by Kim Barrett 15 Sep '20

15 Sep '20

> This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: Respond to reviews by sjohanss and tschatzl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/90/files - new: https://git.openjdk.java.net/jdk/pull/90/files/1981c392..1c8c0a82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01-02 Stats: 11 lines in 4 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk/pull/90

1 0

RFR: 8249676: [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs
by Thomas Schatzl 15 Sep '20

15 Sep '20

Hi, please review this re-application of JDK-8249676. The change passes two tier8 (plus tier1-7 which never were a problem) runs w/o problems; the crashes I reported in the original review are gone after recent (other) changes. Note that this PR contains two commits: the vanilla original patch and an update to fix merge errors with the recent IHOP changes. Thanks, Thomas ------------- Commit messages: - Merge issues resolved - Original patch Changes: https://git.openjdk.java.net/jdk/pull/108/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=108&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249676 Stats: 380 lines in 3 files changed: 178 ins; 63 del; 139 mod Patch: https://git.openjdk.java.net/jdk/pull/108.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/108/head:pull/108 PR: https://git.openjdk.java.net/jdk/pull/108

5 12

G1 crashes
by Doerr, Martin 15 Sep '20

15 Sep '20

Hi, we see a lot of G1 crashes when running JCK tests. E.g. api/java_util/TreeMap/EntrySetParallelStream.html # SIGSEGV (0xb) at pc=0x00007f5b557f2d15, pid=77863, tid=79363 # # JRE version: OpenJDK Runtime Environment (16.0.0.1) (fastdebug build 16.0.0.1-internal+0-adhoc.openjdk.jdk) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 16.0.0.1-internal+0-adhoc.openjdk.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xae1d15] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x4b5 Stack: [0x00007f5ae7afb000,0x00007f5ae7bfb000], sp=0x00007f5ae7bf9930, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xae1d15] G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+0x4b5 V [libjvm.so+0xb52f1a] G1ParScanThreadState::trim_queue_partially()+0x3a V [libjvm.so+0xb5ad3f] G1ScanHRForRegionClosure::scan_heap_roots(HeapRegion*)+0x8ef V [libjvm.so+0xb4f4dd] G1RemSet::scan_heap_roots(G1ParScanThreadState*, unsigned int, G1GCPhaseTimes::GCParPhases, G1GCPhaseTimes::GCParPhases)+0x37d V [libjvm.so+0xa59d83] G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x43 V [libjvm.so+0xa5c187] G1EvacuateRegionsBaseTask::work(unsigned int)+0x57 V [libjvm.so+0x185782c] GangWorker::loop()+0xac V [libjvm.so+0x17203f6] Thread::call_run()+0xf6 V [libjvm.so+0x133b706] thread_native_entry(Thread*)+0x116 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000f7d7b844c Seem like the thread has loaded garbage from the queue. Is this a known problem? Best regards, Martin

2 2

Re: RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space [v2]
by Kim Barrett 15 Sep '20

15 Sep '20

> This is rework of initial change from before the transition to git. > The initial RFR email is attached below. > > The primary change is to limit the number of partial array tasks in > the queues for any given array. The original change just split up an > array into N tasks that were all enqueued at once. But for a large > array this could be a lot of tasks, leading to significant and > unnecessary queue expansion. Instead we now limit the number of tasks > for a given array based on the number of workers, and only gradually > add tasks up to that limit. This gives other threads an opportunity > to steal such tasks, while still keeping queue growth under control. > > Most of the calculation for this is handled by a new helper class, so > this can later be shared with ParallelGC. > > The dispatch on array klass type for has also been changed. It now > affirmatively breaks Project Valhalla, rather than quietly doing > something that probably isn't what is actually wanted. I'll discuss > with them so there is a plan for dealing with it when they take this > update. > > Ran tier1-6 in mach5 and some local stress tests. > > Performance testing was unchanged from previous, except I wasn't able > to reproduce the small specjbb2015 critical-jops improvement > previously seen on one platform. My suspicion is that improvement was > a statistical abberation. > > --- Initial RFR email --- > > RFR: 8158045: Improve large object handling during evacuation > RFR: 8027761: Investigate fast-path for scanning only objects with references during gc > RFR: 8027545: Improve object array chunking test in G1's copy_to_survivor_space > > Please review this change to type dispatching and handling in G1's > evacuation copying, in order to improve the hot paths and improve array > handling. This change addresses several closely co-located enhancement > requests; it seemed difficult to split them up in a sensible way. > > do_copy_to_survivor_space now gets the klass of the object being copied > once, up front, for use in multiple places. This avoids fetching (including > re-decoding when compressed) the klass multiple times. This addresses part > of JDK-8027545. > > Moved check for and handling of string deduplication later, only applying it > after the special array cases have been dealt with, since strings are not > arrays. (They are header objects pointing to an array of character values.) > > Special case typeArray, doing nothing other than the copy, since they > contain no oops that need to be processed. This addresses JDK-8027761. > > Changed handling of objArray, pushing all of the partial array tasks up > front, rather than processing the current chunk after pushing a single task > for the remaining work. This addresses JDK-8158045. > > As part of these, cached some more frequently accessed values in > G1ParScanThreadState member variables. This addresses part of part of > JDK-8027545. > > While both the old and new code will work for Project Valhalla, the handling > of arrays should be updated for that project, which introduces new array > types. > > Deleted a lingering reference to G1ParScanPartialArrayClosure that was > deleted long ago (JDK-8035330, JDK 9). > > CR: > https://bugs.openjdk.java.net/browse/JDK-8158045 > https://bugs.openjdk.java.net/browse/JDK-8027761 > https://bugs.openjdk.java.net/browse/JDK-8027545 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8158045/open.00/ > > Testing: > tier1-3 > > performance testing - seems to be at worst performance neutral, with a > statistically significant 3% improvement in specjbb2015 critical-jops seen > on one platform. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: Respond to reviews by ayang and sjohanss. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/90/files - new: https://git.openjdk.java.net/jdk/pull/90/files/9397514e..1981c392 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=90&range=00-01 Stats: 152 lines in 6 files changed: 122 ins; 14 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/90.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/90/head:pull/90 PR: https://git.openjdk.java.net/jdk/pull/90

5 4