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
