Thread Native ID Access

[David Holmes]

On 23/02/2018 5:19 AM, Bernd Eckenfels wrote:
> Agreed, when those hit the Code they will require a different Change. 
> (Which does not make it less useful for the current Code). Probably the 
> ID is from the days of green threads anyway. ��

No it was added in Java SE 5 as a way to uniquely identify Threads.

I don't think this request has any impact on Fibers at all. At any given 
time a piece of executing Java code is executing on a current Thread, 
and that current Thread must be running on a native thread (regardless 
of mapping) and the native thread has an id. The only use for exposing 
such an id is to allow you to correlate information obtained from inside 
the VM, with information observed outside, possibly by external tools.

David
-----

> -- 
> http://bernd.eckenfels.net
> 
> *Von: *Jeremy Manson <mailto:jeremymanson at google.com>
> *Gesendet: *Donnerstag, 22. Februar 2018 20:15
> *An: *Bernd Eckenfels <mailto:ecki at zusammenkunft.net>
> *Cc: *Alan Bateman <mailto:Alan.Bateman at oracle.com>; 
> serviceability-dev at openjdk.java.net 
> <mailto:serviceability-dev at openjdk.java.net>; loom-dev at openjdk.java.net 
> <mailto:loom-dev at openjdk.java.net>
> *Betreff: *Re: Thread Native ID Access
> 
> Bernd,
> 
> The thread ID needs to be unique, so that approach might actually cause 
> problems with fibers, depending on their implementation.
> 
> Jeremy
> 
> On Thu, Feb 22, 2018 at 11:07 AM, Bernd Eckenfels 
> <ecki at zusammenkunft.net <mailto:ecki at zusammenkunft.net>> wrote:
> 
>     Hello,
> 
>     one Option would be to use nid as tid on platforms where the
>     datatype is compatible. Thread#getId() is „positive Long“. That
>     should work(?) at least on Windows and Linux, it will actually
>     reduce some Overhead and make the identifier more useful for
>     Debugging without adding a new API. With the thread-name Counter not
>     being the tid there are way too many different identifiers anyway.
> 
>     Gruss
> 
>     Bernd
> 
>     -- 
>     http://bernd.eckenfels.net
> 
>     *Von: *Jeremy Manson <mailto:jeremymanson at google.com>
>     *Gesendet: *Donnerstag, 22. Februar 2018 20:01
>     *An: *Alan Bateman <mailto:Alan.Bateman at oracle.com>
>     *Cc: *serviceability-dev at openjdk.java.net
>     <mailto:serviceability-dev at openjdk.java.net>;
>     loom-dev at openjdk.java.net <mailto:loom-dev at openjdk.java.net>
>     *Betreff: *Re: Thread Native ID Access
> 
>     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 <mailto: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
>