Thread Native ID Access

[Jeremy Manson]

There isn't a pressing need.  I wrote this patch almost 5 years ago.  We
can do what we've always done and keep the patch locally.  It's just more
work for us to keep forward porting it, and loss of potential benefit to
the community.

I can certainly understand not wanting this in the high-value real estate
in java.lang.Thread.  I am reasonably happy just to add it to ThreadInfo,
or, if we think even that's too much, just to
com.sun.management.ThreadMXBean.

Since Alan cc'd loom-dev, I'll reiterate what I said before: IMO, for the
purposes of this feature, it doesn't matter how fibers map to Java Threads,
or how Java Threads map to OS threads.  As long as a Java Thread is running
on some OS thread (and nothing that we do in the JVM will change that),
this proposed API can return whatever OS thread the Java Thread currently
maps to.

David asked the following question:

For things like  /proc/<pid>/task/<nid> is there a way to say <nid> in a
> way that means "current thread"? That may be a partial solution - or even
> whole if you could then read back the actual id?
>

Linux 3.17 and greater has /proc/thread-self.  But I'm not sure that's a
solution - if I want to use this to generate a list of threads with Java
names and OS-level state (which often differs from JVM thread state), then
I'm not sure how I would do that.

Mandy says this:

> - other than VM threads and Java to native OS threads mapping, any other
>   items on your list for monitoring?
>
>
There is a bunch of stuff - the ongoing thread with JC Beyler about our
heap profiler is the current thing on the front burner.  The only thing
that is relevant to thread monitoring is the aforementioned list of VM
threads, but that's not a point change to ThreadInfo.

For some of the other stuff, we need to do more due diligence on our end or
wait and see what you are doing before pushing it.  For example, we have
programmatic access to JFR event based GC history, but we're waiting to see
how the open-sourcing goes on that before pushing.  We have TSan support,
which we've mentioned in various forums before.  We let people register
native callbacks on allocation sites, but that's likely to get folded into
the heap profiling work.  We let monitoring tools look at the code cache
directly to avoid JVMTI overhead, but that's pretty dangerous, so I'm not
sure that it's a great idea as-is.  We have a bunch of extra entries in
perfdata, but we should probably review them to make sure we still care
about all of them.

We also have some bug fixes and performance improvements, and we should
probably just send those in.

Jeremy

On Thu, Feb 22, 2018 at 7:24 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 21/02/2018 22:40, 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...
>
> Mandy mentioned fibers in one of the replies and I think we do need to be
> cautious about exposing native thread IDs in the Java SE APIs until we have
> a better sense how some of these APIs will work. I expect there will be a
> Thread object per fiber but I'm less sure on ThreadMXBean. It may be that
> ThreadMXBean's dumpAllThreads returns the ThreadInfos for just the kernels
> threads, the equivalent of today where it only returns the ThreadInfos for
> the started threads, but once the project is further along then maybe a
> different choice might emerge.
>
> If there is pressing need then could we just expose it it in the
> JDK-specific com.sun.management.ThreadMXBean API instead?
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180222/50c04c4c/attachment-0001.html>