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. ūüėä

-- 
http://bernd.eckenfels.net

Von: Jeremy Manson
Gesendet: Donnerstag, 22. Februar 2018 20:15
An: Bernd Eckenfels
Cc: Alan Bateman; serviceability-dev@openjdk.java.net; loom-...@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 <e...@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
Gesendet: Donnerstag, 22. Februar 2018 20:01
An: Alan Bateman
Cc: serviceability-dev@openjdk.java.net; loom-...@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.bate...@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
 
 


Reply via email to