October 2020 - hotspot-gc-dev

RFR: 8255235: ZGC: Allocate and initialize forwarding data structures in parallel
by Per Liden 02 Nov '20

02 Nov '20

As a continuation of JDK-8255234, we can speed things up even more by allocating/initializing forwarding data structures in parallel. For example, testing using BigRamTester shows the time for "Concurrent Select Relocation Set" phase drop by ~50% when using 4 threads. This PR depends on "8255234: ZGC: Bulk allocate forwarding data structures", which is a separate PR (https://github.com/openjdk/jdk/pull/804) ------------- Commit messages: - 8255235: ZGC: Allocate and initialize forwarding data structures in parallel - 8255234: ZGC: Bulk allocate forwarding data structures Changes: https://git.openjdk.java.net/jdk/pull/805/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=805&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255235 Stats: 502 lines in 21 files changed: 333 ins; 105 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/805.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/805/head:pull/805 PR: https://git.openjdk.java.net/jdk/pull/805

3 8

RFR: 8255691: Shenandoah: Invoke native-LRB only on non-strong refs
by Roman Kennke 30 Oct '20

30 Oct '20

The way that current native LRB is implemented is wrong (but non-fatal) and misleading. It's purpose is to prevent resurrection of unreachable non-strong references, and it should only be invoked on non-strong references, not all native references. This distinction will become even more important once we get concurrent reference processing: then we also want to invoke this barrier on referent-loads. This changes the runtime-part of native-LRB so that it is only invoked when it's invoked with non-strong reference decorator. Otherwise it acts as regular LRB. Testing: hotspot_gc_shenandoah ------------- Commit messages: - 8255691: Shenandoah: Invoke native-LRB only on non-strong refs Changes: https://git.openjdk.java.net/jdk/pull/961/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=961&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255691 Stats: 15 lines in 3 files changed: 4 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/961.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/961/head:pull/961 PR: https://git.openjdk.java.net/jdk/pull/961

2 2

Re: RFR: 8254758: Change G1ServiceThread to be task based [v3]
by Albert Mingkun Yang 30 Oct '20

30 Oct '20

On Tue, 20 Oct 2020 12:01:46 GMT, Stefan Johansson <sjohanss(a)openjdk.org> wrote: >> src/hotspot/share/gc/g1/g1ServiceThread.cpp line 318: >> >>> 316: _vtime_accum = (os::elapsedVTime() - vtime_start); >>> 317: } else { >>> 318: _vtime_accum = 0.0; >> >> Why resetting it to zero? I thought empty else branch is enough here. > > I think you are correct but this is pre-existing code that I don't intend to change right now. There is a separate > [issue](https://bugs.openjdk.java.net/browse/JDK-8252645) on moving this to the G1RemSetSamplingTask. Back in the day > when the thread only did remembered set sampling it made sense to measure it here, it doesn't anymore, but I wanted to > leave that out of this change. Got it, sure. >> src/hotspot/share/gc/g1/g1ServiceThread.cpp line 312: >> >>> 310: register_task(&remset_task); >>> 311: >>> 312: while (!should_terminate()) { >> >> `should_terminate()` is called in three places/functions; I wonder it's possible to gather them together. Conceptually, >> we should check termination condition before yielding to the task or to sleep. Manually inlining `run_tasks` to this >> loop actually helps readability, since it's quite short itself. > > I agree that it's a bit unfortunate and I can see if I can find some way to restructure the code to improve this. > Thinking about it, the recent changes might make it possible to nicely just let each round in the outer loop handle one > task and then check if we should sleep, maybe this is what you meant. This looks good; thank you. ------------- PR: https://git.openjdk.java.net/jdk/pull/734

2 1

RFR: 8255595: delay_to_keep_mmu passes wrong arguments to Monitor wait
by Kim Barrett 30 Oct '20

30 Oct '20

Please review this trivial fix of the second argument in a call to MonitorLocker::wait. Because the locker is constructed as no-safepoint-checking, the improper second argument is ignored rather than possibly going into an unexpected state. ------------- Commit messages: - fix call to wait Changes: https://git.openjdk.java.net/jdk/pull/934/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=934&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255595 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/934.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/934/head:pull/934 PR: https://git.openjdk.java.net/jdk/pull/934

4 8

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v5]
by Richard Reingruber 30 Oct '20

30 Oct '20

> The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > For ZGC (so far) this is not 100% reliable. > > Just ignoring the runs where the expected OOME was not raised was not accepted. > > Summary of the now accepted solution: > > - The 3 problematic test cases are skipped if ZGC is selected. > > - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. > > - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. > > - EATests.java is removed from the problem list for ZGC. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Replaced vm.jvmci with vm.graal.enabled in @requires clause. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/4676f1da..4e878e8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775

2 2

RFR: 8254972: Fix pretouch chunk calculations
by Thomas Schatzl 30 Oct '20

30 Oct '20

Hi all, can I have reviews for this follow-up to JDK-8252221 where Kim noticed that the code in the pretouch task has some minor issues? In particular, some code could be simplified and due to some inconsistencies, and used less than ideal number of workers. There is also a fix to avoid an overflow if you want to pretouch >= 16TB of heap with 4k pages (order of casts in calculation of ``num_workers``). Testing: tier1 Thanks, Thomas ------------- Commit messages: - Initial import Changes: https://git.openjdk.java.net/jdk/pull/884/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=884&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254972 Stats: 29 lines in 2 files changed: 13 ins; 7 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/884.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/884/head:pull/884 PR: https://git.openjdk.java.net/jdk/pull/884

3 5

Re: RFR: 8255072: [TESTBUG] com/sun/jdi/EATests.java should not fail if expected VMOutOfMemoryException is not thrown [v4]
by Richard Reingruber 29 Oct '20

29 Oct '20

> The following test cases try to provoke VMOutOfMemoryException during object reallocation because of JVMTI PopFrame / ForceEarlyReturn: > > EAPopFrameNotInlinedReallocFailure > EAPopInlinedMethodWithScalarReplacedObjectsReallocFailure > EAForceEarlyReturnOfInlinedMethodWithScalarReplacedObjectsReallocFailure > > For ZGC (so far) this is not 100% reliable. > > Just ignoring the runs where the expected OOME was not raised was not accepted. > > Summary of the now accepted solution: > > - The 3 problematic test cases are skipped if ZGC is selected. > > - They are also skipped if no OOME during object reallocation can be expected because allocations are not eliminated. > > - In consumeAllMemory, as a last step, empty LinkedList nodes are created without long array to fill up small blocks of free memory. > > - EATests.java is removed from the problem list for ZGC. Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision: Whitespace/indentation clean-up. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/775/files - new: https://git.openjdk.java.net/jdk/pull/775/files/33ceb741..4676f1da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=775&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/775/head:pull/775 PR: https://git.openjdk.java.net/jdk/pull/775

2 2

RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
by Roman Kennke 29 Oct '20

29 Oct '20

JDK-8254314 introduced the following code: if (in1->bottom_type() == TypePtr::NULL_PTR && (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) { in2 = step_over_gc_barrier(in2); } However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB. The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. I am also putting in some refactoring to avoid duped code for good measure. Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests) ------------- Commit messages: - 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB Changes: https://git.openjdk.java.net/jdk/pull/902/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=902&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255534 Stats: 17 lines in 2 files changed: 9 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/902.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/902/head:pull/902 PR: https://git.openjdk.java.net/jdk/pull/902

2 6

RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask
by Aleksey Shipilev 28 Oct '20

28 Oct '20

The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives. ------------- Commit messages: - 8255457: Shenandoah: cleanup ShenandoahMarkTask Changes: https://git.openjdk.java.net/jdk/pull/883/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=883&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255457 Stats: 94 lines in 3 files changed: 42 ins; 24 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/883.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/883/head:pull/883 PR: https://git.openjdk.java.net/jdk/pull/883

2 5

RFR: 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing
by Erik Österlund 28 Oct '20

28 Oct '20

Today, when you crash, the GCLogPrecious::_lock is taken. This effectively limits you to only get clean crash reports if you crash or assert without holding a lock of rank tty or lower. It is arguably difficult to know what locks you are going to have when crashing. Therefore, I don't think the precious GC log should constrain possible crashing contexts in that fashion. This patch inserts the precious GC lines into a linked list instead, that can be traversed concurrently, without holding any locks. This allows you to crash in contexts where "low" ranked locks are held. I have manually verified that the hs_err precious GC log looks identical before and after my change. ------------- Commit messages: - 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing Changes: https://git.openjdk.java.net/jdk/pull/900/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=900&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254877 Stats: 50 lines in 2 files changed: 41 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/900.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/900/head:pull/900 PR: https://git.openjdk.java.net/jdk/pull/900

2 3