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.


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?


Reply via email to