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
