os::current_thread_id on Linux

[Jeremy Manson]

On Wed, Jul 22, 2015 at 12:15 PM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
> 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?
>

The long hex number in the SIGQUIT output is the address of the thread
object.  It doesn't map to pthread_self.  So there is no current way to map
the compiler thread id back to the sigquit output.


> 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.


It's used to indicate thread ownership of resources in a couple of places,
but there was nothing about pthread_self that seemed more correct to me in
those places.

If you are willing to sponsor, I can file a bug and send a change for
review.  Thanks!

Jeremy


>
>
> 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
>>>
>>>
>