May 2020 - hotspot-gc-dev

RFR: 8246134: ZGC: Restructure hs_err sections
by Stefan Karlsson 01 Jun '20

01 Jun '20

Hi all, Please review this small patch to restructure and cleanup the information ZGC prints to hs_err files (and jcmd VM.info). https://cr.openjdk.java.net/~stefank/8246134/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8246134 The patch: - Moves the Page Table dumping later, to make it easier to find the other sections - Pretty print some info - Add barrier set print (mostly to get rid of awkward double new lines) - Update titles and cleanup newlines Thanks, StefanK

3 5

[15] RFR[T] 8246075: Missing logging in nmethod::oops_do_marking_epilogue() on early return path
by Zhengyu Gu 29 May '20

29 May '20

Please review this trivial patch that ensures ops_do_marking_prologue/epilogue messages are matched. Bug: https://bugs.openjdk.java.net/browse/JDK-8246075 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246075/webrev.00/ Test: tier1 on Linux x86_64 Submit test in progress Thanks, -Zhengyu

2 2

[15] RFR 8245880: Shenandoah: should not mark all code roots if class unloading is enabled
by Zhengyu Gu 29 May '20

29 May '20

Currently, concurrent code root scanning marks all code cache, no matter if class unloading is enabled, which is wrong. When class unloading is enabled, only on-stack code roots should be marked. Bug: https://bugs.openjdk.java.net/browse/JDK-8245880 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245880/webrev.00/ Test: hotspot_gc_shenandoah tier1 with Shenandoah Thanks, -Zhengyu

2 3

[15] RFR 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
by Zhengyu Gu 29 May '20

29 May '20

When class unloading is off, Shenandoah should mark through code roots. In normal cycle, this is done during concurrent marking phase. However, full GC does not execute concurrent marking phase, we should piggyback code root marking in final mark. Bug: https://bugs.openjdk.java.net/browse/JDK-8246162 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246162/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu

2 1

RFR: 8246044: ZGC: Rename ZDirector's max_capacity to soft_max_capacity
by Per Liden 29 May '20

29 May '20

After JDK-8222182, ZDirector started to use the "soft max capacity" to guide its heuristics. However, a number of local variables are still called max_capacity. I propose we rename them soft_max_capacity for clarity. Bug: https://bugs.openjdk.java.net/browse/JDK-8246044 Webrev: http://cr.openjdk.java.net/~pliden/8246044/webrev.0 /Per

3 4

RFR: 8242527: ZGC: TestUncommit.java fails due to "Exception: Uncommitted too fast"
by Per Liden 29 May '20

29 May '20

While awaiting the fix for JDK-8245208 "ZGC: Don't hold the ZPageAllocator lock while committing/uncommitting memory", I suggest we temporarily disable the "uncomitted too fast" check to avoid noise in our testing. JDK-8245208 will deliver the proper fix and re-enable the check. Bug: https://bugs.openjdk.java.net/browse/JDK-8242527 Webrev: http://cr.openjdk.java.net/~pliden/8242527/webrev.0 /Per

2 2

RFR (S) 8245942: Shenandoah: x86_32 builds fail after JDK-8245594
by Aleksey Shipilev 29 May '20

29 May '20

Bug: https://bugs.openjdk.java.net/browse/JDK-8245942 JDK-8245594 removed some volatile-qualified members, so now x86_32 build fails. I believe we just turn the affected classes trivially copyable as well, like it was done for ShenandoahVerifierTask in JDK-8245594. Fix: https://cr.openjdk.java.net/~shade/8245942/webrev.01/ Kim, does that match original intent with JDK-8245594? Testing: hotspot_gc_shenandoah {x86_64, x86_32} -- Thanks, -Aleksey

3 4

RFR: 8246045: ZGC: Fix ZDirector::rule_high_usage() calculation
by Per Liden 28 May '20

28 May '20

When ZDirector::rule_high_usage() calculates the amount of free space, it should take into account that "used" could be higher than "soft_max_capacity". Just like we do inZDirector::rule_allocation_rate(). Bug: https://bugs.openjdk.java.net/browse/JDK-8246045 Webrev: http://cr.openjdk.java.net/~pliden/8246045/webrev.0 /Per

3 4

RFR (S) 8245478: Implementation: JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production)
by Aleksey Shipilev 28 May '20

28 May '20

Hi, JEP: https://openjdk.java.net/jeps/379 Impl: https://bugs.openjdk.java.net/browse/JDK-8245478 CSR: https://bugs.openjdk.java.net/browse/JDK-8245479 Webrev: https://cr.openjdk.java.net/~shade/8245478/webrev.01/ Along with flag changes, I also enabled back the tests that assume Shenandoah is "product", like we have in sh/jdk11 and sh/jdk8 trees. Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey

4 5

Discussion on JDK-8245511: G1 adaptive IHOP does not account for reclamation of humongous objects by young GC
by Luo, Ziyi 28 May '20

28 May '20

Hi Thomas, Thank you for looking into JDK-8245511. I open this thread to discuss the questions you raised in comments (I’m not an author yet :)). > If you compare latest jdk15 behavior which does not show this problem here at all like with earlier jdks (you tagged 15 as affected, but I can't reproduce with latest. Might be a local fluke though). You are right about the test result. The probem is not reproducible in jdk-15-ea+24. I look deep into the gc log, I found some anomalies with the humongous regions e.g., % cat gc-vanilla-15-30353-2020-05-26_17-03-39.log | grep "Humongous regions" [3.256s][info ][gc,heap ] GC(0) Humongous regions: 228->0 [10.209s][info ][gc,heap ] GC(2) Humongous regions: 78->0 ... [20.034s][info ][gc,heap ] GC(5) Humongous regions: 0->0 [20.914s][info ][gc,heap ] GC(7) Humongous regions: 0->0 <No humongous allocations at all according to the gc heap stats> ... I suspect this is because the humongous object size is set the same as the region size in the repro program and somehow jdk15 treats such objects as not humongous (Correct if I were wrong). I adjusted the humongous object size 1.5 times of the region size. Now the problem is reproducible in jdk15. I'll update the repro program in JBS. Thanks, Ziyi

2 3