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

[David Holmes]

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

On 10/10/2014 11:58 PM, Volker Simonis wrote:
> 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
> <daniel.daugherty at oracle.com> wrote:
>> 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
>>>>>
>>