Thread Native ID Access

[Jeremy Manson]

Agreed that it is platform-dependent.  That said, so is PID, and you can
now get that from java.lang.Process.  And also, there is very little
available in SIGQUIT thread dumps that you can't get programmatically, and
this is one of the big ticket things (we also have a patch to export the
list of VM threads; maybe that would be useful to expose somewhere).

Although the nid is useful for troubleshooting, it's more often used for
ongoing VM monitoring, because you often want to map from Java Thread to
some native resource, and the only way to do it is via native thread id.
For examples of this sort of thing, on Linux, look in
/proc/<pid>/task/<nid>.  There's a lot of useful information in there, but
how to map it to Java threads is non-obvious.

At Google, we added an interface to export the information, but I would
rather relieve ourselves of the (relatively minor) technical debt and
contribute to the community.

I'm generally a little skeptical that adding to a JDK-specific diagnostic
tool is the right solution.  At Google, at least, it can be very, very
difficult to apply those tools at scale / integrate them into existing
monitoring tooling.  When the JDK has functionality that is only available
via one of these commands, we usually end up having to figure out what the
command is doing and reimplement it.  So, for example, we ended up with our
own parser for hsperfdata.  We end up relying on undocumented interfaces
that can go away at the next JDK revision, and that's not good.

I have no problem with some other, documented interface for it that doesn't
go through Thread/ThreadInfo, but we (at least) will end up needing
something that isn't tied to a particular tool.

As far as the interaction of a feature like this with Fibers (or other
alternate threading approaches, like Green threads): I wouldn't be worried
about that.  A fiber executes on an os thread.  The only thing that might
happen is that the os thread might change over time, or that multiple
fibers might multiplex on the same os thread.  If you are worried about the
value changing, all you have to do is not to cache it in the Thread
object.  You wouldn't want to do that anyway, because it would be a waste
of space for something that's only needed occasionally.

Is there another way of doing the right thing here?

Jeremy



On Wed, Feb 21, 2018 at 3:04 PM, mandy chung <mandy.chung at oracle.com> wrote:

> I'm not comfortable for ThreadInfo to expose the implementation details.
> What should we specify w.r.t. Java Thread mapping to native thread which is
> platform dependent.  Also how does it relate to the future fibers [1]?
>
> Another alternative is for JDK specific diagnostic tools to do that
> mapping for you for example jcmd, rather than exposing it in the API.  I
> assume is that this is more about troubleshooting than on-going VM
> monitoring.
>
> Mandy
> [1] http://openjdk.java.net/projects/loom/
>
>
> On 2/21/18 2:40 PM, Jeremy Manson wrote:
>
> Hey folks,
>
> I mentioned earlier in the thread about the ThreadInfo.from() bug that I
> found this because I was looking at fixing JDK-8154176, which proposes
> introducing native thread ids to Thread and ThreadInfo.
>
> https://bugs.openjdk.java.net/browse/JDK-8154176
>
> I have a prototype for it.  I have a couple of questions, though:
>
> 0) Does anyone object to this being done or my doing it?  I see that it
> already has an owner.
>
> 1) Should the ID be a long?  The Hotspot thread dump prints it out as
> 0x%x, which is an unsigned hexadecimal integer.  The type hiding behind it
> is platform-dependent, though: a pid_t on Linux, an unsigned long on
> Windows, a thread_t on Solaris.  I could make it a String instead...
>
> Jeremy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180221/23f131c5/attachment-0001.html>