Thread Native ID Access

[Thomas Stüfe]

Hi Jeremy,

On Wed, Feb 21, 2018 at 11:40 PM, Jeremy Manson <jeremymanson at google.com>
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...
>
>
Just to chime in on this, I would be fine with it. We (SAP) maintain AIX,
linux ppc and s390. Internally we also have a (closed) port for hpux and
AS/400. On all these platforms we have thread ids which can be expressed as
numericals. Neither do I know a contemporary platform which does not have
that, does anyone? And even if they exist, seeing how reluctant we are to
allow new platforms (e.g. see the discussions about letting in the BSD
people into the main line), I cannot see these platforms being porting
targets soon?

But please make it 64bit. At least AIX has 64bit thread ids. That also
gives porters a back door which want or have to hide the real thread id by
just returning e.g. &Thread (probably not that, but something thread
specific which can be represented by a pointer on 64bit platforms).

Kind Regards, Thomas


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