os::current_thread_id on Linux

[Coleen Phillimore]

With this change would it change this output to os::Linux::gettid() in 
decimal, ie the smaller number?  I take it this is long hex number is 
pthread_self?

To debug, run 'gdb /proc/12549/exe 12549'; then switch to thread 
140452715837184 (0x00007fbdb23c3700)

the hs_err_log file has:

*Current thread (0x00007fbda8011000):  JavaThread "main" [_thread_in_vm, 
id=12550, stack(0x00007fbdb22
c3000,0x00007fbdb23c4000)]

*I'd rather see 12550 which is so much easier to find in gdb (gdb still 
has this number I believe I just verified this).  There is anywhere else 
in the JVM where pthread_self is more correct than the tid?  If not, 
which I think you've stated, this sounds really good to me.

Coleen

On 7/22/15 2:52 PM, Jeremy Manson wrote:
> 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.
>
> Jeremy
>
> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson <jeremymanson at google.com>
> wrote:
>
>> Hey folks,
>>
>> os::current_thread_id on Linux now maps to pthread_self.  The problem with
>> pthread_self is that it only makes sense in the context of the running
>> process.  When it is written out to the log (as it is in several places),
>> there really isn't a way (AFAICT) for the user to map it back to anything
>> useful.
>>
>> As it happens, that value is mostly used to write to the log.  The places
>> where it doesn't do so don't seem to need to use pthread_self for any
>> particular reason.
>>
>> Meanwhile, the SIGQUIT stack dump
>> uses java_thread->osthread()->thread_id() as the nid.  On Linux, that maps
>> back to os::Linux::gettid(), whish is also what gets exposed in /proc.
>> That makes it much easier to see what threads might be doing the log write.
>>
>> Would it be okay to change os::current_thread_id to point
>> to os::Linux::gettid()?  That way, it can be mapped back to the output of a
>> SIGQUIT dump.
>>
>> The downside of gettid() is that it is only available on Linux>2.4.11, but
>> that dates from 2001.  If we really still want to support it, we could
>> check for that.
>>
>> Thoughts?
>>
>> Jeremy
>>