Thread Native ID Access

[mandy chung]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180221/4e227a29/attachment.html>