The following test failed in an Adhoc Mach5 job for JDK-8153224:

applications/runthese/RunThese30M.java

Here are snippets from the hs_err_pid file:

# SIGSEGV (0xb) at pc=0x000000010c169052, pid=17627, tid=20227
#
# JRE version: Java(TM) SE Runtime Environment (13.0) (build 13-internal+0-2019-08-05-1257029.daniel.daugherty.8153224formach5)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (13-internal+0-2019-08-05-1257029.daniel.daugherty.8153224formach5, mixed mode, tiered, parallel gc, bsd-amd64)
# Problematic frame:
# V [libjvm.dylib+0x369052] FindInstanceClosure::do_object(oopDesc*)+0x3c

--------------- T H R E A D ---------------

Current thread (0x00007fc9b6809800): VMThread "VM Thread" [stack: 0x00007000061fa000,0x00007000062fa000] [id=20227]

Stack: [0x00007000061fa000,0x00007000062fa000], sp=0x00007000062f99c0, free space=1022k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0x369052] FindInstanceClosure::do_object(oopDesc*)+0x3c
V [libjvm.dylib+0x604397] MutableSpace::object_iterate(ObjectClosure*)+0x3b
V [libjvm.dylib+0x368f36] HeapInspection::find_instances_at_safepoint(Klass*, GrowableArray<oopDesc*>*)+0x4a
V [libjvm.dylib+0x73c66b] ConcurrentLocksDump::dump_at_safepoint()+0x57
V [libjvm.dylib+0x784033] VM_ThreadDump::doit()+0x65
V [libjvm.dylib+0x7839f5] VM_Operation::evaluate()+0xd5
V [libjvm.dylib+0x78b5f5] VMThread::evaluate_operation(VM_Operation*)+0x123
V [libjvm.dylib+0x78b015] VMThread::loop()+0x101
V [libjvm.dylib+0x78ae08] VMThread::run()+0x78
V [libjvm.dylib+0x72fdaf] Thread::call_run()+0x71
V [libjvm.dylib+0x626475] thread_native_entry(Thread*)+0x132
C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154
C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0
C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd

This is NOT the same bug as:

    JDK-8229179 FindInstanceClosure::do_object crash during safepoint

So far this failure mode has only been seen with parallel-gc
with JDK-8153224 bits (Async Monitor Deflation project bits).

Note: This bug is in hotspot/runtime because so far it has only been seen with Adhoc testing
of JDK-8153224.