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.ch...@oracle.com >
<mailto:mandy.ch...@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 > >
