RFR: 8343741: SA jstack --mixed should print information about VM locks

[Serguei Spitsyn]

On Thu, 7 Nov 2024 01:11:14 GMT, Leonid Mesnik <lmesnik at 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
> .....
> ----------------- 1620554 -----------------
> "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=16...

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`?  :)

src/hotspot/share/runtime/mutex.cpp line 275:

> 273: int Mutex::_num_mutex = 0;
> 274: 
> 275: void Mutex::add_mutex(Mutex* var) {

Nit: Why `var` but not `arg`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1839729824
PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1839731580