os::current_thread_id on Linux
david.holmes at oracle.com
Thu Jul 23 02:08:08 UTC 2015
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
// 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
> 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.
More information about the hotspot-runtime-dev