Name: dd4877 Date: 10/04/2001


daniel.daugherty@Sun 2001-10-04

One of my profiling stress runs hung during VM shutdown.

Here is the scenario:

- sampler thread
  - it queues up a VM_ThreadSuspend operation
  - calls VMOperationRequest_lock->wait()

- VMThread
  - receives the VM_ThreadSuspend operation which is defined as an
    "evaluate at safepoint" operation
  - calls SafepointSynchronize::begin()
  - executes the VM_ThreadSuspend operation
  - calls SafepointSynchronize::end()
  - calls VMOperationRequest_lock->notify_all()
    // at this point the sampler thread is free to return from wait()
    // but it is racing with the JNI DestroyJavaVM() call
  - calls SafepointSynchronize::begin() // we have SafepointALot set
  - calls SafepointSynchronize::end()

- JNI DestroyJavaVM() has been called
  - it queues up a VM_SuspendDaemons operation
  - calls VMOperationRequest_lock->wait()

- VMThread
  - receives the VM_SuspendDaemons operation which is defined as an
    "evaluate at safepoint" operation
  - calls SafepointSynchronize::begin()

- sampler thread
  - receives the notify from the VMThread
  - returns from the internal _Lock_Event->wait() call
  - calls ThreadBlockInVM deconstructor
  - blocks on the safepoint
    // sampler thread still holds the VMOperationRequest_lock

- VMThread
  - processes the VM_SuspendDaemons operation which is defined as an
    "evaluate at safepoint" operation
  - suspends the sampler thread
    // the SuspendChecker thread can't help here because the sampler
    // thread is blocked by the safepoint and we don't end the
    // safepoint until the suspend operation is complete. In other
    // words, the VMThread has deadlocked itself with its own
    // safepointing mechanism.
  - calls SafepointSynchronize::end()
  - blocks on MutexLocker mu(VMOperationRequest_lock)

The key to this deadlock is a VM_ThreadSuspend operation closely
followed by a VM_SuspendDaemons operation.

======================================================================