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/
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
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
