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

Fri Oct 10 22:22:53 UTC 2014

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

On 10/10/2014 11:46 AM, Thomas Stüfe wrote:
> 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
>>>>>>>
>>>>>>>
>