The VMOperationQueue::oops_do() function runs without the VMOperationQueue_lock. It walks lists of VM_Operations to find VM_Operations that need to perform oops_do during GC root processing.

However, since the VMOperationQueue_lock is not held while walking this list, a non-Java thread that is not stopped during safepoints (e.g. EnableBiasedLocking from the periodic task thread, or an eager concurrent marking thread) might enqueue a new VM_Operation concurrently. If that happens, elements could temporarily disappear from the list as observed by the GC during root scanning, and VM_Operations with naked oops might find themselves pointing to dead memory.