May 2020 - hotspot-gc-dev

RFR (S) 8245720: Shenandoah: improve configuration logging
by Aleksey Shipilev 26 May '20

26 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245720 As the follow up of JDK-8244817 for Shenandoah GC, it makes sense to enable Shenandoah to print similar info. Example output: [0.006s][info][gc] Using Shenandoah [0.006s][info][gc] Heuristics ergonomically sets -XX:+ExplicitGCInvokesConcurrent [0.006s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahImplicitGCInvokesConcurrent [0.360s][info][gc,init] Version: 15-internal+0-adhoc.shade.jdk-jdk (fastdebug) [0.360s][info][gc,init] CPUs: 16 total, 16 available [0.360s][info][gc,init] Memory: 125G [0.360s][info][gc,init] Large Page Support: Disabled [0.360s][info][gc,init] NUMA Support: Disabled [0.360s][info][gc,init] Compressed Oops: Enabled (Zero based) [0.360s][info][gc,init] Heap Min Capacity: 1G [0.360s][info][gc,init] Heap Initial Capacity: 1G [0.360s][info][gc,init] Heap Max Capacity: 10G [0.360s][info][gc,init] Pre-touch: Disabled [0.360s][info][gc,init] Mode: Snapshot-At-The-Beginning (SATB) [0.360s][info][gc,init] Heuristics: Adaptive [0.360s][info][gc,init] Heap Region Count: 2560 [0.360s][info][gc,init] Heap Region Size: 4M [0.360s][info][gc,init] TLAB Size Max: 4M [0.360s][info][gc,init] Humongous Object Threshold: 4M [0.360s][info][gc,init] Reference Processing: Parallel discovery, Parallel processing [0.360s][info][gc,init] Parallel Workers: 8 [0.360s][info][gc,init] Concurrent Workers: 4 Ready I am thinking to just inline the upstream superclass InitLogger into ShenandoahInitLogger when backporting this to 11u and 8u. Webrev: https://cr.openjdk.java.net/~shade/8245720/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey

2 2

RFR: 8244817: Add configuration logging similar to ZGCs to other GCs
by stefan.johansson＠oracle.com 26 May '20

26 May '20

Hi, Please review this enhancement to improve startup logging for G1, Parallel and Serial. Webrev: http://cr.openjdk.java.net/~sjohanss/8244817/00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8244817 Summary ZGC has some really nice initialization logging that really helps when analyzing multiple logs. It would be nice to have something similar in the other GCs. This change adds a InitLogger which can be used to print basic configuration that might be interesting to have in the GC logs. ZGC have some specific things in their logs and I've not included changing Z to make use of the new InitLogger, but this can be done as a follow up if it makes sense. After some discussion with different people I decided to avoid adding to the CollectedHeap interface. Instead all GCs that make use of this should call the InitLogger in their initialization code. There might be more information that make sense to put into to this block of logging and I plan to file a few follow-up. For example, to look at G1s perodic GC startup logging, but also to change the the compressed oops logging that become somewhat duplicated on info level after this change. Testing Mach5 1-3 Thanks, Stefan

4 11

RFR (XS) 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
by Aleksey Shipilev 25 May '20

25 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245757 At present, enabling -XX:+AlwaysPreTouch implicitly disables uncommit and sets the heap size to Xmx. This is not coherent with the rest of OpenJDK garbage collectors that only pretouch when the actual commit happens. Shenandoah should do the same. It would still be recommended to set -Xmx == -Xms for AlwaysPreTouch to work without excess latencies. Webrev: https://cr.openjdk.java.net/~shade/8245757/webrev.01/ Testing: hotspot_gc_shenandoah; ad-hoc perf runs -- Thanks, -Aleksey

2 1

RFR (XS) 8245755: Shenandoah: missing logging for CWR Roots
by Aleksey Shipilev 25 May '20

25 May '20

Bug: https://bugs.openjdk.java.net/browse/JDK-8245755 JDK-8244953 introduced the Roots/Rendezvous split in CWR logging. Yet, there is no "Roots" counter in the gc+stats, because there is nothing that tracks it. Fix: diff -r 403587ab7d6e src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Mon May 25 21:02:37 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Mon May 25 21:14:26 2020 +0200 @@ -1852,12 +1852,13 @@ } }; void ShenandoahHeap::op_weak_roots() { if (is_concurrent_weak_root_in_progress()) { { + ShenandoahTimingsTracker t(ShenandoahPhaseTimings::conc_weak_roots_work); ShenandoahGCWorkerPhase worker_phase(ShenandoahPhaseTimings::conc_weak_roots_work); ShenandoahConcurrentWeakRootsEvacUpdateTask task(ShenandoahPhaseTimings::conc_weak_roots_work); workers()->run_task(&task); if (!ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { set_concurrent_weak_root_in_progress(false); Testing: hotspot_gc_shenandoah, eyeballing gc+stats -- Thanks, -Aleksey

2 1

RFR (S) 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch
by Aleksey Shipilev 25 May '20

25 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245754 ShenandoahAlwaysPreTouch flag dates back to the times when ShenandoahHeap used VirtualSpace for reserving/committing heap. To workaround single-threaded pretouch code in VirtualSpace, a new flag was needed: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2016-October/000892.… That code is long gone now, and current Shenandoah just reserves/commits from OS directly. Therefore, this flag is no longer needed. It actually confuses logging in JDK-8245720. Fix: https://cr.openjdk.java.net/~shade/8245754/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release}; ad-hoc runs -- Thanks, -Aleksey

2 1

RFR (S) 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties
by Aleksey Shipilev 25 May '20

25 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245726 JDK-8245720 would print most stuff in Capitalized Form. GC modes already print in capitalized form. Heuristics should do the same. Additionally, lifting the is_diagnostic/is_experimental implementations right into header makes it a bit more clean, and matches what modes are doing. Webrev: https://cr.openjdk.java.net/~shade/8245726/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey

2 1

[G1] Why humongous object bytes allocated after a collection are not recorded in G1Policy::_bytes_allocated_in_old_since_last_gc?
by Luo, Ziyi 25 May '20

25 May '20

Hi, I have a question about humongous object allocation result in g1CollectedHeap: http://hg.openjdk.java.net/jdk/jdk/file/6d7c3a8bfab6/src/hotspot/share/gc/g… http://hg.openjdk.java.net/jdk/jdk/file/6d7c3a8bfab6/src/hotspot/share/gc/g… L874 returns the result after a successful humongous allocation. L893 returns the result after a successful G1CollectForAllocation. In the former case, the allocated bytes are recorded in G1Policy::_bytes_allocated_in_old_since_last_gc in L873. But bytes in the latter case are not. Is this intentional or a mistake? Best, Ziyi

2 1

RFR (S) 8245465: Shenandoah: test_in_cset can use more efficient encoding
by Aleksey Shipilev 25 May '20

25 May '20

RFE: https://cr.openjdk.java.net/~shade/8245465/webrev.02/ See the rationale in the bug itself. Webrev: https://bugs.openjdk.java.net/browse/JDK-8245465 Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah, eyeballing asm, benchmarks -- Thanks, -Aleksey

3 4

RFR (S) 8244729: Shenandoah: remove resolve paths from SBSA::generate_shenandoah_lrb
by Aleksey Shipilev 21 May '20

21 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8244729 After JDK-8232992, we don't need the resolve path in ShenandoahBarrierSetAssembler. The slowpath call to ShenandoahRuntime would fix the reference, and we would not have to resolve it once again. Webrev: https://cr.openjdk.java.net/~shade/8244729/webrev.01/ Testing: hotspot_gc_shenandoah {x86_64, aarch64} -- Thanks, -Aleksey

2 1

RFR (S) 8245464: Shenandoah: allocate collection set bitmap at lower addresses
by Aleksey Shipilev 21 May '20

21 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245464 See the rationale in the bug itself. Webrev: https://cr.openjdk.java.net/~shade/8245464/webrev.02/ Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah -- Thanks, -Aleksey

2 1