Thread Native ID Access

[Alan Bateman]

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/2dffc191/attachment.html>