OopHandle release can not be called in a safepoint

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