RFR: 7102541: Implement os::set_native_thread

Discussion:

RFR: 7102541: Implement os::set_native_thread_name() on Windows and Linux

Thomas Stüfe

2014-10-10 08:38:27 UTC

Hi all,

I'd like to contribute implementations for os::set_native_thread_name() on
Windows and Linux. We have added this feature to the SAP JVM and it has
been useful for debugging.

http://cr.openjdk.java.net/~simonis/webrevs/7102541/

Associated request:
https://bugs.openjdk.java.net/browse/JDK-7102541

On Windows, it uses the method described here:
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
On Linux, it uses pthread_setname_np(2).

Notes for the windows implementation:
- os::set_native_thread_name() only has any effect if there is a debugger
attached to the process at the time of the function call. The reason is
that the debugger must observe the raised exception. This means that this
method works fine if the VM is being debugged right from the start; for
cases where the debugger attaches during VM life, threads started before
the attach will show default names.
- This was tested using Visual Studio 2013 and Windbg.

Notes for the Linux implementation:
- pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the
function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm'
") or with gdb >= 4.7

Note that not all threads show names. os::set_native_thread_name() was only
called for JavaThread* children before this change, this change adds the VM
thread, but there are some threads for which this function is not yet
called; they appear with their default names.

---

Note that when I was doing this change, I worked first on
https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that
Gerard Ziemski had done a lot of the same work before. But it looks like
his changes did not appear in the hotspot? Either that or I looked at the
wrong place... Anyway, I hope either his or my changes make it into the
hotspot, because the feature is quite useful.

Kind Regards,

Thomas

David Holmes

2014-10-10 09:06:44 UTC

Permalink

Hi Thomas,

Based on the bug report Gerard's work stalled because of solaris issues.
We've covered a lot of ground regarding this in the past. Personally I'm
unhappy about a few things - the windows situations seem not that
useful; the linux 15 character limit also renders this useless for many
cases. Then there is the issue of whether this can only be applied by
the current thread to itself, or by any thread to any thread.

I concede there is some value in some cases but there are enough warts
on this to make me cringe about putting it in. (As I cringed with the
original OSX version.)

That's not to say I'm going to oppose it, but I certainly don't champion
it. :)

Cheers,
David

Post by Thomas StÃ¼fe
Hi all,
I'd like to contribute implementations for os::set_native_thread_name() on
Windows and Linux. We have added this feature to the SAP JVM and it has
been useful for debugging.
http://cr.openjdk.java.net/~simonis/webrevs/7102541/
https://bugs.openjdk.java.net/browse/JDK-7102541
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
On Linux, it uses pthread_setname_np(2).
- os::set_native_thread_name() only has any effect if there is a debugger
attached to the process at the time of the function call. The reason is
that the debugger must observe the raised exception. This means that this
method works fine if the VM is being debugged right from the start; for
cases where the debugger attaches during VM life, threads started before
the attach will show default names.
- This was tested using Visual Studio 2013 and Windbg.
- pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the
function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm'
") or with gdb >= 4.7
Note that not all threads show names. os::set_native_thread_name() was only
called for JavaThread* children before this change, this change adds the VM
thread, but there are some threads for which this function is not yet
called; they appear with their default names.
---
Note that when I was doing this change, I worked first on
https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that
Gerard Ziemski had done a lot of the same work before. But it looks like
his changes did not appear in the hotspot? Either that or I looked at the
wrong place... Anyway, I hope either his or my changes make it into the
hotspot, because the feature is quite useful.
Kind Regards,
Thomas

Staffan Larsen

2014-10-10 10:54:51 UTC

Permalink

Thomas,

I?m happy to see this being worked on and I think the code looks good. We had similar implementations of this in JRockit and very often found them useful.

I don?t share David?s concerns. That we can?t do this on solaris is not a good reason not do it on other platforms. The windows limitation that a debugger has to be attached is a limitation, but the feature is worth a lot when you /do/ have a debugger attached. The 15 character limitation is too bad, but again, better something than nothing.

Thanks,
/Staffan

Post by David Holmes
Hi Thomas,
Based on the bug report Gerard's work stalled because of solaris issues. We've covered a lot of ground regarding this in the past. Personally I'm unhappy about a few things - the windows situations seem not that useful; the linux 15 character limit also renders this useless for many cases. Then there is the issue of whether this can only be applied by the current thread to itself, or by any thread to any thread.
I concede there is some value in some cases but there are enough warts on this to make me cringe about putting it in. (As I cringed with the original OSX version.)
That's not to say I'm going to oppose it, but I certainly don't champion it. :)
Cheers,
David

Christian Tornqvist

2014-10-10 11:06:25 UTC

Permalink

Hi Thomas,

I agree with Staffan. The platform specific limitations are unfortunate but
it shouldn't stop us from doing this. I'd be happy to see the thread names
when debugging on Windows :)

The code looks good.

Thanks,
Christian

-----Original Message-----
From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of
Staffan Larsen
Sent: Friday, October 10, 2014 6:55 AM
To: David Holmes
Cc: hotspot-dev at openjdk.java.net Developers
Subject: Re: RFR: 7102541: Implement os::set_native_thread_name() on Windows
and Linux

Thomas,

I?m happy to see this being worked on and I think the code looks good. We
had similar implementations of this in JRockit and very often found them
useful.

I don?t share David?s concerns. That we can?t do this on solaris is not a
good reason not do it on other platforms. The windows limitation that a
debugger has to be attached is a limitation, but the feature is worth a lot
when you /do/ have a debugger attached. The 15 character limitation is too
bad, but again, better something than nothing.

Thanks,
/Staffan

Post by David Holmes
Hi Thomas,
Based on the bug report Gerard's work stalled because of solaris issues.

We've covered a lot of ground regarding this in the past. Personally I'm
unhappy about a few things - the windows situations seem not that useful;
the linux 15 character limit also renders this useless for many cases. Then
there is the issue of whether this can only be applied by the current thread
to itself, or by any thread to any thread.

Post by David Holmes
I concede there is some value in some cases but there are enough warts
on this to make me cringe about putting it in. (As I cringed with the
original OSX version.)
That's not to say I'm going to oppose it, but I certainly don't champion it. :)
Cheers,
David

Post by Thomas StÃ¼fe
Hi all,
I'd like to contribute implementations for
os::set_native_thread_name() on Windows and Linux. We have added this
feature to the SAP JVM and it has been useful for debugging.
http://cr.openjdk.java.net/~simonis/webrevs/7102541/
https://bugs.openjdk.java.net/browse/JDK-7102541
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
On Linux, it uses pthread_setname_np(2).
- os::set_native_thread_name() only has any effect if there is a
debugger attached to the process at the time of the function call.
The reason is that the debugger must observe the raised exception.
This means that this method works fine if the VM is being debugged
right from the start; for cases where the debugger attaches during VM
life, threads started before the attach will show default names.
- This was tested using Visual Studio 2013 and Windbg.
- pthread_setname_np(2) needs glibc 2.12 or newer. The change loads
the function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg " ps H -p 1234 -o 'pid tid comm'
") or with gdb >= 4.7
Note that not all threads show names. os::set_native_thread_name()
was only called for JavaThread* children before this change, this
change adds the VM thread, but there are some threads for which this
function is not yet called; they appear with their default names.
---
Note that when I was doing this change, I worked first on
https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware
that Gerard Ziemski had done a lot of the same work before. But it
looks like his changes did not appear in the hotspot? Either that or
I looked at the wrong place... Anyway, I hope either his or my
changes make it into the hotspot, because the feature is quite useful.
Kind Regards,
Thomas

Daniel D. Daugherty

2014-10-10 13:18:54 UTC

Permalink

I started this architectural inconsistency when I shepherded in
the os::set_native_thread_name() API with the MacOS X port so
our current state of affairs is that we are inconsistent across
the platforms today.

If I remember our very old discussions, our choices were:

1) remove os::set_native_thread_name() since it cannot be done
consistently across platforms
2) allow differing implementations of os::set_native_thread_name()
to be added as they are developed by interested parties
3) define a Lowest-Common-Denominator (LCD) version of the API
and add platform implementations that adhere to the LCD; in
other words, we hobble implementations that can do more for
the sake of consistency

I don't like #1 or #3. I'm OK with #2 and there's precedent for
platform specific limitations, e.g., filename and pathname length
differences between the various platforms...

Dan

Post by David Holmes
Thomas,
I?m happy to see this being worked on and I think the code looks good. We had similar implementations of this in JRockit and very often found them useful.
I don?t share David?s concerns. That we can?t do this on solaris is not a good reason not do it on other platforms. The windows limitation that a debugger has to be attached is a limitation, but the feature is worth a lot when you /do/ have a debugger attached. The 15 character limitation is too bad, but again, better something than nothing.
Thanks,
/Staffan

Volker Simonis

2014-10-10 13:58:06 UTC

Permalink

Hi,

I totally agree with Staffan. This change simply improves the current
situation on Linux and Windows. And it has no drawbacks on other
platforms.

Can somebody please sponsor this change? And please don't forget to
add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until
now - but he's covered by the general SAP OCA.

Thank you and best regards,
Volker

On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty

Post by Daniel D. Daugherty
I started this architectural inconsistency when I shepherded in
the os::set_native_thread_name() API with the MacOS X port so
our current state of affairs is that we are inconsistent across
the platforms today.
1) remove os::set_native_thread_name() since it cannot be done
consistently across platforms
2) allow differing implementations of os::set_native_thread_name()
to be added as they are developed by interested parties
3) define a Lowest-Common-Denominator (LCD) version of the API
and add platform implementations that adhere to the LCD; in
other words, we hobble implementations that can do more for
the sake of consistency
I don't like #1 or #3. I'm OK with #2 and there's precedent for
platform specific limitations, e.g., filename and pathname length
differences between the various platforms...
Dan

Post by David Holmes
Thomas,
I?m happy to see this being worked on and I think the code looks good. We
had similar implementations of this in JRockit and very often found them
useful.
I don?t share David?s concerns. That we can?t do this on solaris is not a
good reason not do it on other platforms. The windows limitation that a
debugger has to be attached is a limitation, but the feature is worth a lot
when you /do/ have a debugger attached. The 15 character limitation is too
bad, but again, better something than nothing.
Thanks,
/Staffan

Post by David Holmes
Hi Thomas,
Based on the bug report Gerard's work stalled because of solaris issues.
We've covered a lot of ground regarding this in the past. Personally I'm
unhappy about a few things - the windows situations seem not that useful;
the linux 15 character limit also renders this useless for many cases. Then
there is the issue of whether this can only be applied by the current thread
to itself, or by any thread to any thread.
I concede there is some value in some cases but there are enough warts on
this to make me cringe about putting it in. (As I cringed with the original
OSX version.)
That's not to say I'm going to oppose it, but I certainly don't champion it. :)
Cheers,
David

David Holmes

2014-10-10 15:15:37 UTC

Permalink

We should wait for Gerard to catch up with this before any commit is
done. He had also already proposed code changes in the bug report.

We also need to determine where these different platform limitations are
to be documented. Otherwise we will get bug reports (as I'm sure I've
mentioned in previous discussions) regarding missing names (because
setName was not called by the current thread on itself) and duplicate
names (because of the 15 char limit).

On the issue of current thread versus any thread, is pthread_setname_np
restricted to use by the current thread on itself? It is used that way
in this patch, but possibly only to match the restriction that OSX had
introduced. That restriction should be removed on platforms where it can
be removed.

Thanks,
David

Post by Volker Simonis
Hi,
I totally agree with Staffan. This change simply improves the current
situation on Linux and Windows. And it has no drawbacks on other
platforms.
Can somebody please sponsor this change? And please don't forget to
add a "Contributed-by: thomas.stuefe at sap.com" as he's no author until
now - but he's covered by the general SAP OCA.
Thank you and best regards,
Volker
On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty

Post by David Holmes
Thomas,
I?m happy to see this being worked on and I think the code looks good. We
had similar implementations of this in JRockit and very often found them
useful.
I don?t share David?s concerns. That we can?t do this on solaris is not a
good reason not do it on other platforms. The windows limitation that a
debugger has to be attached is a limitation, but the feature is worth a lot
when you /do/ have a debugger attached. The 15 character limitation is too
bad, but again, better something than nothing.
Thanks,
/Staffan

Post by David Holmes
Hi Thomas,
Based on the bug report Gerard's work stalled because of solaris issues.
We've covered a lot of ground regarding this in the past. Personally I'm
unhappy about a few things - the windows situations seem not that useful;
the linux 15 character limit also renders this useless for many cases. Then
there is the issue of whether this can only be applied by the current thread
to itself, or by any thread to any thread.
I concede there is some value in some cases but there are enough warts on
this to make me cringe about putting it in. (As I cringed with the original
OSX version.)
That's not to say I'm going to oppose it, but I certainly don't champion it. :)
Cheers,
David

Thomas Stüfe

2014-10-10 16:46:39 UTC

Permalink

Thank you all for the positive feedback; I really think the feature would
be useful. Right now I am looking at a core on Linux from a Tomcat run and
it is nice to see the thread names in a list instead of having to manually
go thru all threads and examine the stack to guess at the function.

I agree with David that the solution is not complete, but I think it would
be a step in the right direction. Sure it would be nice to have all
platforms; however, 3 out of 5 is not bad. On AIX, I am investigating
whether we can add the feature some other way.

The limitation to the current thread is not a hard limitation; Linux and
Windows implementations work with other threads too. I did not test Mac OS.

I do not think the restriction on Windows is that bad; it is still helpful.
You want thread names, just run the VM in a debugger from the start on.

I even looked for a way to re-establish thread names after the windows
debugger attaches; but seems to be no way to get informed when a debugger
attaches. Theoretically one could add a function which iterates over all
threads, calling os::set_native_thread_name() on them (provided we make it
work for other threads than the current one), and call that function
manually within the Debugger. But I think that would be over engineered.

As for Linux, I think one could even dynamically probe for the largest
allowed thread name at the start of the VM (calling pthread_setname_np with
ever-smaller names until it stops saying ERANGE). That way we could retain
downward compatibility while still profit from larger names should the
glibc people decide to enlarge that name buffer. But again, that may be
over engineered.

As for missing documentation, this should be already a problem now, as the
function is implemented on one platform and the other platforms are stubbed
out? I don't see how the change would change that.

Thomas

On Fri, Oct 10, 2014 at 5:15 PM, David Holmes <david.holmes at oracle.com>

We should wait for Gerard to catch up with this before any commit is done.
He had also already proposed code changes in the bug report.
We also need to determine where these different platform limitations are
to be documented. Otherwise we will get bug reports (as I'm sure I've
mentioned in previous discussions) regarding missing names (because setName
was not called by the current thread on itself) and duplicate names
(because of the 15 char limit).
On the issue of current thread versus any thread, is pthread_setname_np
restricted to use by the current thread on itself? It is used that way in
this patch, but possibly only to match the restriction that OSX had
introduced. That restriction should be removed on platforms where it can be
removed.
Thanks,
David

Post by David Holmes
Thomas,
I?m happy to see this being worked on and I think the code looks good. We
had similar implementations of this in JRockit and very often found them
useful.
I don?t share David?s concerns. That we can?t do this on solaris is not a
good reason not do it on other platforms. The windows limitation that a
debugger has to be attached is a limitation, but the feature is worth a lot
when you /do/ have a debugger attached. The 15 character limitation is too
bad, but again, better something than nothing.
Thanks,
/Staffan
Hi Thomas,

Post by David Holmes
Based on the bug report Gerard's work stalled because of solaris issues.
We've covered a lot of ground regarding this in the past. Personally I'm
unhappy about a few things - the windows situations seem not that useful;
the linux 15 character limit also renders this useless for many cases. Then
there is the issue of whether this can only be applied by the current thread
to itself, or by any thread to any thread.
I concede there is some value in some cases but there are enough warts on
this to make me cringe about putting it in. (As I cringed with the original
OSX version.)
That's not to say I'm going to oppose it, but I certainly don't champion
it. :)
Cheers,
David

Post by Thomas StÃ¼fe
Hi all,
I'd like to contribute implementations for
os::set_native_thread_name()
on
Windows and Linux. We have added this feature to the SAP JVM and it has
been useful for debugging.
http://cr.openjdk.java.net/~simonis/webrevs/7102541/
https://bugs.openjdk.java.net/browse/JDK-7102541
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
On Linux, it uses pthread_setname_np(2).
- os::set_native_thread_name() only has any effect if there is a debugger
attached to the process at the time of the function call. The reason is
that the debugger must observe the raised exception. This means that this
method works fine if the VM is being debugged right from the start; for
cases where the debugger attaches during VM life, threads started before
the attach will show default names.
- This was tested using Visual Studio 2013 and Windbg.
- pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the
function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg " ps H -p 1234 -o 'pid
tid
comm'
") or with gdb >= 4.7
Note that not all threads show names. os::set_native_thread_name() was only
called for JavaThread* children before this change, this change adds
the
VM
thread, but there are some threads for which this function is not yet
called; they appear with their default names.
---
Note that when I was doing this change, I worked first on
https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that
Gerard Ziemski had done a lot of the same work before. But it looks like
his changes did not appear in the hotspot? Either that or I looked at the
wrong place... Anyway, I hope either his or my changes make it into the
hotspot, because the feature is quite useful.
Kind Regards,
Thomas

Gerard Ziemski

2014-10-10 20:47:37 UTC

Permalink

I'm in the process of reviewing and making sure it all still works on
Mac OS X...

Post by Thomas StÃ¼fe
Thank you all for the positive feedback; I really think the feature would
be useful. Right now I am looking at a core on Linux from a Tomcat run and
it is nice to see the thread names in a list instead of having to manually
go thru all threads and examine the stack to guess at the function.
I agree with David that the solution is not complete, but I think it would
be a step in the right direction. Sure it would be nice to have all
platforms; however, 3 out of 5 is not bad. On AIX, I am investigating
whether we can add the feature some other way.
The limitation to the current thread is not a hard limitation; Linux and
Windows implementations work with other threads too. I did not test Mac OS.
I do not think the restriction on Windows is that bad; it is still helpful.
You want thread names, just run the VM in a debugger from the start on.
I even looked for a way to re-establish thread names after the windows
debugger attaches; but seems to be no way to get informed when a debugger
attaches. Theoretically one could add a function which iterates over all
threads, calling os::set_native_thread_name() on them (provided we make it
work for other threads than the current one), and call that function
manually within the Debugger. But I think that would be over engineered.
As for Linux, I think one could even dynamically probe for the largest
allowed thread name at the start of the VM (calling pthread_setname_np with
ever-smaller names until it stops saying ERANGE). That way we could retain
downward compatibility while still profit from larger names should the
glibc people decide to enlarge that name buffer. But again, that may be
over engineered.
As for missing documentation, this should be already a problem now, as the
function is implemented on one platform and the other platforms are stubbed
out? I don't see how the change would change that.
Thomas
On Fri, Oct 10, 2014 at 5:15 PM, David Holmes <david.holmes at oracle.com>

We should wait for Gerard to catch up with this before any commit is done.
He had also already proposed code changes in the bug report.
We also need to determine where these different platform limitations are
to be documented. Otherwise we will get bug reports (as I'm sure I've
mentioned in previous discussions) regarding missing names (because setName
was not called by the current thread on itself) and duplicate names
(because of the 15 char limit).
On the issue of current thread versus any thread, is pthread_setname_np
restricted to use by the current thread on itself? It is used that way in
this patch, but possibly only to match the restriction that OSX had
introduced. That restriction should be removed on platforms where it can be
removed.
Thanks,
David

Post by David Holmes
Thomas,
I?m happy to see this being worked on and I think the code looks good. We
had similar implementations of this in JRockit and very often found them
useful.
I don?t share David?s concerns. That we can?t do this on solaris is not a
good reason not do it on other platforms. The windows limitation that a
debugger has to be attached is a limitation, but the feature is worth a lot
when you /do/ have a debugger attached. The 15 character limitation is too
bad, but again, better something than nothing.
Thanks,
/Staffan
Hi Thomas,

Post by Thomas StÃ¼fe
Hi all,
I'd like to contribute implementations for
os::set_native_thread_name()
on
Windows and Linux. We have added this feature to the SAP JVM and it has
been useful for debugging.
http://cr.openjdk.java.net/~simonis/webrevs/7102541/
https://bugs.openjdk.java.net/browse/JDK-7102541
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
On Linux, it uses pthread_setname_np(2).
- os::set_native_thread_name() only has any effect if there is a debugger
attached to the process at the time of the function call. The reason is
that the debugger must observe the raised exception. This means that this
method works fine if the VM is being debugged right from the start; for
cases where the debugger attaches during VM life, threads started before
the attach will show default names.
- This was tested using Visual Studio 2013 and Windbg.
- pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the
function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg " ps H -p 1234 -o 'pid
tid
comm'
") or with gdb >= 4.7
Note that not all threads show names. os::set_native_thread_name() was only
called for JavaThread* children before this change, this change adds
the
VM
thread, but there are some threads for which this function is not yet
called; they appear with their default names.
---
Note that when I was doing this change, I worked first on
https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that
Gerard Ziemski had done a lot of the same work before. But it looks like
his changes did not appear in the hotspot? Either that or I looked at the
wrong place... Anyway, I hope either his or my changes make it into the
hotspot, because the feature is quite useful.
Kind Regards,
Thomas

Gerard Ziemski

2014-10-10 22:22:53 UTC

Permalink

hi Thomas.

Thank you very much for your contribution.

With your changes even the Mac OS X platform seems to benefit - we now
get more named threads on Mac (ie. "Thread 13 Java: VM Thread" and
"Thread 24 Java: VM Perdiodic Task Thread"). I do wonder what all those
remainding threads are those, but that's another question...

Please consider this reviewed, though with a small "r".

All we need now is Solaris implementation...

cheers

We should wait for Gerard to catch up with this before any commit is done.
He had also already proposed code changes in the bug report.
We also need to determine where these different platform limitations are
to be documented. Otherwise we will get bug reports (as I'm sure I've
mentioned in previous discussions) regarding missing names (because setName
was not called by the current thread on itself) and duplicate names
(because of the 15 char limit).
On the issue of current thread versus any thread, is pthread_setname_np
restricted to use by the current thread on itself? It is used that way in
this patch, but possibly only to match the restriction that OSX had
introduced. That restriction should be removed on platforms where it can be
removed.
Thanks,
David

Post by David Holmes
Thomas,
I?m happy to see this being worked on and I think the code looks good. We
had similar implementations of this in JRockit and very often found them
useful.
I don?t share David?s concerns. That we can?t do this on solaris is not a
good reason not do it on other platforms. The windows limitation that a
debugger has to be attached is a limitation, but the feature is worth a lot
when you /do/ have a debugger attached. The 15 character limitation is too
bad, but again, better something than nothing.
Thanks,
/Staffan
Hi Thomas,

Post by Thomas StÃ¼fe
Hi all,
I'd like to contribute implementations for
os::set_native_thread_name()
on
Windows and Linux. We have added this feature to the SAP JVM and it has
been useful for debugging.
http://cr.openjdk.java.net/~simonis/webrevs/7102541/
https://bugs.openjdk.java.net/browse/JDK-7102541
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
On Linux, it uses pthread_setname_np(2).
- os::set_native_thread_name() only has any effect if there is a debugger
attached to the process at the time of the function call. The reason is
that the debugger must observe the raised exception. This means that this
method works fine if the VM is being debugged right from the start; for
cases where the debugger attaches during VM life, threads started before
the attach will show default names.
- This was tested using Visual Studio 2013 and Windbg.
- pthread_setname_np(2) needs glibc 2.12 or newer. The change loads the
function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg " ps H -p 1234 -o 'pid
tid
comm'
") or with gdb >= 4.7
Note that not all threads show names. os::set_native_thread_name() was only
called for JavaThread* children before this change, this change adds
the
VM
thread, but there are some threads for which this function is not yet
called; they appear with their default names.
---
Note that when I was doing this change, I worked first on
https://bugs.openjdk.java.net/browse/JDK-8060033, so I was not aware that
Gerard Ziemski had done a lot of the same work before. But it looks like
his changes did not appear in the hotspot? Either that or I looked at the
wrong place... Anyway, I hope either his or my changes make it into the
hotspot, because the feature is quite useful.
Kind Regards,
Thomas

Thomas Stüfe

2014-10-12 08:40:35 UTC

Permalink

On Sat, Oct 11, 2014 at 12:22 AM, Gerard Ziemski <gerard.ziemski at oracle.com>

With your changes even the Mac OS X platform seems to benefit - we now get
more named threads on Mac (ie. "Thread 13 Java: VM Thread" and "Thread 24
Java: VM Perdiodic Task Thread"). I do wonder what all those remainding
threads are those, but that's another question...

I think the primordial thread is missing, the java main thread, NMT worker
thread and of course the n GC threads. They should be easy to add, though.

David Holmes

2014-10-10 22:33:42 UTC

Permalink

Post by Thomas StÃ¼fe
Thank you all for the positive feedback; I really think the feature
would be useful. Right now I am looking at a core on Linux from a Tomcat
run and it is nice to see the thread names in a list instead of having
to manually go thru all threads and examine the stack to guess at the
function.
I agree with David that the solution is not complete, but I think it
would be a step in the right direction. Sure it would be nice to have
all platforms; however, 3 out of 5 is not bad. On AIX, I am
investigating whether we can add the feature some other way.
The limitation to the current thread is not a hard limitation; Linux and
Windows implementations work with other threads too. I did not test Mac OS.
I do not think the restriction on Windows is that bad; it is still
helpful. You want thread names, just run the VM in a debugger from the
start on.
I even looked for a way to re-establish thread names after the windows
debugger attaches; but seems to be no way to get informed when a
debugger attaches. Theoretically one could add a function which iterates
over all threads, calling os::set_native_thread_name() on them (provided
we make it work for other threads than the current one), and call that
function manually within the Debugger. But I think that would be over
engineered.
As for Linux, I think one could even dynamically probe for the largest
allowed thread name at the start of the VM (calling pthread_setname_np
with ever-smaller names until it stops saying ERANGE). That way we could
retain downward compatibility while still profit from larger names
should the glibc people decide to enlarge that name buffer. But again,
that may be over engineered.

This is likely to be a discrete range rather than a continuous one - I
don't expect to find different linux versions each choosing a different
value. My main concern is that some very commonly used threading
libraries will encounter this 15 char limit eg:

ForkJoinPool.commonPool-worker-<N>
pool-<N>-thread-<M>

and custom Executors and FJPools tend to use even longer name.

Post by Thomas StÃ¼fe
As for missing documentation, this should be already a problem now, as
the function is implemented on one platform and the other platforms are
stubbed out? I don't see how the change would change that.

At the moment the missing documentation concerns only one platform. Now
it concerns three platforms that all (potentially) behave differently;
with a fourth and fifth potentially on the way. So I think the
documentation issue needs to resolved.

Thanks,
David

Post by Thomas StÃ¼fe
Thomas
On Fri, Oct 10, 2014 at 5:15 PM, David Holmes <david.holmes at oracle.com
We should wait for Gerard to catch up with this before any commit is
done. He had also already proposed code changes in the bug report.
We also need to determine where these different platform limitations
are to be documented. Otherwise we will get bug reports (as I'm sure
I've mentioned in previous discussions) regarding missing names
(because setName was not called by the current thread on itself) and
duplicate names (because of the 15 char limit).
On the issue of current thread versus any thread, is
pthread_setname_np restricted to use by the current thread on
itself? It is used that way in this patch, but possibly only to
match the restriction that OSX had introduced. That restriction
should be removed on platforms where it can be removed.
Thanks,
David
Hi,
I totally agree with Staffan. This change simply improves the current
situation on Linux and Windows. And it has no drawbacks on other
platforms.
Can somebody please sponsor this change? And please don't forget to
add a "Contributed-by: thomas.stuefe at sap.com
<mailto:thomas.stuefe at sap.com>" as he's no author until
now - but he's covered by the general SAP OCA.
Thank you and best regards,
Volker
On Fri, Oct 10, 2014 at 3:18 PM, Daniel D. Daugherty
<daniel.daugherty at oracle.com
I started this architectural inconsistency when I shepherded in
the os::set_native_thread_name() API with the MacOS X port so
our current state of affairs is that we are inconsistent across
the platforms today.
1) remove os::set_native_thread_name() since it cannot be done
consistently across platforms
2) allow differing implementations of
os::set_native_thread_name()
to be added as they are developed by interested parties
3) define a Lowest-Common-Denominator (LCD) version of the API
and add platform implementations that adhere to the LCD; in
other words, we hobble implementations that can do more for
the sake of consistency
I don't like #1 or #3. I'm OK with #2 and there's precedent for
platform specific limitations, e.g., filename and pathname length
differences between the various platforms...
Dan
Thomas,
I?m happy to see this being worked on and I think the
code looks good. We
had similar implementations of this in JRockit and very
often found them
useful.
I don?t share David?s concerns. That we can?t do this on
solaris is not a
good reason not do it on other platforms. The windows
limitation that a
debugger has to be attached is a limitation, but the
feature is worth a lot
when you /do/ have a debugger attached. The 15 character
limitation is too
bad, but again, better something than nothing.
Thanks,
/Staffan
On 10 okt 2014, at 11:06, David Holmes
<david.holmes at oracle.com
Hi Thomas,
Based on the bug report Gerard's work stalled
because of solaris issues.
We've covered a lot of ground regarding this in the
past. Personally I'm
unhappy about a few things - the windows situations
seem not that useful;
the linux 15 character limit also renders this
useless for many cases. Then
there is the issue of whether this can only be
applied by the current thread
to itself, or by any thread to any thread.
I concede there is some value in some cases but
there are enough warts on
this to make me cringe about putting it in. (As I
cringed with the original
OSX version.)
That's not to say I'm going to oppose it, but I
certainly don't champion
it. :)
Cheers,
David
Hi all,
I'd like to contribute implementations for
os::set_native_thread_name()
on
Windows and Linux. We have added this feature to
the SAP JVM and it has
been useful for debugging.
http://cr.openjdk.java.net/~__simonis/webrevs/7102541/
<http://cr.openjdk.java.net/~simonis/webrevs/7102541/>
https://bugs.openjdk.java.net/__browse/JDK-7102541
<https://bugs.openjdk.java.net/browse/JDK-7102541>
http://msdn.microsoft.com/en-__us/library/xcb2z8hs.aspx
<http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx>
On Linux, it uses pthread_setname_np(2).
- os::set_native_thread_name() only has any
effect if there is a
debugger
attached to the process at the time of the
function call. The reason is
that the debugger must observe the raised
exception. This means that
this
method works fine if the VM is being debugged
right from the start; for
cases where the debugger attaches during VM
life, threads started before
the attach will show default names.
- This was tested using Visual Studio 2013
and Windbg.
- pthread_setname_np(2) needs glibc 2.12 or
newer. The change loads
the
function dynamically.
- Thread names are truncated to 15 characters.
- We can see the thread names with ps (eg "
ps H -p 1234 -o 'pid tid
comm'
") or with gdb >= 4.7
Note that not all threads show names.
os::set_native_thread_name() was
only
called for JavaThread* children before this
change, this change adds the
VM
thread, but there are some threads for which
this function is not yet
called; they appear with their default names.
---
Note that when I was doing this change, I worked
first on
https://bugs.openjdk.java.net/__browse/JDK-8060033
<https://bugs.openjdk.java.net/browse/JDK-8060033>,
so I was not aware
that
Gerard Ziemski had done a lot of the same work
before. But it looks like
his changes did not appear in the hotspot?
Either that or I looked at
the
wrong place... Anyway, I hope either his or my
changes make it into the
hotspot, because the feature is quite useful.
Kind Regards,
Thomas

Thomas Stüfe

2014-10-12 09:15:19 UTC

Permalink

Post by Thomas StÃ¼fe
As for Linux, I think one could even dynamically probe for the largest

Post by Thomas StÃ¼fe
allowed thread name at the start of the VM (calling pthread_setname_np
with ever-smaller names until it stops saying ERANGE). That way we could
retain downward compatibility while still profit from larger names
should the glibc people decide to enlarge that name buffer. But again,
that may be over engineered.

This is likely to be a discrete range rather than a continuous one - I
don't expect to find different linux versions each choosing a different
value.

The same binary could run on both old and new Linux machines with different
task name length limits. It would be nice to have the VM automatically
adapt to future improvements while retaining downward compatibility.

After reading up a bit on Gerards glibc feature request
https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=16578, it
seems that pthread lib on Linux implements thread naming by using kernel
task names; task names are limited by TASK_COMM_LEN. It is possible to
increase that define, but there are bug reports out that increasing
TASK_COMM_LEN caused memory corruptions. So I concede that while it is
possible that the pthread name length may change, it is not probable.

Post by Thomas StÃ¼fe
My main concern is that some very commonly used threading libraries will
ForkJoinPool.commonPool-worker-<N>
pool-<N>-thread-<M>
and custom Executors and FJPools tend to use even longer name.

This is true and you are right. I think the feature is still useful enough,
not so much for java developers but for OpenJDK developers, who are much
more likely to debug natively and for whom a common case is to quickly
identify OpenJDK special threads (Vm Thread, GC threads etc) in a forest of
common java threads.

It is also useful for cases where the libjvm.so is embedded into another
launcher as "just another library", and you want to tell apart jvm threads
from threads which have nothing to do with the jvm.

Post by Thomas StÃ¼fe
As for missing documentation, this should be already a problem now, as

Post by Thomas StÃ¼fe
the function is implemented on one platform and the other platforms are
stubbed out? I don't see how the change would change that.

At the moment the missing documentation concerns only one platform. Now it
concerns three platforms that all (potentially) behave differently; with a
fourth and fifth potentially on the way. So I think the documentation issue
needs to resolved.

I agree with you and if you tell me the format and/or where to put it, I
can write a short documentation.

Thanks, Thomas

David Holmes

2014-10-13 00:19:24 UTC

Permalink

Post by Thomas StÃ¼fe
As for Linux, I think one could even dynamically probe for the largest
allowed thread name at the start of the VM (calling
pthread_setname_np
with ever-smaller names until it stops saying ERANGE). That way we could
retain downward compatibility while still profit from larger names
should the glibc people decide to enlarge that name buffer. But again,
that may be over engineered.
This is likely to be a discrete range rather than a continuous one -
I don't expect to find different linux versions each choosing a
different value.
The same binary could run on both old and new Linux machines with
different task name length limits. It would be nice to have the VM
automatically adapt to future improvements while retaining downward
compatibility.
After reading up a bit on Gerards glibc feature request
https://sourceware.org/bugzilla/show_bug.cgi?format=multiple&id=16578,
it seems that pthread lib on Linux implements thread naming by using
kernel task names; task names are limited by TASK_COMM_LEN. It is
possible to increase that define, but there are bug reports out that
increasing TASK_COMM_LEN caused memory corruptions. So I concede that
while it is possible that the pthread name length may change, it is not
probable.
My main concern is that some very commonly used threading libraries
ForkJoinPool.commonPool-__worker-<N>
pool-<N>-thread-<M>
and custom Executors and FJPools tend to use even longer name.
This is true and you are right. I think the feature is still useful
enough, not so much for java developers but for OpenJDK developers, who
are much more likely to debug natively and for whom a common case is to
quickly identify OpenJDK special threads (Vm Thread, GC threads etc) in
a forest of common java threads.
It is also useful for cases where the libjvm.so is embedded into another
launcher as "just another library", and you want to tell apart jvm
threads from threads which have nothing to do with the jvm.
As for missing documentation, this should be already a problem now, as
the function is implemented on one platform and the other platforms are
stubbed out? I don't see how the change would change that.
At the moment the missing documentation concerns only one platform.
Now it concerns three platforms that all (potentially) behave
differently; with a fourth and fifth potentially on the way. So I
think the documentation issue needs to resolved.
I agree with you and if you tell me the format and/or where to put it, I
can write a short documentation.

I would like to see a release note entry; though that is an Oracle
specific entity :( Not sure where else this can be readily documented -
suggestions welcome.

Thanks,
David

Post by Thomas StÃ¼fe
Thanks, Thomas

Staffan Larsen

2014-10-13 15:51:33 UTC

Permalink

I?ve tagged the bug to add a release note - just need to provide the text for it.

Thomas: I can sponsor the fix if you send me a ?hg export? changeset with the correct check-in comments.

Thanks,
/Staffan

I would like to see a release note entry; though that is an Oracle specific entity :( Not sure where else this can be readily documented - suggestions welcome.
Thanks,
David

Post by Thomas StÃ¼fe
Thanks, Thomas