JDK-8031703 : Missing post-barrier in ReferenceProcessor
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-01-14
  • Updated: 2014-07-29
  • Resolved: 2014-02-06
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 8 JDK 9
8u20Fixed 9 b04Fixed
Related Reports
Duplicate :  
JDK-8031717 - Kitchensink crashes in ObjectSynchronizer when inflating lock
Description
The VM has crashed several times in the ReferenceHandler, the symptom is always that we want to enqueue a reference on its ReferenceQueue, but the reference oop is bad (seems to not have been updated).

The bug has happened with Kitchensink and G1, and has been seen on both 32-bit and 64-bit machines in nightly testing.

Example of stack traces:

tack: [0xb55c0000,0xb5611000],  sp=0xb560ecac,  free space=315k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x9895d5]  VMError::report_and_die()+0x185;;  VMError::report_and_die()+0x185
V  [libjvm.so+0x371568]  report_vm_error(char const*, int, char const*, char const*)+0x68;;  report_vm_error(char const*, int, char const*, char const*)+0x68
V  [libjvm.so+0x3ccc42]  frame::retrieve_receiver(RegisterMap*)+0x1f2;;  frame::retrieve_receiver(RegisterMap*)+0x1f2
V  [libjvm.so+0x887176]  SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&, Bytecodes::Code&, CallInfo&, Thread*)+0x526;;  SharedRuntime::find_callee_info_helper(JavaThread*, vframeStream&, Bytecodes::Code&, CallInfo&, Thread*)+0x526
V  [libjvm.so+0x88c70e]  SharedRuntime::handle_ic_miss_helper(JavaThread*, Thread*)+0x22e;;  SharedRuntime::handle_ic_miss_helper(JavaThread*, Thread*)+0x22e
V  [libjvm.so+0x88d13f]  SharedRuntime::handle_wrong_method_ic_miss(JavaThread*)+0x1cf;;  SharedRuntime::handle_wrong_method_ic_miss(JavaThread*)+0x1cf
v  ~RuntimeStub::ic_miss_stub
J 1006% C1 java.lang.ref.Reference$ReferenceHandler.run()V (102 bytes) @ 0xf48a120c [0xf48a1000+0x20c]
v  ~StubRoutines::call_stub
V  [libjvm.so+0x50113d]  JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x17bd;;  .L625+0x25c
V  [libjvm.so+0x7d2b79]  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x19;;  os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0x19
V  [libjvm.so+0x503690]  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x650;;  JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x650
V  [libjvm.so+0x504075]  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x95;;  JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x95
V  [libjvm.so+0x5de3b1]  thread_entry(JavaThread*, Thread*)+0xc1;;  thread_entry(JavaThread*, Thread*)+0xc1
V  [libjvm.so+0x92d0e4]  JavaThread::thread_main_inner()+0x234;;  JavaThread::thread_main_inner()+0x234
V  [libjvm.so+0x92d484]  JavaThread::run()+0x2e4;;  JavaThread::run()+0x2e4
V  [libjvm.so+0x7db819]  java_start(Thread*)+0x119;;  java_start(Thread*)+0x119
C  [libpthread.so.0+0x6a49]  abort@@GLIBC_2.0+0x6a49

0  0xf77f9430 in __kernel_vsyscall ()
#1  0x4a71db01 in raise () from sysroot/lib/libc.so.6
#2  0x4a71f3da in abort () from sysroot/lib/libc.so.6
#3  0xf6f9e104 in os::abort(bool) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#4  0xf714ec51 in VMError::report_and_die() ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#5  0xf714f22e in crash_handler(int, siginfo*, void*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#6  <signal handler called>
#7  0xf6f910cb in os::is_first_C_frame(frame*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#8  0xf714cfb7 in VMError::report(outputStream*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#9  0xf714e5d5 in VMError::report_and_die() ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#10 0xf6fa8ff9 in JVM_handle_linux_signal ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#11 0xf6f9a1ef in signalHandler(int, siginfo*, void*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#12 <signal handler called>
#13 J 505 C1 java.lang.ref.ReferenceQueue.enqueue(Ljava/lang/ref/Reference;)Z (119 bytes) @ 0xf7a3b1c7 [0xf7a3b1c0+0x7]
#14 0xf6cc613d in JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#15 0xf6f97b79 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle*, JavaCallArguments*, Thread*), JavaValue*, methodHandle*, JavaCallArguments*, Thread*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#16 0xf6cc8690 in JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#17 0xf6cc9075 in JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#18 0xf6da33b1 in thread_entry(JavaThread*, Thread*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#19 0xf70f20e4 in JavaThread::thread_main_inner() ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#20 0xf70f2484 in JavaThread::run() ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#21 0xf6fa0819 in java_start(Thread*) ()
   from sysroot/scratch/local/aurora/sandbox/sca/vmsqe/jdk/nightly/fastdebug/gc_baseline/linux-i586/jre/lib/i386/client/libjvm.so
#22 0x4a8c0a49 in start_thread () from sysroot/lib/libpthread.so.0
#23 0x4a7d1e1e in clone () from sysroot/lib/libc.so.6
Comments
This can be easily reproduced by running Kitchensink on 32-bit x86 with -XX:+UseG1GC and -XX:+Verify{Before|During|After}GC enabled. Root cause: In ReferenceProcessor::process_discovered_references() the lists of discovered references are pruned (a reference who's referent is still alive is unlinked, etc). During this pruning the Reference.discovered field is rewritten without a post-barrier (in DiscoveredListIterator::remove()), which means we loose track of this reference and it will not be properly updated if the object it refers to is later moved. This should only affect G1's CM reference processor, which is the only case where the reference processor needs post-barriers for the discovered list (i.e. _discovered_list_needs_barrier is true). The window for this to happen was widened after fixing JDK-8029255. Before that fix the appropriate card was usually dirtied by pure luck because of a write (in a different context) to the next field in the same object. However, if the object was unlucky and the next/discovered fields spanned two different cards the problem would have appeared. Solution: The unlinking of references from the discovered list should be followed by a post-barrier if the collector needs that (i.e. when _discovered_list_needs_barrier is true).
27-01-2014
This seems to be a GC issue, sorry for transferring to compiler. I hope you guys did not spend too much time on it :(
24-01-2014