os::current_thread_id on Linux
Jeremy Manson
jeremymanson at google.com
Mon Jul 27 18:11:18 UTC 2015
Okay, thanks, David. I'll submit a patch to make one API call the other,
so that there will be no confusion in the future.
Jeremy
On Thu, Jul 23, 2015 at 5:28 PM, David Holmes <david.holmes at oracle.com>
wrote:
> On 24/07/2015 4:03 AM, Jeremy Manson wrote:
>
>> Quick rundown:
>>
>
> Thanks - sorry I couldn't get to this last night.
>
> On Solaris, osthread and current_thread_id are the same (thr_self()).
>>
>
> So both user-thread
>
> On Windows, they are the same (GetCurrentThreadId()).
>>
>
> Windows is single-level.
>
> On OS X, they are the same (pthread_mach_thread_np(::pthread_self()))
>>
>
> Both "kernel" thread
>
> 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.
>>
>
> One user and one kernel.
>
> 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.
>>
>
> Yes - port by copy. :(
>
> 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).
>>
>
> Just make the change on Linux, there's really no consistency here to aim
> for. :(
>
> Thanks,
> David
>
> Jeremy
>>
>> On Thu, Jul 23, 2015 at 12:16 AM, David Holmes <david.holmes at oracle.com
>> <mailto: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>
>> <mailto: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>>
>> <mailto: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>>>
>> <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
>> <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
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150727/ed8569a2/attachment-0001.html>
More information about the serviceability-dev
mailing list