On Thu, 30 Jul 2026 20:41:30 GMT, Coleen Phillimore <[email protected]> wrote:
>> This fixes the crash when printing deadlocks when the only lock held for the >> thread in the deadlock is the JVMTI raw monitor lock. This also fixes >> deadlock detection for only raw monitor locks and adds a test for it. >> >> make test TEST="serviceability/dcmd/thread >> vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock >> serviceability/jvmti/SuspendWithRawMonitorEnter >> serviceability/jvmti/vthread/RawMonitorTest" >> >> Tested with jvmti deadlock detection tests above, and tier 1-4 in progress. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Coleen Phillimore has updated the pull request incrementally with one > additional commit since the last revision: > > Remove something I missed. src/hotspot/share/services/threadService.cpp line 1044: > 1042: owner_desc = "\n in JNI, which is held by"; > 1043: } > 1044: currentThread = Threads::owning_thread_from_monitor(t_list, > waitingToLockMonitor); Not sure, I fully understand how the variable `currentThread` is used. It seems that it is possible that both `waitingToLockRawMonitor` and `waitingToLockMonitor` are non-null. So, the `currentThread` can be set at the line 1025: `currentThread = JavaThread::cast(owner);` Then this it can be used at line 1041: `if (!currentThread->current_pending_monitor_is_from_java()) {` and can be reset at line 1044: `currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);` This potential issue was probably before your fix. We may want to file a separate bug if there is an issue here. test/hotspot/jtreg/serviceability/dcmd/thread/PrintRawMonitorLockTest.java line 49: > 47: import java.util.concurrent.CyclicBarrier; > 48: import java.util.concurrent.locks.ReentrantLock; > 49: import java.util.regex.Pattern; Nit: Two imports above at lines 48-49 might be not needed. test/hotspot/jtreg/serviceability/dcmd/thread/PrintRawMonitorLockTest.java line 132: > 130: break; > 131: } > 132: } Nit: The loop above can iterate forever if the `break` at line 130 does not happen. test/hotspot/jtreg/serviceability/dcmd/thread/libPrintRawMonitorLockTest.cpp line 41: > 39: printf("\n"); \ > 40: fflush(stdout); \ > 41: } while (0) Nit: It is better to use the `LOG` macro from `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp`. Then the line 24 can be not needed anymore: `#include <string.h>` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690019776 PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690067141 PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690081640 PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690045416
