JDK-8231197 : Shenandoah: JVMTI heap walking cleanup crashes with NULL forwardee
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 8-shenandoah,11-shenandoah,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-09-18
  • Updated: 2020-06-01
  • Resolved: 2019-09-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13 JDK 14
13.0.2Fixed 14 b16Fixed
Related Reports
Relates :  
JDK-8231198 - Shenandoah: heap walking should visit all roots most of the time
Relates :  
JDK-8224584 - Shenandoah: Eliminate forwarding pointer word
Description
$ CONF=linux-x86_64-server-fastdebug make images run-test TEST=vmTestbase/nsk/jvmti/unit/FollowReferences/ TEST_VM_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"

Fails:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/shenandoah-jdk11/src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp:47), pid=5542, tid=5555
#  Error: Shenandoah assert_correct failed; Forwardee must point to a heap address

Referenced from:
  no interior location recorded (probably a plain heap scan, or detached oop)

Object:
  0x000000070f12b720 - klass 0x0000000800068aa8 nsk.jvmti.unit.FollowReferences.followref001RootTestedClass
        allocated after mark start
        marked 
    not in collection set
  mark: marked(0x0000000000000003)
  region: |    4|R  |BTE    70f100000,    70f200000,    70f200000|TAMS    70f100000|U  1024K|T  1024K|G     0B|S     0B|L     0B|CP   0|SN            5,        5,        0,        0

Forwardee:
  0x0000000000000000 - safe print, no details


#
# JRE version: OpenJDK Runtime Environment (11.0.5) (fastdebug build 11.0.5-internal+0-adhoc.shade.shenandoah-jdk11)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 11.0.5-internal+0-adhoc.shade.shenandoah-jdk11, mixed mode, tiered, compressed oops, shenandoah gc, linux-amd64)

---------------  T H R E A D  ---------------

Current thread (0x00007f23cc3cb800):  VMThread "VM Thread" [stack: 0x00007f23b275f000,0x00007f23b285f000] [id=5555]

Stack: [0x00007f23b275f000,0x00007f23b285f000],  sp=0x00007f23b285ade0,  free space=1007k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x194ee24]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x314
V  [libjvm.so+0x194fcbf]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f
V  [libjvm.so+0xadb6f0]  report_vm_error(char const*, int, char const*, char const*, ...)+0x100
V  [libjvm.so+0x164d38e]  ShenandoahAsserts::print_failure(ShenandoahAsserts::SafeLevel, oop, void*, oop, char const*, char const*, char const*, int)+0x45e
V  [libjvm.so+0x164dc9a]  ShenandoahAsserts::assert_correct(void*, oop, char const*, int)+0x1da
V  [libjvm.so+0x1402625]  ShenandoahBarrierSet::resolve_forwarded_not_null(oop)+0x45
V  [libjvm.so+0x16ce0c0]  void ObjectIterateScanRootClosure::do_oop_work<oop>(oop*)+0x70
V  [libjvm.so+0xfcd439]  JNIHandles::oops_do(OopClosure*)+0xb9
V  [libjvm.so+0x16fee0c]  ShenandoahHeapIterationRootScanner::roots_do(OopClosure*)+0x47c
V  [libjvm.so+0x16c63df]  ShenandoahHeap::object_iterate(ObjectClosure*)+0x19f
V  [libjvm.so+0x1175787]  ObjectMarker::done()+0x317
V  [libjvm.so+0x1178f88]  VM_HeapWalkOperation::doit()+0x318
V  [libjvm.so+0x1993af1]  VM_Operation::evaluate()+0x141
V  [libjvm.so+0x198ee2e]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.60]+0x18e
V  [libjvm.so+0x198f71a]  VMThread::loop()+0x50a
V  [libjvm.so+0x198fd4b]  VMThread::run()+0xcb
V  [libjvm.so+0x187ddcd]  Thread::call_run()+0x6d
V  [libjvm.so+0x147b856]  thread_native_entry(Thread*)+0x106
Comments
Fix Request (13u) This fixes a few failures in vmTestbase_nsk_jvmti with Shenandoah. Patch applies cleanly, passes broken heap iteration tests in vmTestbase_nsk_jvmti, hotspot_gc_shenandoah, tier1. Risk is low, as it only affects Shenandoah paths.
02-10-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/13e041be4e5c User: shade Date: 2019-09-19 18:27:59 +0000
19-09-2019
HeapWalkOperation does its own walk to follow references, storing the wavefront in mark words. Then, when it is done, it wants to restore the marks. To do that, it asks the heap to walk all objects and apply RestoreMarksClosure to reset the marks. At that time, Shenandoah walks the heap, resolving the forwarded objects using forwardees from mark word. This fails, because it encounters the object "marked" by JVMTI code that has NULL forwardee. Can be fixed with e.g.: http://cr.openjdk.java.net/~shade/8231197/webrev.01/
18-09-2019