On Thu, 30 Jul 2026 23:59:38 GMT, David Holmes <[email protected]> wrote:
>> 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). So it was known. But it does make sense to fix the raw monitor only case, if only to prevent and test the crash that this is fixing. I think the mixed case is strange and unlikely and this algorithm seems to favor the case where the raw monitor is involved in the deadlock now because it'll correctly find it now. Not sure how much of an observable difference this is, and whether it matters at all. Could file a bug to try to describe this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690646150
