os::current_thread_id on Linux
Jeremy Manson
jeremymanson at google.com
Mon Jul 27 18:14:09 UTC 2015
Turns out JDK-6661889 already covered this.
Jeremy
On Mon, Jul 27, 2015 at 11:11 AM, Jeremy Manson <jeremymanson at google.com>
wrote:
> 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/9202345a/attachment-0001.html>
More information about the serviceability-dev
mailing list