JDK-8352116 : Deadlock with GCLocker and JVMTI after JDK-8192647
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 25
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2025-03-16
  • Updated: 2025-08-22
  • Resolved: 2025-04-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b18Fixed
Related Reports
Relates :  
JDK-8192647 - GClocker induced GCs can starve threads requiring memory leading to OOME
Description
Stress process times out. See comments for details.
Comments
No failures, but not verified explicitly.
22-08-2025
Changeset: 39549f89 Branch: master Author: Albert Mingkun Yang <ayang@openjdk.org> Date: 2025-04-07 09:13:43 +0000 URL: https://git.openjdk.org/jdk/commit/39549f89905019fa90dd20ff8b6822c1351cbaa6
07-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24407 Date: 2025-04-03 09:40:19 +0000
04-04-2025
Based on stacktraces shared by Leonid, I believe the problematic scenario is as follows: Thread A: in JvmtiTagMap::iterate_through_heap, held EscapeBarrier_lock and waits for Heap_lock Thread B: in GCLocker::block, held Heap_lock and waits for threads in critical-region to exit Thread C: in JavaThread::wait_for_object_deoptimization (by jni_ReleasePrimitiveArrayCritical), on its way to exit critical-region, waiting for EscapeBarrier_lock So, in this case, A waits for B, B waits for C, and C waits for A, causing deadlock.
20-03-2025
Stress process times out. It is seems it is deadlock during VM shutdown caused by https://bugs.openjdk.org/browse/JDK-8192647 A lost of threads are stuck in #3 0x00007fd16c72e7a4 in JavaThread::wait_for_object_deoptimization() () #4 0x00007fd16c72e9c4 in JavaThread::handle_special_runtime_exit_condition() wating for EscapeLock. and the following thread waiting for a HeapLock Thread 20 (Thread 0x7fd123727700 (LWP 27828)): #0 0x00007fd16da438ad in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fd16da3cb19 in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x00007fd16cd09740 in Mutex::lock_contended(Thread*) () from #3 0x00007fd16cd0b67a in Mutex::lock() () from #4 0x00007fd16ca7495d in JvmtiTagMap::iterate_through_heap(int, Klass*, jvmtiHeapCallbacks const*, void const*) () from #5 0x00007fd16ca1308d in JvmtiEnv::IterateThroughHeap(int, _jclass*, jvmtiHeapCallbacks const*, void const*) () from #6 0x00007fd16c9a97c9 in jvmti_IterateThroughHeap () from #7 0x00007fd16e528467 in get_heap_info (klass=<optimized out>, env=0x7fd164735b90) at while on of other threads is checking until GClocker is unlocked Thread 72 (Thread 0x7fcfc413f700 (LWP 40060)): #0 0x00007fd16e176118 in nanosleep () from /lib64/libc.so.6 #1 0x00007fd16cdbac01 in os::naked_short_nanosleep(long) () from #2 0x00007fd16cf6ce0d in SpinYield::yield_or_sleep() () from #3 0x00007fd16c5c1940 in GCLocker::block() () from #4 0x00007fd16c5d5d8e in VM_GC_Operation::doit_prologue() () fro #5 0x00007fd16d1ff2e0 in VMThread::execute(VM_Operation*) () from #6 0x00007fd16cf29b29 in SerialHeap::mem_allocate_work(unsigned long, bool) () froo #7 0x00007fd16cf29fba in SerialHeap::allocate_new_tlab(unsigned long, unsigned long, unsigned long*) () f #8 0x00007fd16cc5171c in MemAllocator::mem_allocate_inside_tlab_slow(MemAllocator::Allocation&) const () from #9 0x00007fd16cc51df3 in MemAllocator::mem_allocate(MemAllocator::Allocation&) const () from #10 0x00007fd16cc51f05 in MemAllocator::allocate() const () from #11 0x00007fd16c68e1ce in InstanceKlass::allocate_instance(JavaThread*) () from / #12 0x00007fd16ceff185 in OptoRuntime::new_instance_C(Klass*, JavaThread*) () from #13 0x00007fd153dda085 in ?? () #14 0x0000000000000000 in ?? () and one more in jni_ReleasePrimitiveArrayCritical can't unpin the array and unlock GCLocker because stuck wating for EscapeLock #0 0x00007fd16da404dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00007fd16cdbd84c in PlatformMonitor::wait(unsigned long) () from #2 0x00007fd16cd0aa27 in Monitor::wait_without_safepoint_check(unsigned long) () from #3 0x00007fd16c72e7a4 in JavaThread::wait_for_object_deoptimization() () from #4 0x00007fd16c72e9c4 in JavaThread::handle_special_runtime_exit_condition() () from #5 0x00007fd16c1037fb in ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) () #6 0x00007fd16c82a597 in jni_ReleasePrimitiveArrayCritical () from #7 0x00007fd16e4e6f19 in Java_java_util_zip_Inflater_inflateBytesBytes () from #8 0x00007fd15431d5d1 in ?? () #9 0x00007fcfc6c68520 in ?? ()
20-03-2025
It looks like regression after https://bugs.openjdk.org/browse/JDK-8192647
20-03-2025