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

[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>
wrote:

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