os::current_thread_id on Linux

[Jeremy Manson]

Right.  Those values were taken off of actual output from a JVM.

I think that, generally, they will be relatively close to each other in
memory, but not actually the same.  That jibes with one being pthread_self
and the other being the address of the JVM's thread object - they would be
created at roughly the same time.

Since no one has noticed this for the O(years) that it has been in place, I
argue that no one is relying on this behavior. :)

Jeremy

On Wed, Jul 22, 2015 at 2:10 PM, Rainer Jung <rainer.jung at kippdata.de>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150722/d64030b0/attachment-0001.html>