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

[Christian Tornqvist]

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

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