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

[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.

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


On 10/10/14 4:54 AM, Staffan Larsen wrote:
> 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> wrote:
>
>> 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
>>
>> On 10/10/2014 6:38 PM, Thomas Stüfe wrote:
>>> 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
>>>