JDK-8251336 : OopHandle release can not be called in a safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-08-10
  • Updated: 2024-11-20
  • Resolved: 2020-08-12
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 16
16 b11Fixed
Related Reports
Duplicate :  
JDK-8251337 - Shenandoah: TestEvilSyncBug: assert(_satb_mark_queue_set.is_active()) failed
Relates :  
JDK-8244997 - Convert the JavaThread::_threadObj oop to use OopStorage
Relates :  
JDK-8251455 - OopStorage usage rules should be documented and checked
Description
Happens semi-reliably during hotspot_gc_shenandoah testing:

$ CONF=linux-x86_64-server-slowdebug make images run-test TEST=hotspot_gc_shenandoah

#  Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:80), pid=439282, tid=439461
#  assert(_satb_mark_queue_set.is_active()) failed: only get here when SATB active

Stack: [0x00007f05f8667000,0x00007f05f8768000],  sp=0x00007f05f8766970,  free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x4ee90f]  ShenandoahBarrierSet::enqueue(oopDesc*)+0x37
V  [libjvm.so+0x6c5b14]  void ShenandoahBarrierSet::satb_barrier<548980ul, oopDesc*>(oopDesc**)+0x9a
V  [libjvm.so+0x6c530a]  void ShenandoahBarrierSet::AccessBarrier<548980ul, ShenandoahBarrierSet>::oop_store_not_in_heap<oopDesc*>(oopDesc**, oopDesc*)+0x94
V  [libjvm.so+0x6c4dfb]  AccessInternal::PostRuntimeDispatch<ShenandoahBarrierSet::AccessBarrier<548980ul, ShenandoahBarrierSet>, (AccessInternal::BarrierType)0, 548980ul>::oop_access_barrier(void*, oopDesc*)+0x27
V  [libjvm.so+0x6c4325]  AccessInternal::RuntimeDispatch<548948ul, oopDesc*, (AccessInternal::BarrierType)0>::store(void*, oopDesc*)+0x2b
V  [libjvm.so+0x6c40e8]  EnableIf<!HasDecorator<548948ul, 2048ul>::value, void>::type AccessInternal::PreRuntimeDispatch::store<548948ul, oopDesc*>(void*, oopDesc*)+0x4d
V  [libjvm.so+0x6c3cb0]  void AccessInternal::store_reduce_types<548948ul, oopDesc*>(oopDesc**, oopDesc*)+0x27
V  [libjvm.so+0x6c37cd]  void AccessInternal::store<524292ul, oopDesc*, oopDesc*>(oopDesc**, oopDesc*)+0x3c
V  [libjvm.so+0x6c2e8d]  void Access<524288ul>::oop_store<oopDesc*, oopDesc*>(oopDesc**, oopDesc*)+0x34
V  [libjvm.so+0x81e2d6]  OopHandle::release(OopStorage*)+0x3e
V  [libjvm.so+0x10099bb]  OopHandleList::~OopHandleList()+0x37
V  [libjvm.so+0x1008d87]  release_oop_handles()+0x5a
V  [libjvm.so+0x1009211]  ServiceThread::service_thread_entry(JavaThread*, Thread*)+0x21b
V  [libjvm.so+0x11c3dd4]  JavaThread::thread_main_inner()+0x150
V  [libjvm.so+0x11c3c7c]  JavaThread::run()+0x128
V  [libjvm.so+0x11bfc1e]  Thread::call_run()+0x184
V  [libjvm.so+0xf1c693]  thread_native_entry(Thread*)+0x239

...and it seems to happen in the middle of Init-Mark pause. Is this a race when concurrent-mark is already set, so we enter toward the enqueue, but SATB queue had not been activated yet? Last events are:

Event: 4.436 Executing VM operation: Shenandoah Init Marking
Event: 4.436 Pause Init Mark (process weakrefs) (unload classes)
Event: 4.437 Protecting memory [0x00007f05fe3e3000,0x00007f05fe3e4000] with protection modes 7

And we are marking:

Status: marking, not cancelled
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/997ead23fa06 User: coleenp Date: 2020-08-12 11:55:59 +0000
12-08-2020
ILW = HLM = P3
11-08-2020
I changed the synopsis. I think it's that OopHandle release stores a NULL into OopStorage during a safepoint and the barrier for the store is what cannot be done inside of a safepoint.
11-08-2020
My change for JDK-8244997 released OopStorage oops inside a safepoint. It appears that Shenandoah cares and probably the other GCs, so I will fix it and add an assert.
11-08-2020
Hmm, ServiceThread is a JavaThread and should be safepointed and therefore not race with anything during init-mark. It seems possible that this is a race during Thread start or shutdown where the SATB flag and conc-mark flag go out of sync if not properly handled. EvilSyncBug was made specifically for this situation.
10-08-2020