Am 22.07.2015 um 20:52 schrieb Jeremy Manson:
Example of where this would help:
Current output of SIGQUIT:
"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007f0890247800
nid=0x2e3d waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f0890245000
nid=0x2e3c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f0890243800
nid=0x2e3b waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f0890240800
nid=0x2e3a waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
Current directory listing from /tmp with -XX:+UnlockDiagnosticVMOptions
-XX:+LogCompilation:
$ ls -d /tmp/hs*
hs_c139673756251904_pid11818.log hs_c139673759409920_pid11818.log
hs_c139673757304576_pid11818.log hsperfdata_jeremymanson/
hs_c139673758357248_pid11818.log hsperfdata_root/
Output with this change would look like:
$ ls -d /tmp/hs*
hs_c11837_pid11818.log hs_c11834_pid11818.log
hs_c11836_pid11818.log hsperfdata_jeremymanson/
hs_c11835_pid11818.log hsperfdata_root/
Where 1183x maps neatly back to 0x2e3x in the SIGQUIT dump.
I always though the other thread id is the tid printed above. At least I
vaguely remember to have successfully used that id to match against
thread IDs as ouput by the gstack command. In your concrete example
above, tid and long thread ID do not exactly match though, e.g.
139673756251904 = 0x00007f0854a03700
Regards,
Rainer