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.