On Thu, 30 Jul 2026 15:50:59 GMT, Coleen Phillimore <[email protected]> wrote:
>> 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. Thanks for pointing out this was in fact my code and comment :). I had forgotten about this. The problem with being able to wait on a raw-monitor and normal object monitor at the same time was flagged by @dcubed-ojdk . That then highlighted that the existing deadlock detection code could not handle this situation (one thread waiting on two things each with a different owner). The conclusion was to not try and fix that but make things a little less broken than they already were: https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2019-October/036219.html So I suspect your change here might change the way in which the code is broken for the mixed case. But it does fix the pure raw monitor deadlock case. That was a case that @sspitsyn pointed out: https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2019-October/036244.html but I did not attempt to fix it (the PR was about refactoring/cleaning). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3687070757
