On Fri, 31 Jul 2026 12:50:02 GMT, Coleen Phillimore <[email protected]> wrote:
>> 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.
>
> It looks like currentThread is reset at the top of the loop, so it doesn't
> follow the currentThread further. I think here it just prints it. Not sure
> if the detection algorithm can get into a weird state but that might be why
> raw monitor deadlocks are given precedence when adding to the cycle loop.
> Frankly I don't really follow the details of how the deadlock detection
> works, but this bit looks okay to me.
I just filed https://bugs.openjdk.org/browse/JDK-8389513.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690742764
