RFR: 8238649: Call new Win32 API SetThreadDescription in os::set_native_thread_name

[David Holmes]

On 11/06/2021 6:31 pm, Ludovic Henry wrote:
> On Wed, 2 Jun 2021 02:19:52 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>  From Windows 10 and Windows 2016 server, we have a direct API for setting the thread name/description. Use of this API was suggested by Markus Gaisbauer:
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030366.html
>>
>> Using the new API was quite straight forward, but verifying that it had worked correctly was far more challenging. It seems there are no tools that use the new GetThreadDescription API to display thread names, so no easy check that this had worked. While Visual Studio will use it, it also uses the old debugger mechanism, so we wouldn't be able to tell the difference.
>>
>> Writing a Windows-only test was one possibility, but the conversion to/from Unicode and java.lang.String would make that test very cumbersome in itself (for something that should be trivial!).
>>
>> So instead for debug builds I read back the thread name using GetThreadDescription and check that the name we set and the name we read are the same. I'm a bit concerned about the impact this may have on performance so I'm going to run some benchmarks.
>>
>> I will also run benchmarks to watch for issues with the unicode conversion costs related to this.
>>
>> The logging strategy is as follows:
>> - info: show whether the new API is available or not
>> - debug: report failures that are ignored (as we fallback to debugger mechanism)
>> - trace: report successes for full tracking
>>
>> Testing:
>>    - internal self-verification in debug builds as previously described
>>   - verified the logging output on different Windows systems that have, and don't have, the new API
>>   - sanity testing for tiers 1-3
>>
>> Thanks,
>> David
> 
> Looks good.

Thanks for reviewing it!

> 
> src/hotspot/os/windows/os_windows.cpp line 4372:
> 
>> 4370:   // Lookup SetThreadDescription - the docs state we must use runtime-linking of
>> 4371:   // kernelbase.dll, so that is what we do.
>> 4372:   HINSTANCE _kernelbase = LoadLibrary(TEXT("kernelbase.dll"));
> 
> `kernel32.dll` would be the better dll to look into (per https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription and the .NET source code).

Those docs state:

"Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: 
SetThreadDescription is only available by Run Time Dynamic Linking in 
KernelBase.dll."

so if I use kernel32 does that mean it will fail on the above Windows 
versions? Is this suggesting I need to use a different dll depending on 
the actual Windows version?

Thanks,
David

> -------------
> 
> Marked as reviewed by luhenry (Author).
> 
> PR: https://git.openjdk.java.net/jdk/pull/4297
>