Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8251336

OopHandle release can not be called in a safepoint

    Details

    • Subcomponent:
    • Resolved In Build:
      b11

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                coleenp Coleen Phillimore
                Reporter:
                shade Aleksey Shipilev
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: