April 2019 - hotspot-gc-dev

RFR: 8221359: Eliminate SATBMarkQueueSet::filter_thread_buffers
by Kim Barrett 02 May '19

02 May '19

Please review this removal of the function used by G1 to clean up the per-thread SATB queues when a young-only collection will have moved young object references present in those queues. This cleanup isn't needed, since the same cleanup may be done before enqueuing a completed queue buffer, and will also be done during the eventual processing of the buffer contents. Having this function called during a pause just moves some work from the concurrent phase into a pause, which isn't a good tradeoff. Also renamed G1GCPhaseTimes::ExtRootScanSubPhases(Start|End) => ExtRootScanSubPhases(First|Last), to remove the ambiguity over whether "end" is inclusive or exclusive. (It was inclusive here.) CR: https://bugs.openjdk.java.net/browse/JDK-8221359 Webrev: http://cr.openjdk.java.net/~kbarrett/8221359/open.00/ Testing: mach5 tier1-3

3 4

RFR(M) 8222992: Shenandoah: Pre-evacuate all roots
by Zhengyu Gu 02 May '19

02 May '19

Since we switched to strong to-space invariant, if we pre-evacuate all roots, the roots should only contain to-space references, until next evacuation cycle. Therefore, we can avoid a couple of update roots calls in regular paths. Also, make code easy to reason. The change may prolong final_mark pause. It is temporary. I intent to move several pre-evacuated roots to concurrent phase, in followup RFEs. Bug: https://bugs.openjdk.java.net/browse/JDK-8222992 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222992/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu

2 8

RFR (XS): 8220388: Increase -inlinehint-threshold for Clang to avoid G1 pause time regression
by Man Cao 29 Apr '19

29 Apr '19

Hi all, I propose to increase the -inlinehint-threshold for Clang build: Webrev: https://cr.openjdk.java.net/~manc/8220388/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8220388 The background and performance impact is described in the RFE. In summary, increasing the -inlinehint-threshold could noticeably reduce GC pause time for G1 when building the JVM with Clang. I have a couple of questions though: (1) I agree that a better long-term solution might be to identify those performance-critical functions and mark them with "ALWAYSINLINE" instead of "inline". However, it might be difficult to identify all those functions, and similar issue might arise in collectors other than G1, or in other places in HotSpot. Currently ALWAYSINLINE is rarely used across HotSpot. I'm not sure if there is a convention to prefer "inline" over "ALWAYSINLINE". If we go down this path, we might end up changing many "inline" to "ALWAYSINLINE" all over the places, due to the cascading effect of inlining. (2) Since this change only affects Clang build, and Clang is only officially supported for Mac OS ( https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms) should I send this patch to broader mailing lists such as build-dev, hotspot-dev? Thanks, Man

4 7

RFR: 8198505: Remove CollectorPolicy and its subclasses
by Stefan Karlsson 29 Apr '19

29 Apr '19

Hi all, Please review this patch to remove CollectorPolicy and its subclasses. https://cr.openjdk.java.net/~stefank/8198505/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8198505 From the RFE: ========== I'd like to propose that we get rid of the CollectorPolicy classes. The CollectorPolicy classes contains a mix of features to support the CollectedHeaps. A few of them are: * Have virtual functions that either CMS or Serial can override. This was important when CMS didn't have it's own CollectedHeap. But CMSHeap was recently added, so this isn't needed anymore. * Has common allocation code for CMS and Serial. Can be moved to GenCollectedHeap. * Deal with parts of the heap sizing and corresponding flags. A lot of the flag handling has been moved to the GCArguments classes. We should move the CollectorPolicy flag handling functions there as well. * Keeps the state for the SoftRefPolicy. Separate this out to it's own class. * Has the satisfy_failed_metadata_allocation function. No need to be located in CollectorPolicy. ========== I started this work last year and have already pushed a number of sub RFEs: JDK-8198373: Remove CollectorPolicy::is/as functions JDK-8198507: Remove CollectorPolicy::create_rem_set JDK-8198509: Move satisfy_failed_metadata_allocation out from CollectorPolicy JDK-8198511: Move allocation functions from GenCollectorPolicy to GenCollectedHeap JDK-8198515: Extract SoftReferencePolicy code out of CollectorPolicy JDK-8198525: Move _size_policy out of GenCollectorPolicy into GenCollectedHeap JDK-8198528: Move GenerationSpecs from GenCollectorPolicy to GenCollectedHeap JDK-8198530: Move _gc_policy_counters from GenCollectorPolicy to GenCollectedHeap This patch removes the last bits. It mainly moves flag handling and sizing information over to the GCArguments. Most of the gc flag handling has already been moved there, so it makes sense to move the rest over to that sub-system. For Shenandoah I only moved the flag handling code, but left the ShenandoahCollectorPolicy class as a Shenandoah internal implementation detail. Some GCs perform the initialization a little bit differently than others. For example: - Parallel runs some initialization code twice - Some simply uses the default initialize_heap_flags_and_sizes, while others override it. - G1 and Shenandoah needs the heap size before alignments can be set up. The last item is a bit awkward because there's a circular dependency between figuring out the heap size and the heap region size. We have this initialization sequence: void GCArguments::initialize_before_create_heap() { initialize_alignments(); initialize_heap_flags_and_sizes(); initialize_size_info(); } Today G1 and Shenandoah sets up the heap region sizes in initialize_alignments, to overcome this circular dependencies. There might an opportunity for further cleanups in this area. Tested with tier1-3 and tier1-7 on Linux x64. Thanks, StefanK

2 4

JVM crashes constantly when High GC happens
by shang xinli 26 Apr '19

26 Apr '19

Hi all, We hit crashes pretty constantly when the GC is high when using CMS GC. We switched to G1GC but it still crashes at the same places. It also crashes with the newest version of JDK. Anybody has a clue how to investigate why? The call stack for G1GC is: #0 0x00007fcb7d665067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fcb7d666448 in __GI_abort () at abort.c:89 #2 0x00007fcb7cf78ba9 in os::abort(bool) (dump_core=<optimized out>) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/os/linux/vm/os_linux.cpp:1509 #3 0x00007fcb7d12fff4 in VMError::report_and_die() (this=this@entry=0x7fcb5f8cc660) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/utilities/vmError.cpp:1060 #4 0x00007fcb7d1307c7 in crash_handler(int, siginfo_t*, void*) (sig=11, info=0x7fcb5f8cc8b0, ucVoid=0x7fcb5f8cc780) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/os/linux/vm/vmError_linux.cpp:106 #5 0x00007fcb7e018890 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007fcb7cf690c3 in oopDesc::print_on(outputStream*) const (this=0x7fb629d4b7a8, st=0x7fcb5f8cd410) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/oops/oop.cpp:43 #7 0x00007fcb7cf8342b in os::print_register_info(outputStream*, void*) (st=0x7fcb5f8cd410, context=0x7fcb5f8cd680) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:847 #8 0x00007fcb7d12ee98 in VMError::report(outputStream*) (this=0x7fcb5f8cd510, st=st@entry=0x7fcb5f8cd410) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/utilities/vmError.cpp:542 #9 0x00007fcb7d12fc6d in VMError::report_and_die() (this=this@entry=0x7fcb5f8cd510) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/utilities/vmError.cpp:971 #10 0x00007fcb7cf827f7 in JVM_handle_linux_signal(int, siginfo_t*, void*, int) (sig=11, info=0x7fcb5f8cd7b0, ucVoid=0x7fcb5f8cd680, abort_if_unrecognized=<optimized out>) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp:541 #11 0x00007fcb7cf75f58 in signalHandler(int, siginfo_t*, void*) (sig=11, info=0x7fcb5f8cd7b0, uc=0x7fcb5f8cd680) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/os/linux/vm/os_linux.cpp:4432 #12 0x00007fcb7e018890 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007fcb7cb4bea8 in CMTask::deal_with_reference(oopDesc*) (this=0x7fb629d4b968) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/oops/oop.inline.hpp:76 #14 0x00007fcb7cb4bea8 in CMTask::deal_with_reference(oopDesc*) (this=0x7fb629d4b968) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/oops/oop.inline.hpp:492 #15 0x00007fcb7cb4bea8 in CMTask::deal_with_reference(oopDesc*) (task_card_bm=0x7fcb740d6bb0, marked_bytes_array=0x7fcb740e5860, hr=0x7fcb7763e500, obj=0x7fb629d4b968, this=0x7fcb740cb730) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp:133 #16 0x00007fcb7cb4bea8 in CMTask::deal_with_reference(oopDesc*) (task_card_bm=0x7fcb740d6bb0, marked_bytes_array=0x7fcb740e5860, hr=0x7fcb7763e500, obj=0x7fb629d4b968, this=0x7fcb740cb730) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp:146 #17 0x00007fcb7cb4bea8 in CMTask::deal_with_reference(oopDesc*) (hr=0x7fcb7763e500, obj=0x7fb629d4b968, this=0x7fcb740f3e70) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp:293 #18 0x00007fcb7cb4bea8 in CMTask::deal_with_reference(oopDesc*) (this=0x7fcb740f3e70, obj=0x7fb629d4b968) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp:362 #19 0x00007fcb7cf5c761 in ObjArrayKlass::oop_oop_iterate_nv(oopDesc*, G1CMOopClosure*) (this=0x7fcb5f8cddc0, p=0x7f9356a5b588) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp:124 #20 0x00007fcb7cf5c761 in ObjArrayKlass::oop_oop_iterate_nv(oopDesc*, G1CMOopClosure*) (this=<optimized out>, obj=<optimized out>, closure=0x7fcb5f8cddc0) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/oops/objArrayKlass.cpp:556 #21 0x00007fcb7cb44400 in CMTask::drain_local_queue(bool) (blk=<optimized out>, this=0x7f92da000000) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/oops/oop.inline.hpp:735 #22 0x00007fcb7cb44400 in CMTask::drain_local_queue(bool) (obj=0x7f92da000000, this=0x7fcb740f3e70) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:3520 #23 0x00007fcb7cb44400 in CMTask::drain_local_queue(bool) (obj=0x7f92da000000, this=0x7fcb740f3e70) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.hpp:1174 #24 0x00007fcb7cb44400 in CMTask::drain_local_queue(bool) (this=0x7fcb740f3e70, partially=partially@entry=true) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:3930 #25 0x00007fcb7cb4b32a in CMBitMapClosure::do_bit(unsigned long) (partially=true, this=<optimized out>) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/oops/klass.inline.hpp:65 #26 0x00007fcb7cb4b32a in CMBitMapClosure::do_bit(unsigned long) (this=this@entry=0x7fcb5f8cdda0, offset=offset@entry=910241497) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:3554 #27 0x00007fcb7cb46cc9 in CMTask::do_marking_step(double, bool, bool) (mr=..., cl=0x7fcb5f8cdda0, this=0x7fcb740cb7b8) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp:179 #28 0x00007fcb7cb46cc9 in CMTask::do_marking_step(double, bool, bool) (this=this@entry=0x7fcb740f3e70, time_target_ms=10, do_termination=do_termination@entry=true, is_serial=is_serial@entry=false) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:4305 #29 0x00007fcb7cb4caa3 in CMConcurrentMarkingTask::work(unsigned int) (this=0x7fcb642f1d60, worker_id=1) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:1131 #30 0x00007fcb7d14c39a in GangWorker::loop() (this=0x7fcb740d0000) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/share/vm/utilities/workgroup.cpp:329 #31 0x00007fcb7cf77b62 in java_start(Thread*) (thread=0x7fcb740d0000) at /srv/jdk/openjdk-8-8u171-b11/src/hotspot/src/os/linux/vm/os_linux.cpp:790 #32 0x00007fcb7e011064 in start_thread (arg=0x7fcb5f8ce700) at pthread_create.c:309 #33 0x00007fcb7d71862d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

6 22

RFR: 8223016: ZGC: Fix misaligned statistics printout
by Per Liden 26 Apr '19

26 Apr '19

JDK-8221393 introduced a new ZStatSubPhase with long name, causing the avg/max columns in the statistics table to become misaligned. Bug: https://bugs.openjdk.java.net/browse/JDK-8223016 Webrev: http://cr.openjdk.java.net/~pliden/8223016/webrev.0 /Per

2 2

RFR: JDK-8220813: update hotspot tier1_gc tests depending on GC to use @requires vm.gc.X
by Ao Qi 26 Apr '19

26 Apr '19

Hi, JBS: https://bugs.openjdk.java.net/browse/JDK-8220813 Webrev: http://cr.openjdk.java.net/~aoqi/8220813/webrev.00/ If a particular GC is not supported, some hotspot tier1_gc tests fails. The patch allows tests to be skipped on platforms where a GC is not supported. Tested: before (configure using --with-jvm-features): configure TOTAL PASS FAIL ERROR default 251 251 0 0 -cmsgc 243 222 21 0 -epsilongc 229 229 0 0 -g1gc,-jfr 181 157 24 0 -parallelgc 241 219 22 0 -shenandoahgc 206 206 0 0 -zgc 251 251 0 0 after (configure using --with-jvm-features): configure TOTAL PASS FAIL ERROR default 251 251 0 0 -cmsgc 222 222 0 0 -epsilongc 229 229 0 0 -g1gc,-jfr 157 157 0 0 -parallelgc 219 219 0 0 -shenandoahgc 206 206 0 0 -zgc 251 251 0 0 before: VM_OPTIONS TOTAL PASS FAIL ERROR default 251 251 0 0 -XX:+UseG1GC 129 129 0 0 -XX:+UseSerialGC 65 65 0 0 -XX:+UseParallelGC 69 69 0 0 -XX:+UseConcMarkSweepGC 67 67 0 0 after: VM_OPTIONS TOTAL PASS FAIL ERROR default 251 251 0 0 -XX:+UseG1GC 121 121 0 0 -XX:+UseSerialGC 51 51 0 0 -XX:+UseParallelGC 60 60 0 0 -XX:+UseConcMarkSweepGC 66 66 0 0 The difference in VM_OPTIONS tests mainly comes from two reasons: 1. This patch make this kind of change: @requires vm.gc=="null" & !vm.graal.enabled => @requires vm.gc.ConcMarkSweep & !vm.graal.enabled Take gc/arguments/TestAlignmentToUseLargePages.java#id1 for example. Before the patch, even if VM_OPTIONS=-XX:+UseConcMarkSweepGC is set, gc/arguments/TestAlignmentToUseLargePages.java#id1 will not be executed (but the test is intended to test -XX:+UseConcMarkSweepGC). After the patch, the test will be executed if VM_OPTIONS=-XX:+UseConcMarkSweepGC is set. 2. If a test use a particular GC in the code (not in the jtreg tag fields) and another GC is passed by -XX:UseXGC, the test will be skipped. For example, gc/startup_warnings/TestG1.java uses -XX:+UseG1GC in the main method. This test will be skipped, when VM_OPTIONS=-XX:+UseConcMarkSweepGC is used. Before this patch, it will be executed. I am doing more tests and checking test results above. Could someone give some advice on this change? Thanks, Ao Qi

4 30

RFR: 8222182: ZGC: Use SoftMaxHeapSize to guide GC heuristics
by Per Liden 25 Apr '19

25 Apr '19

The ZDriector currently uses max heap size (-Xmx) as input when deciding on when to start a GC cycle. We should start using SoftMaxHeapSize instead. Of course, this change depends on JDK-8222145 "Add -XX:SoftMaxHeapSize flag", which is currently out for review. Bug: https://bugs.openjdk.java.net/browse/JDK-8222182 Webrev: http://cr.openjdk.java.net/~pliden/8222182/webrev.0 /Per

3 9

RFR (XS) 8222843: Print Shenandoah cset map addresses in hs_err
by Aleksey Shipilev 24 Apr '19

24 Apr '19

RFE: https://bugs.openjdk.java.net/browse/JDK-8222843 Fix: diff -r 8eae2646fed8 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 23 10:58:24 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 23 11:13:05 2019 +0200 @@ -89,4 +89,7 @@ private: + jbyte* map_address() const { + return _cset_map; + } jbyte* biased_map_address() const { return _biased_cset_map; diff -r 8eae2646fed8 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 23 10:58:24 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 23 11:13:05 2019 +0200 @@ -538,4 +538,13 @@ p2i(reserved_region().end())); + ShenandoahCollectionSet* cset = collection_set(); + st->print_cr("Collection set:"); + if (cset != NULL) { + st->print_cr(" - map (vanilla): " PTR_FORMAT, p2i(cset->map_address())); + st->print_cr(" - map (biased): " PTR_FORMAT, p2i(cset->biased_map_address())); + } else { + st->print_cr(" (NULL)"); + } + st->cr(); MetaspaceUtils::print_on(st); Testing: eyeballing hs_errs -- Thanks, -Aleksey

2 1

RFR (S) 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr
by Aleksey Shipilev 24 Apr '19

24 Apr '19

Bug: https://bugs.openjdk.java.net/browse/JDK-8222838 Webrev: http://cr.openjdk.java.net/~shade/8222838/webrev.01/ See the bug for the example failure that this fix resolves. Code comments should tell about the implementation details for the fix. Testing: Linux {x86_64, aarch64} hotspot_gc_shenandoah {+Coops, -Coops}, Windows x86_64 ad-hoc tests, eyeballing NMT summary -- Thanks, -Aleksey

2 1