os::current_thread_id on Linux
Jeremy Manson
jeremymanson at google.com
Thu Jul 23 18:03:48 UTC 2015
Quick rundown:
On Solaris, osthread and current_thread_id are the same (thr_self()).
On Windows, they are the same (GetCurrentThreadId()).
On OS X, they are the same (pthread_mach_thread_np(::pthread_self()))
On AIX, current_thread_id is pthread_self, and osthread is thread_self()
On non-OS X BSD, current_thread_id is pthread_self, and osthread is the
syscall.
I don't see any code that depends on the particular value of
current_thread_id (for example, assuming that it is the same as thread_self
in a meaningful way on AIX, or that it is pthread_self on AIX). My guess
is that the AIX and non-OS X code are just following the Linux convention.
I'm happy to make current_thread_id consistent with osthread on all of the
platforms, or just on Linux (with the understanding that I can't really
test AIX and OS X easily).
Jeremy
On Thu, Jul 23, 2015 at 12:16 AM, David Holmes <david.holmes at oracle.com>
wrote:
> 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.
>
> Cheers,
> David
>
> 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