May 2020 - hotspot-gc-dev

RFR (S) 8245718: Epsilon: improve configuration logging
by Aleksey Shipilev 28 May '20

28 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245718 As the follow up of JDK-8244817 for Epsilon GC, it makes sense to enable Epsilon to print similar info. Webrev: https://cr.openjdk.java.net/~shade/8245718/webrev.01/ Testing: gc/epsilon, eyeballing gc+init logs, jdk-submit (running) -- Thanks, -Aleksey

2 5

RFR: 8245955: Shenandoah: Remove LRB/is_redundant optimization
by Roman Kennke 28 May '20

28 May '20

Just before expanding LRBs in C2, we check whether or not the LRB is actually used for anything useful. This optimization is a bit odd, it doesn't really follow the usual pattern for such things (it should be done by overwriting Ideal/Identity in the consuming node, and the LRB would be eliminated when it has no users left). Also, the optimization doesn't actually seem to have any positive effect anymore. It used to be significant when we had to deal with null-checks, but this is gone. The only other thing left is OptimizeStaticFinals, which is already covered by C2 because it inlines such fields as constants. Also, this blocks an improvement to ensure that there's no safepoints between loads and LRBs because eliminating the LRB can leave from-space oops in local variables. I've run SPECjvm2008 and SPECjbb2015, and have seen no regressions. Some workloads even seem to benefit (in the range 1-2%) from this change, and it appears to be a stable, but I have no explanation yet why this should be the case. Bug: https://bugs.openjdk.java.net/browse/JDK-8245955 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8245955/webrev.00/ Testing: hotspot_gc_shenandoah, several runs of specjvm and specjbb without noticable regressions Roman

2 2

[15] RFR 8245827: Shenandoah: Cleanup Shenandoah code root iterators and root scanner
by Zhengyu Gu 27 May '20

27 May '20

ShenandoahCsetCodeRootsIterator and ShenandoahCSetRootScanner are only relevant to Traversal GC, which was removed by JDK-8242082, they should be removed as well. After removal, we can rename ShenandoahAllCodeRootsIterator and ShenandoahAllRootScanner back to ShenandoahCodeRootsIterator and ShenandoahRootScanner, respectively. Bug: https://bugs.openjdk.java.net/browse/JDK-8245827 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245827/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu

2 3

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

27 May '20

Hi Thomas, >Hi, > >On 23.05.20 00:30, Luo, Ziyi wrote: >> 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 >> > > the collection itself has some code to add the allocated bytes. In >the first case since there is no collection, that value needs to be >incremented manually. > >But you probably already know that, you filed JDK-8245511 :) Yes, this is about JDK-8245511. In IHOP, _bytes_allocated_in_old_since_last_gc is used to calculate the old gen allocation rate. In some jtreg tests (e.g., gc /TestSoftReferencesBehaviorOnOOME), I observed the following gc log output: GC(215) Pause Full (G1 Humongous Allocation) GC(215) Humongous regions: 0->0 ... GC(216) Basic information (value update) ... recent allocation size: 0B, recent allocation duration: 173.09ms, recent old gen allocation rate: 0.00B/s GC(216) Humongous regions: 111->111 Correct me if I were wrong: The allocated bytes during G1CollectForAllocation are considered as "on gc allocation". Since they are allocated during a pause, they should not be used to calculate the old gen allocation rate, thus are not included in G1Policy::_bytes_allocated_in_old_since_last_gc. If that's the case, for JDK-8245511, I need to adjust how the survived humongous regions in a GC is recorded. Thanks, Ziyi

2 2

[15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope
by Zhengyu Gu 27 May '20

27 May '20

Please review this patch that makes ShenandoahEvacOOMScope inline-able, also avoids calling ShenandoahHeap::heap() and Thread::current() if caller can provide them. The gain is not as noticeable as JDK-8245240 and JDK-8245288, but seems consistent. Bug: https://bugs.openjdk.java.net/browse/JDK-8245823 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu

3 7

RFR (XS) 8245814: Shenandoah: reconsider format specifiers for stats
by Aleksey Shipilev 27 May '20

27 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245814 Current log is misplaced because "CWR: Resolved Table Roots" is larger than the format specifier for it. Let's bump the specifier lengths. Also, make sure the US_WORKER_TIME_FORMAT matches the "empty" slot. I did it while changing its length from 3 to 4, but ultimately decided to keep at 3. Fix: diff -r bdeba1590341 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 16:36:08 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 16:42:43 2020 +0200 @@ -34,8 +34,9 @@ #include "utilities/ostream.hpp" -#define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" +#define SHENANDOAH_PHASE_NAME_FORMAT "%-30s" #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" +#define SHENANDOAH_US_WORKER_NOTIME_FORMAT "%3s" #define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" @@ -244,5 +245,5 @@ out->print(SHENANDOAH_US_WORKER_TIME_FORMAT ", ", tv * 1000000.0); } else { - out->print("%3s, ", "---"); + out->print(SHENANDOAH_US_WORKER_NOTIME_FORMAT ", ", "---"); } } Testing: hotspot_gc_shenandoah, eyeballing GC logs. -- Thanks, -Aleksey

2 1

RFR: 8245724: Move g1 periodic gc logging to G1InitLogger
by stefan.johansson＠oracle.com 27 May '20

27 May '20

Hi, Please review this change to move more G1 logging to gc+init. Webrev: http://cr.openjdk.java.net/~sjohanss/8245724/00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8245724 Summary The initial periodic GC logs are good candidates for being part of the G1InitLogger so I moved them there. Since this logging doesn't really fit in any of the existing categories I added print_gc_specific() to the InitLogger so that the GCs that want to add more stuff have a good place to put it. Testing Mach5 tier1-2 and local verification. Thanks, Stefan

3 3

[15] RFR 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots
by Zhengyu Gu 27 May '20

27 May '20

We have diagnostic flag "ShenandoahConcurrentScanCodeRoots" default to true for a long period of time without any issues, let's remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8245825 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245825/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu

2 1

RFR (S) 8245812: Shenandoah: compute root phase parallelism
by Aleksey Shipilev 26 May '20

26 May '20

RFE: https://bugs.openjdk.java.net/browse/JDK-8245812 Current gc+stats log says: [gc,stats] All times are wall-clock times, except per-root-class counters, that are sum over [gc,stats] all workers. Dividing the <total> over the root stage time estimates parallelism. But we can actually compute it ourselves: diff -r 6a562866cbd0 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 09:44:17 2020 -0400 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 16:36:10 2020 +0200 @@ -35,10 +35,11 @@ #define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" +#define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" #define SHENANDOAH_PHASE_DECLARE_NAME(type, title) \ title, const char* ShenandoahPhaseTimings::_phase_names[] = { @@ -227,10 +228,16 @@ out->cr(); for (uint i = 0; i < _num_phases; i++) { double v = _cycle_data[i] * 1000000.0; if (v > 0) { out->print(SHENANDOAH_PHASE_NAME_FORMAT " " SHENANDOAH_US_TIME_FORMAT " us", _phase_names[i], v); + + if (is_worker_phase(Phase(i))) { + double total = _cycle_data[i + 1] * 1000000.0; + out->print(", parallelism: " SHENANDOAH_PARALLELISM_FORMAT "x", total / v); + } + if (_worker_data[i] != NULL) { out->print(", workers (us): "); for (uint c = 0; c < _max_workers; c++) { double tv = _worker_data[i]->get(c); if (tv != ShenandoahWorkerData::uninitialized()) { Would print like this, on a special CLDG torture test that is used to optimize CLDG walks: Pause Init Mark (G) 26558 us Pause Init Mark (N) 26357 us Make Parsable 7 us Update Region States 31 us Scan Roots 26267 us, parallelism: 3.63x S: <total> 95442 us S: Thread Roots 159 us, workers (us): 41, 15, 15, 5, 17, ... S: Universe Roots 3 us, workers (us): 3, ---, ---, ---, ---, ... S: JNI Handles Roots 4 us, workers (us): 1, 0, 1, 1, 1, ... S: VM Global Roots 1 us, workers (us): 0, 0, 0, 0, 0, ... S: Synchronizer Roots 0 us, workers (us): 0, ---, ---, ---, ---, ... S: Management Roots 1 us, workers (us): 1, ---, ---, ---, ---, ... S: System Dict Roots 10 us, workers (us): ---, 10, ---, ---, ---, ... S: CLDG Roots 95263 us, workers (us): 11933, 11924, 11926, 11923, ... S: JVMTI Roots 0 us, workers (us): 0, ---, ---, ---, ---, ... Note it says ~3.6x parallelism, while there are 8 workers. This highlights the high setup costs for CLDG walk. Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey

2 2

RFR (XS) 8245773: Shenandoah: Windows assertion failure after JDK-8245464
by Aleksey Shipilev 26 May '20

26 May '20

Bug: https://bugs.openjdk.java.net/browse/JDK-8245773 JDK-8245464 made the accidental change that dropped the alignment to os::vm_allocation_granularity(), which fails on Windows. Argh. Simple fix: diff -r 5b77ebd1b4a6 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue May 26 09:43:55 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue May 26 12:16:05 2020 +0200 @@ -306,5 +306,5 @@ char* req_addr = (char*)addr; assert(is_aligned(req_addr, cset_align), "Should be aligned"); - ReservedSpace cset_rs(cset_size, os::vm_page_size(), false, req_addr); + ReservedSpace cset_rs(cset_size, cset_align, false, req_addr); if (cset_rs.is_reserved()) { assert(cset_rs.base() == req_addr, "Allocated where requested: " PTR_FORMAT ", " PTR_FORMAT, p2i(cset_rs.base()), addr); @@ -315,5 +315,5 @@ if (_collection_set == NULL) { - ReservedSpace cset_rs(cset_size, os::vm_page_size(), false); + ReservedSpace cset_rs(cset_size, cset_align, false); _collection_set = new ShenandoahCollectionSet(this, cset_rs, sh_rs.base()); } Testing: hotspot_gc_shenandoah {Linux, Windows} -- Thanks, -Aleksey

2 2