RFR (S): 8151322: Implement os::set_native_thread_name() on Solaris

[Gerard Ziemski]

David,

If we were to move the initialization code off the startup path, we wouldn’t need to bother with this optimization.

I’m in favor of “defer until needed”, as I suggested earlier, as opposed to the “eagerly initialize” approach taken here.


cheers

> On Mar 16, 2016, at 8:43 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi James,
> 
> On 17/03/2016 8:54 AM, james cheng wrote:
>> Hi David,
>> 
>> Thanks for implementing this RFE.
>> 
>> A Solaris Linker guru suggested what we do something like this:
>> 
>>     my_pthread_setname_np(...)
>>     {
>>     static    (*fptr)() = NULL;
>>     void    *handle;
>> 
>>     if ((fptr == NULL) &&
>>         ((handle = dlopen("libc.so.1", RTLD_LAZY)) != NULL) &&
>>         ((fptr = dlsym(handle, "pthread_setname_np")) == NULL))
>>         fptr = noop_setname;
>> 
>>     (*fptr)(...);
>>     }
>> 
>> So using libc.so.1 without a path should be okay.  But I don't see you have
>> a null check for the return of dlsym().
> 
> We initialize _pthread_setname_np using dlopen+dlsym as above at VM startup - we don't want to do the lookup on each use. The NULL check happens in the actual os::set_native_thread_name() function.
> 
> Glad to hear using the libc.so.1 path is okay (as we already use it) but was wondering if we can assume /usr/lib/libc.so.1 and so shorten the search time even further?
> 
> Thanks,
> David
> 
>> 
>> Thanks,
>> -James
>> 
>> On 3/15/2016 9:24 PM, David Holmes wrote:
>>> cc'ing James as initial requestor for this.
>>> 
>>> On 16/03/2016 7:49 AM, Gerard Ziemski wrote:
>>>> 
>>>>> On Mar 15, 2016, at 4:31 PM, David Holmes <david.holmes at oracle.com>
>>>>> wrote:
>>>>> 
>>>>>> Couldn’t we look it up on as needed basis in the implementation of
>>>>>> "void os::set_native_thread_name(const char *name)” instead?
>>>>> 
>>>>> AFAIK we never lookup anything as-needed but always handle it at VM
>>>>> initialization time. A quick grep will show that we are using
>>>>> RTLD_DEFAULT in a few places across
>>>>> different platforms. Elsewhere we know what library we have to
>>>>> search. I can try finding out which library it should be if you
>>>>> think that is preferable?
>>>> 
>>>> Sure, either that or we find out the performance impact on the
>>>> startup time, so then we can decide if it’s an issue or not.
>>> 
>>> Some numbers in the bug report. It seems to me if we know the library
>>> that will contain the symbol then we should just open it. I filed a RFE:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8151953
>>> 
>>> to look at use of RTLD_DEFAULT in general.
>>> 
>>> Updated webrev: http://cr.openjdk.java.net/~dholmes/8151322/webrev.v2/
>>> 
>>> Not 100% sure whether dlopen should be also relying on the search path
>>> dlopen("libc.so.1",...) - or whether the absolute /usr/lib/libc.so.1
>>> should be hard-wired? I'm not
>>> familiar enough with solaris library management to know whether we
>>> will always find libc on that exact path? We have one existing
>>> /usr/lib/libc.so.1 dlopen on Solaris x86,
>>> but most dlopens just take the base name.
>>> 
>>> Thanks,
>>> David
>>> -----
>>> 
>>>> 
>>>> thanks