os::current_thread_id on Linux

[David Holmes]

On 23/07/2015 8:01 AM, Jeremy Manson wrote:
> Based on the feedback, this seems to be a good idea, approximately.
> Coleen would have sponsored, but she's going on vacation.  Anyone else
> feel like sponsoring?

Hold up a minute! :) There are different notions of "native thread id" 
that exist. First we have the "user level thread id" - this is what is 
reported by pthread_self in POSIX and thr_self in UI. Then we also have 
the OS specific "thread" id, also referred to as a LWP or "kernel 
scheduling entity" or "kernel thread" - the id for this is what gettid() 
maps back to on Linux. This distinction may not exist on all platforms.

Unfortunately os::current_thread_id does not define which of these it 
represents:

  // thread id on Linux/64bit is 64bit, on Windows and Solaris, it's 32bit
   static intx current_thread_id();

and so on some platforms it returns the "user thread id" (eg 
pthread_self()), and on some it returns the same as gettid (ie OSX - but 
I don't know if the mach thread id is truly a "LWP" id ?).

Also note that on some platforms the osThread stores the id of the 
"user-level thread" and on some the "kernel thread". Hence another 
source of confusion. :(

So if you want to enforce that os::current_thread_id() represents the 
"kernel thread" then that should be applied consistently across all 
platforms**, and for platforms for which there is a change to make you 
have to ensure the usage of os::current_thread_id() is not semantically 
altered by the change.

** Of course a platform may only have a single notion of "thread"

I'm happy to sponsor such a proposal. And don't worry about maintaining 
compatibility with archaic Linux versions for JDK9 (less cleanup to do 
later).

Thanks,
David

> Jeremy
>
> On Wed, Jul 22, 2015 at 11:22 AM, Jeremy Manson <jeremymanson at google.com
> <mailto: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
>
>