os::current_thread_id on Linux

David Holmes david.holmes at oracle.com
Thu Jul 23 07:16:07 UTC 2015

On 23/07/2015 4:11 PM, Jeremy Manson wrote:
> Okay.  TBH, thinking about it more, it's a little weird for something
> named os::current_thread_id() to be different from
> Thread::current()->osThread->thread_id(), or for either of them to be
> different from "what the OS thinks the thread id is", so it seems like
> the Right Thing to Do (in the absence of any platform-specific issues).

When there are two different levels of thread ID it isn't that simple - 
especially as, like you say, one can be used to look in /proc while the 
other can't. So perhaps better naming is in order.


> Jeremy
> On Wed, Jul 22, 2015 at 10:57 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>     On 23/07/2015 3:15 PM, Jeremy Manson wrote:
>         Hey David,
>         Thanks for the offer of sponsorship.  My goal here is really to
>         make the
>         log output on Linux usable.  I want to be able to map the log output
>         back to an actual thread.  I don't think it really matters to
>         users if
>         the API consistently means "kernel thread ID" or "threading API
>         thread
>         ID", as long as they can figure out what the output means.
>     I think consistency is important else developers don't know what
>     they should be using where - which is the current situation.
>         Since what I am doing (in effect) to accomplish my goal is to ensure
>         that the API returns the same value as osthread()->thread_id()
>         does for
>         the current thread,  I could just... do precisely that.
>         os::current_thread_id could just return osthread()->thread_id()
>         for the
>         current thread. I don't have easy access to anything for testing
>         other
>         than Linux, though, so whether it worked (or even compiled) on
>         the other
>         platforms would be a bit of a guess (per the last time we did
>         this dance).
>     Defining os::current_thread_id() to be
>     Thread::current()->osThread()->thread_id() assumes you can make
>     those calls in the context in which os::current_thread_id() is used
>     - if we crash during thread startup then some of those may be null
>     and the id not even set. The current implementation is independent
>     of the state of thread within the VM.
>     So its okay to return the same thing as
>     Thread::current()->osThread()->thread_id() but it needs to be done
>     directly.
>     Again any platform for which this would cause a change in behaviour
>     needs to be examined. It may be other platforms have the same
>     problem you are trying to fix for linux.
>     If I get time later I'll try to check what each platform does.
>     Thanks,
>     David
>         Seem reasonable?
>         Jeremy
>         On Wed, Jul 22, 2015 at 7:08 PM, David Holmes
>         <david.holmes at oracle.com <mailto:david.holmes at oracle.com>
>         <mailto:david.holmes at oracle.com
>         <mailto:david.holmes at oracle.com>>> wrote:
>              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> <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>>
>                  <mailto:jeremymanson at google.com
>         <mailto:jeremymanson at google.com>
>                  <mailto: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

More information about the hotspot-runtime-dev mailing list