The following test failed in the JDK24 CI:

applications/runthese/RunThese8H.java

Here's a snippet from the hs_err_pid file:

# Internal Error (/opt/mach5/mesos/work_dir/slaves/a4a7850a-7c35-410a-b879-d77fbb2f6087-S145420/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6031c61c-6479-49c3-9133-e5c76dc550bf/runs/15c267c0-adec-4c73-bdaf-d474290ee02a/workspace/open/src/hotspot/share/runtime/synchronizer.cpp:599), pid=317712, tid=317752
# assert(monitor->owner() == Thread::current()) failed: must be owner=0x00007fe5681f8e60 current=0x00007fe6508e5ac0 mark=0x00007fe59c088402
#
# JRE version: Java(TM) SE Runtime Environment (24.0+8) (fastdebug build 24-ea+8-851)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 24-ea+8-851, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x175b571] ObjectSynchronizer::enter_fast_impl(Handle, BasicLock*, JavaThread*)+0xc11

<snip>

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

Current thread (0x00007fe6508e5ac0): JavaThread "JvmtiStressModule" [_thread_in_vm, id=317752, stack(0x00007fe5ff1f3000,0x00007fe5ff2f3000) (1024K)] _threads_hazard_ptr=0x00007fe554938460, _nested_threads_hazard_ptr_cnt=0

Stack: [0x00007fe5ff1f3000,0x00007fe5ff2f3000], sp=0x00007fe5ff2ed340, free space=1000k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x175b571] ObjectSynchronizer::enter_fast_impl(Handle, BasicLock*, JavaThread*)+0xc11 (synchronizer.cpp:599)
V [libjvm.so+0x175c744] ObjectSynchronizer::enter_for(Handle, BasicLock*, JavaThread*)+0x34 (synchronizer.cpp:527)
V [libjvm.so+0xab88a0] Deoptimization::relock_objects(JavaThread*, GrowableArray<MonitorInfo*>*, JavaThread*, frame&, int, bool)+0x6d0 (deoptimization.cpp:1647)
V [libjvm.so+0xac1bea] restore_eliminated_locks(JavaThread*, GrowableArray<compiledVFrame*>*, bool, frame&, int, bool&)+0x5da (deoptimization.cpp:401)
V [libjvm.so+0xac5628] Deoptimization::deoptimize_objects_internal(JavaThread*, GrowableArray<compiledVFrame*>*, bool&)+0x148 (deoptimization.cpp:460)
V [libjvm.so+0xbbd2ff] EscapeBarrier::deoptimize_objects_internal(JavaThread*, long*)+0x10f (escapeBarrier.cpp:364)
V [libjvm.so+0xbbe6e1] EscapeBarrier::deoptimize_objects_all_threads()+0x211 (escapeBarrier.cpp:150)
V [libjvm.so+0x11b63a7] JvmtiTagMap::iterate_through_heap(int, Klass*, jvmtiHeapCallbacks const*, void const*)+0x97 (jvmtiTagMap.cpp:1152)
V [libjvm.so+0x115cd90] JvmtiEnv::IterateThroughHeap(int, _jclass*, jvmtiHeapCallbacks const*, void const*)+0x160 (jvmtiEnv.cpp:1932)
V [libjvm.so+0x10fa825] jvmti_IterateThroughHeap+0x105 (jvmtiEnter.cpp:1792)
C [libJvmtiStressModule.so+0x13e7] get_heap_info.isra.0+0x57 (libJvmtiStressModule.c:718)
C [libJvmtiStressModule.so+0x4775] Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_finishIteration+0x6d5 (libJvmtiStressModule.c:927)
j applications.kitchensink.process.stress.modules.JvmtiStressModule.finishIteration()Lapplications/kitchensink/process/stress/modules/JvmtiStatistics;+0
j applications.kitchensink.process.stress.modules.JvmtiStressModule.execute()V+285
j applications.kitchensink.process.stress.modules.StressModule.run()V+118
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@24-ea
j java.lang.Thread.run()V+19 java.base@24-ea
v ~StubRoutines::call_stub 0x00007fe63fd5dd01
V [libjvm.so+0xe66469] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x4a9 (javaCalls.cpp:415)
V [libjvm.so+0xe66afc] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x34c (javaCalls.cpp:329)
V [libjvm.so+0xe66d16] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x76 (javaCalls.cpp:191)
V [libjvm.so+0xfd5253] thread_entry(JavaThread*, JavaThread*)+0x93 (jvm.cpp:2910)
V [libjvm.so+0xe9cbac] JavaThread::thread_main_inner()+0xcc (javaThread.cpp:757)
V [libjvm.so+0x17bd2e6] Thread::call_run()+0xb6 (thread.cpp:225)
V [libjvm.so+0x14a5167] thread_native_entry(Thread*)+0x127 (os_linux.cpp:858)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j applications.kitchensink.process.stress.modules.JvmtiStressModule.finishIteration()Lapplications/kitchensink/process/stress/modules/JvmtiStatistics;+0
j applications.kitchensink.process.stress.modules.JvmtiStressModule.execute()V+285
j applications.kitchensink.process.stress.modules.StressModule.run()V+118
j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@24-ea
j java.lang.Thread.run()V+19 java.base@24-ea
v ~StubRoutines::call_stub 0x00007fe63fd5dd01


This snippet of the crashing stack shows:

V [libjvm.so+0x175b571] ObjectSynchronizer::enter_fast_impl(Handle, BasicLock*, JavaThread*)+0xc11 (synchronizer.cpp:599)
V [libjvm.so+0x175c744] ObjectSynchronizer::enter_for(Handle, BasicLock*, JavaThread*)+0x34 (synchronizer.cpp:527)
V [libjvm.so+0xab88a0] Deoptimization::relock_objects(JavaThread*, GrowableArray<MonitorInfo*>*, JavaThread*, frame&, int, bool)+0x6d0 (deoptimization.cpp:1647)
V [libjvm.so+0xac1bea] restore_eliminated_locks(JavaThread*, GrowableArray<compiledVFrame*>*, bool, frame&, int, bool&)+0x5da (deoptimization.cpp:401)
V [libjvm.so+0xac5628] Deoptimization::deoptimize_objects_internal(JavaThread*, GrowableArray<compiledVFrame*>*, bool&)+0x148 (deoptimization.cpp:460)
V [libjvm.so+0xbbd2ff] EscapeBarrier::deoptimize_objects_internal(JavaThread*, long*)+0x10f (escapeBarrier.cpp:364)
V [libjvm.so+0xbbe6e1] EscapeBarrier::deoptimize_objects_all_threads()+0x211 (escapeBarrier.cpp:150)
V [libjvm.so+0x11b63a7] JvmtiTagMap::iterate_through_heap(int, Klass*, jvmtiHeapCallbacks const*, void const*)+0x97 (jvmtiTagMap.cpp:1152)
V [libjvm.so+0x115cd90] JvmtiEnv::IterateThroughHeap(int, _jclass*, jvmtiHeapCallbacks const*, void const*)+0x160 (jvmtiEnv.cpp:1932)
V [libjvm.so+0x10fa825] jvmti_IterateThroughHeap+0x105 (jvmtiEnter.cpp:1792)

that JVM/TI, deoptimization and synchronization are all involved
in this crash. What a collection of possible choices. I'm starting
this bug off in hotspot/runtime for initial triage since the assertion
failure is in synchronization code and deoptimization is just above
that on the stack.