The Thread-SMR project added a couple of counter based tests for
ThreadMXBean.getThreadInfo() and ThreadInfo.getLockOwnerName():

nsk/monitoring/ThreadInfo/isSuspended/issuspended002.java
nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java

See "JDK-8167108 inconsistent handling of SR_lock can lead to crashes".

The tests have been moved/renamed to:

test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadInfo/isSuspended/issuspended002/TestDescription.java
test/hotspot/jtreg/vmTestbase/nsk/monitoring/ThreadMXBean/findMonitorDeadlockedThreads/find006.java

I've created a time based test for ThreadMXBean.getThreadInfo()
and ThreadInfo.getLockOwnerName(). This time based test is more
appropriate for use in stress kits instead of a counter based test like
issuspended002 or find006.

I created the test for investigating the following bug:

    JDK-8263901 RunThese30M.java failed with SIGSEGV in Threads::owning_thread_from_monitor_owner

and I've verified that this test does exercise the crashing thread's
code path from JDK-8263901. However, the getThreadInfo() and
getLockOwnerName() APIs do not use nested ThreadsListHandles
and I believe that's the root cause for JDK-8263901. I wasn't able
to prove my theory so I closed JDK-8263901 as not reproducible,
but the test I developed is still quite useful for exercising the use
of ThreadsListHandles by getThreadInfo() when gathering a thread's
info either at a safepoint or at a non-safepoint.