Thread Native ID Access

[Jeremy Manson]

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>
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 <jeremymanson at google.com>
> *Gesendet: *Donnerstag, 22. Februar 2018 20:01
> *An: *Alan Bateman <Alan.Bateman at oracle.com>
> *Cc: *serviceability-dev at openjdk.java.net; 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>
> 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/c2d55d76/attachment-0001.html>