Thread Native ID Access

[mandy chung]

JDK 5 did very minimal for monitoring of native OS resources due to its 
scope and also its platform-dependent nature. I don't have a good advice 
how and where to expose them via Java SE API without further 
investigation. A couple of things come to mind: - Should native threads 
be exposed in Process API? - jdk.management module defines JDK extension 
to java.lang.management API that might be a good place to list VM 
threads. - other than VM threads and Java to native OS threads mapping, 
any other items on your list for monitoring? Mandy [1] 
http://download.java.net/java/jdk10/docs/api/jdk.management-summary.html

On 2/21/18 3:46 PM, Jeremy Manson wrote:
> 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 > 
<mailto: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/ > 
<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 >> 
<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/89be9ef9/attachment-0001.html>