os::current_thread_id on Linux

[Rainer Jung]

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