On Wed, 13 Nov 2024 08:26:57 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> Hi
>> Could you please "pre-review" this fix that add locks information. I want to
>> get some preliminary feedback before completing the changes.
>>
>> Here is the motivation for this rfe and explanation why I add it into SA now.
>>
>> The information about current owners of Hotspot Mutex is often very useful
>> for dealock investigations.
>>
>> The jcmd usually doesn't work because VM can't reach or exit safepoints. So
>> it doesn't respond to jcmd.
>>
>> The SA 'jstack --mixed' provides information about stacktraces on Java and
>> non-Java Threads. So having information about locks along with stack traces
>> might significantly help to identify issues.
>>
>> The gdb allows to provide stacktraces, but the debug symbols are required to
>> get info about locks. These symbols are often absent during execution.
>> Also the debugger solution is OS specifc.
>>
>> The significant part of fix is refacotorrng of mutex_array to be vmStructs
>> compatible.
>>
>> The adding support of non-JavaThreads into SA might be implemented later to
>> obtain more info about their names.
>> The example of output:
>>
>> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563
>> Attaching to process ID 1620533, please wait...
>> Debugger attached successfully.
>> Server compiler detected.
>> JVM version is 24-internal-adhoc.lmesnik.open
>> Deadlock Detection:
>>
>> No deadlocks found.
>>
>> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be
>> non-Java Thread) with address: 0x00007f8cf825b190
>> Internal VM Mutex Compile_lock is owned by LockerThread with address:
>> 0x00007f8cf8309a00
>> ----------------- 1620559 -----------------
>> "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559
>> runnable [0x0000000000000000]
>> java.lang.Thread.State: RUNNABLE
>> JavaThread state: _thread_blocked
>> 0x00007f8cff11e88d syscall + 0x1d
>> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e
>> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool)
>> + 0x79
>> 0x00007f8cfd53ea91
>> ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1
>> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30
>> 0x00007f8cfd679614
>> CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204
>> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8
>> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc
>> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe
>> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b
>> .....
>> -------...
>
> src/hotspot/share/runtime/mutex.cpp line 270:
>
>> 268: }
>> 269:
>> 270: static const int MAX_NUM_MUTEX = 1204;
>
> Q: Is the number `1204` intentional or it was supposed to be `1024`? :)
This codes
with
MAX_NUM_MUTEX = 1204
and
void Mutex::add_mutex(Mutex* var) {
has been just moved from mutexLocker.
I haven't changed it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1841198179
