sun/management/HotspotThreadMBean/GetInternalThreads.java fails the following assert:

    Internal Error (src/share/vm/runtime/mutex.cpp:1292)
    Error: acquiring lock Terminator_lock/16 out of order
        with lock Threads_lock/15 -- possible deadlock

So far this test has failed on Solaris AMD64 Server VM,
Linux IA32 Server VM, Win-AMD64 Server VM, Win32 Server VM,
Linux AMD64 Server VM and Solaris X86 Server VM. The nightly
search tool did not find any failures for this test in the
2008.08.19 nightly.
Posted Date : 2008-08-22 17:53:34.0

New MM_REGRESSION failures (from 2008.08.21)
*   sun/management/HotspotThreadMBean/GetInternalThreads.java
        This test failed the following assertion:

            Internal Error (src/share/vm/runtime/mutex.cpp:1292)
            Error: acquiring lock Terminator_lock/16 out of order with
                lock Threads_lock/15 -- possible deadlock

        on all Client and Server VM configs.

See the MM_REGRESSION results in the following nightly:

http://sqeweb.sfbay.sun.com/nfs/results/vm/gtee/JDK7/NIGHTLY/VM/2008-08-21/Serv_Baseline/index.html
Posted Date : 2008-08-22 19:28:49.0

N/A

The root cause is described in the comment section and the fix could be as simple as removing the lock acquisition when calling ThreadClosure->do_thread(WatcherThread) and just do a NULL check. The potential problem of this is that when examing the fields of WatcherThread, it could have been already terminated and its memory could have been purged by the memory subsystem, however, considerig the VM is also terminating during the termination of WatcherThread and the VM termination occurs at safepoint, the chance of the fatality is extremely low and the worst case is the call site gets the wrong information about the WatcherThread which is probably better than simply crashing.
Posted Date : 2008-08-22 17:53:34.0

http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b33eef719520
Posted Date : 2008-08-26 02:24:18.0