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

Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap

    XMLWordPrintable

Details

    • gc
    • 21
    • b03

    Backports

      Description

        We see this lock order problem:

        assert(false) failed: Attempting to acquire lock ObjectSynchronizer Weak alloc lock/oopstorage out of order with lock Service_lock/service -- possible deadlock

        V [libjvm.so+0x13fcc3c] Mutex::check_rank(Thread*)+0x36c (mutex.cpp:447)
        V [libjvm.so+0x13fdee0] Mutex::lock_without_safepoint_check()+0x50 (mutex.cpp:145)
        V [libjvm.so+0x14819b9] OopStorage::allocate()+0x29 (mutexLocker.hpp:199)
        V [libjvm.so+0x18a8bd0] WeakHandle::WeakHandle(OopStorage*, oop)+0x20 (weakHandle.cpp:37)
        V [libjvm.so+0x144e4f2] ObjectMonitor::ObjectMonitor(oop)+0x62 (objectMonitor.cpp:261)
        V [libjvm.so+0x17337f5] ObjectSynchronizer::inflate(Thread*, oop, ObjectSynchronizer::InflateCause)+0x675 (synchronizer.cpp:1425)
        V [libjvm.so+0x1736036] ObjectSynchronizer::FastHashCode(Thread*, oop)+0x146 (synchronizer.cpp:1001)
        V [libjvm.so+0x146491f] oopDesc::slow_identity_hash()+0x6f (oop.cpp:112)
        V [libjvm.so+0x11bf2c5] JvmtiTagMapTable::remove(oop)+0x265 (oop.inline.hpp:366)
        V [libjvm.so+0x11b6e0f] CallbackWrapper::~CallbackWrapper()+0xef (jvmtiTagMap.cpp:248)
        V [libjvm.so+0x11b290c] IterateThroughHeapObjectClosure::do_object(oop)+0x59c (jvmtiTagMap.cpp:1089)
        V [libjvm.so+0x1999518] ZHeapIteratorContext::mark_and_push(oop) const [clone .part.0]+0x58 (zHeapIterator.cpp:81)
        V [libjvm.so+0x199c6d4] ZHeapIteratorUncoloredRootOopClosure::do_oop(oop*)+0x154 (zHeapIterator.cpp:161)
        V [libjvm.so+0x19bda57] ZNMethod::nmethod_oops_do_inner(nmethod*, OopClosure*)+0x47 (zNMethod.cpp:264)
        V [libjvm.so+0x19bdc1e] ZNMethod::nmethod_oops_do(nmethod*, OopClosure*)+0x8e (zNMethod.cpp:254)
        V [libjvm.so+0x1196195] JvmtiDeferredEventQueue::oops_do(OopClosure*, CodeBlobClosure*)+0x45 (jvmtiImpl.cpp:1027)
        V [libjvm.so+0x15e5dd9] ServiceThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x59 (serviceThread.cpp:220)
        V [libjvm.so+0x1796ac6] Thread::oops_do(OopClosure*, CodeBlobClosure*)+0x76 (thread.cpp:431)
        V [libjvm.so+0x19fad72] ZJavaThreadsIterator::apply(ThreadClosure*)+0x102 (zRootsIterator.cpp:136)
        V [libjvm.so+0x19fb135] ZRootsIteratorStrongUncolored::apply(ThreadClosure*, NMethodClosure*)+0x35 (zRootsIterator.cpp:96)
        V [libjvm.so+0x1997bed] ZHeapIterator::push_strong_roots(ZHeapIteratorContext const&)+0x10d (zHeapIterator.cpp:376)
        V [libjvm.so+0x199a37c] ZHeapIterator::object_iterate(ObjectClosure*, unsigned int)+0x7c (zHeapIterator.cpp:388)
        V [libjvm.so+0x199476e] ZHeap::object_iterate(ObjectClosure*, bool)+0x5e (zHeap.cpp:297)
        V [libjvm.so+0x11b787c] VM_HeapIterateOperation::doit()+0x5c (jvmtiTagMap.cpp:877)
        V [libjvm.so+0x18758e9] VM_Operation::evaluate()+0x139 (vmOperations.cpp:71)
        V [libjvm.so+0x189868b] VMThread::evaluate_operation(VM_Operation*)+0x10b (vmThread.cpp:281)
        V [libjvm.so+0x18991ff] VMThread::inner_execute(VM_Operation*)+0x3bf (vmThread.cpp:435)
        V [libjvm.so+0x18993e4] VMThread::loop()+0x84 (vmThread.cpp:502)
        V [libjvm.so+0x18994e7] VMThread::run()+0x87 (vmThread.cpp:175)
        V [libjvm.so+0x179739a] Thread::call_run()+0xba (thread.cpp:217)

        We think that this lock ordering problem is limited to an assert and will not cause deadlocks.

        There are multiple alternatives to fix this:
        1) Don't inflate monitors during safepoints
        2) Don't take the Service_lock while safepointed
        3) Split Service_lock and create a new lock for the deferred JVMTI events. This lock will have another rank which doesn't conflict with the oopstorage lock.
        4) Don't apply non-GC closures while iterating over the root set

        We think that (4) is the best approach since it makes the code more robust and prevents similar lock order bugs.

        Attachments

          Issue Links

            Activity

              People

                stefank Stefan Karlsson
                stefank Stefan Karlsson
                Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: