On Thu, 30 Jul 2026 12:46:07 GMT, Coleen Phillimore <[email protected]> wrote:
>> src/hotspot/share/services/threadService.cpp line 520: >> >>> 518: previousThread = currentThread; >>> 519: waitingToLockMonitor = >>> (ObjectMonitor*)currentThread->current_pending_monitor(); >>> 520: waitingToLockRawMonitor = >>> currentThread->current_pending_raw_monitor(); >> >> This seems reasonable, but I do worry a little because of the comment: >> >> // JVM TI raw monitors can also be involved in deadlocks, and we can be >> // waiting to lock both a raw monitor and ObjectMonitor at the same time. >> // It isn't clear how to make deadlock detection work correctly if that >> // happens. >> >> Updating the raw monitor here might change something - but I struggle to see >> exactly how this cycle detection is working anyway. > > Not updating the current thread's raw monitor seems to have been an omission > in your JDK-8231289 change and not deliberate. The comment I think is trying > to say that there can be deadlocks with both raw monitors and Java monitors, > and below it says that it picks raw monitor deadlock to report in the cycle. > > It doesn't seem to justify keeping a stale raw monitor pointer through each > iteration of the loop. by the way JDK-8231289 was a really great change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3684191446
