On Fri, 31 Jul 2026 11:13:37 GMT, Serguei Spitsyn <[email protected]> wrote:
>> 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.
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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32092#discussion_r3690525949
