January 2020 - hotspot-gc-dev

8237182(T): Update copyright header for shenandoah and epsilon files
by Mikael Vidstedt 14 Jan '20

14 Jan '20

Please review this small change which adjusts the copyright headers for shenandoah and epsilon related files. JBS: https://bugs.openjdk.java.net/browse/JDK-8237182 <https://bugs.openjdk.java.net/browse/JDK-8237182> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8237182/webrev.00/open/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8237182/webrev.00/open/webrev/> Description: Many/most of the shenandoah and epsilon related files are missing the following line in the copyright header: "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.” This change simply adds that line to the relevant files. In src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp there was also a missing empty line before one of the paragraphs in the header. Cheers, Mikael

3 3

Is CPU_MULTI_COPY_ATOMIC the correct test here?
by Andrew Haley 14 Jan '20

14 Jan '20

AArch64 is multi-copy atomic, but it has a relaxed memory model. I'm looking at the CPU_MULTI_COPY_ATOMIC in this code: template<class E, MEMFLAGS F, unsigned int N> bool GenericTaskQueue<E, F, N>::pop_global(volatile E& t) { Age oldAge = _age.get(); // Architectures with weak memory model require a barrier here // to guarantee that bottom is not older than age, // which is crucial for the correctness of the algorithm. #ifndef CPU_MULTI_COPY_ATOMIC OrderAccess::fence(); #endif uint localBot = Atomic::load_acquire(&_bottom); uint n_elems = size(localBot, oldAge.top()); if (n_elems == 0) { return false; } It seems to me that what we're asking here is not whether the CPU is multi-copy atomic, but whether it's TSO or not. I'd like to turn CPU_MULTI_COPY_ATOMIC off for AArch64, but I think that GenericTaskQueue::pop_global() will break if I do. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 3

RFR: 8236153: ZGC: gc/z/TestUncommit.java fails with java.lang.Exception: Uncommitted too fast
by Per Liden 14 Jan '20

14 Jan '20

The test gc/z/TestUncommit.java fails now and then on Windows when using -Xcomp. This test can fail if it's severely starved on CPU, as it will cause the timing to be off. The logs confirms that the test took an unusually long time to execute, suggesting it was starved on CPU. This only happens in test tiers using -Xcomp, which is likely causing the unusually high load. This patch disables this test when using -Xcomp. I've enabled some GC logging, which should helpful if this test ever fails again. Bug: https://bugs.openjdk.java.net/browse/JDK-8236153 Webrev: http://cr.openjdk.java.net/~pliden/8236153/webrev.0 /Per

2 2

[14] RFR 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test
by Zhengyu Gu 13 Jan '20

13 Jan '20

Please review this small patch to reduce thread pool size in TestEvilSyncBug.java test. I have observed problems with the test on many core system, including crashes on arm server with 48 cores when running 4 concurrent test jobs. Bug: https://bugs.openjdk.java.net/browse/JDK-8237038 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237038/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) with 4 concurrent test jobs on 48 cores arm machine. Thanks, -Zhengyu

2 2

[15] RFR(T) 8237017: Shenandoah: Remove racy assertion
by Zhengyu Gu 13 Jan '20

13 Jan '20

During concurrent weak root processing, it tries to CAS in NULL if the oop is dead, then asserts that the slot is indeed NULL. The assertion is racy, because there can be another thread to release the slot and then reuse it (that's why it uses CAS in the first place), that can result assertion to fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8237017 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237017/webrev.00/index.html Test: hotspot_gc_shenandoah fastdebug on x86_64 Linux Thanks, -Zhengyu

2 1

aarch64: Concurrent class unloading, nmethod barriers, ZGC
by Stuart Monteith 13 Jan '20

13 Jan '20

Hello Zhengyu, et al, This is the current state of the nmethod barrier code I have for ZGC on aarch64. As I understand it, Zhengyu may have been working on this, and so this is my sharing it: http://cr.openjdk.java.net/~smonteith/nmethod/webrev.0/ The code has various bits for debugging, prototype level code, with comments and some notes interspersed throughout - it is not ready for merging. The approach I've taken for the nmethod barrier is to have the nmethod barrier that is emitted be implemented like so: __ adr(rscratch1, __ pc()); __ ldarw(rscratch2, rscratch1); __ ldrw(rscratch1, thread_disarmed_addr); __ cmpw(rscratch2, rscratch1); __ br(Assembler::EQ, continuation); __ mov(rscratch1, StubRoutines::aarch64::method_entry_barrier()); __ blr(rscratch1); __ bind(continuation); This code is patched up such that the ldarw is loading from a field I've added to nmethod "_nmethod_guard". There don't appear to be existing ways to emit a relocation (there aren't spare bits to do a small change) from an address in nmethod emitted code into the nmethod data structure. It is initialized to the instruction's current address and BarrierSetNMethod::disarm will detect this known value and fix it up, which occurs on initialization. Currently the deoptmise path is broken. By setting the environment variable "SRDM_forcedeopt", the deoptimisation can be provoked even when not needed - the x86 implementation is good with this change. The aarch64 code isn't working yet - I suspect I've followed the x86 code too closely, and my offsets are perhaps miscalculated - I may be pointing at the wrong frame, or I've neglected FP too much. BR, Stuart

4 11

[14] RFR 8236902: Shenandoah: Missing string dedup roots in all root scanner
by Zhengyu Gu 10 Jan '20

10 Jan '20

String dedup roots are missing in all roots scanner. The problem was discovered while running TestHeapDump.java test with StringDeduplication enabled, let's add a test there to make sure. Bug: https://bugs.openjdk.java.net/browse/JDK-8236902 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8236902/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu

2 1

RFR: 8236851: Shenandoah: More details in Traversal GC event messages
by Roman Kennke 09 Jan '20

09 Jan '20

We currently only print e.g. "Pause Init Traversal" in event messages for Traversal GC. We should also include information whether or not the cycle also does unload classes and/or process references, like we do for the normal mode. Bug: https://bugs.openjdk.java.net/browse/JDK-8236851 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8236851/webrev.00/ Testing: hotspot_gc_shenandoah, manual inspection of hs_err files Can I please get a review? Thanks, Roman

2 1

RFR (S): 8214277: Use merged G1ArchiveRegionMap for open and closed archive heap regions
by Thomas Schatzl 09 Jan '20

09 Jan '20

Hi all, could I have reviews for this small cleanup/simplification that merges the open and closed archive region map into a single one? CR: https://bugs.openjdk.java.net/browse/JDK-8214277 Webrev: http://cr.openjdk.java.net/~tschatzl/8214277/webrev/ Testing: hs-tier1-5 (almost done, no issues), local gc/g1 jtreg Thanks, Thomas

3 7

[15] RFR 8228818: Shenandoah: Processing weak roots in concurrent phase when possible
by Zhengyu Gu 09 Jan '20

09 Jan '20

Please review this enhancement that moves some of weak root processing into concurrent phase whenever possible. When concurrent class unloading is enabled, the weak roots that backed by OopStorage can be processed in concurrent phase, as Shenandoah native LRB can properly resolve the object and hide dead oops from mutators. Bug: https://bugs.openjdk.java.net/browse/JDK-8228818 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228818/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) on x86_64 and x86_32 Linux specjvm on x86_64 Linux Thanks, -Zhengyu

2 4