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

[David Holmes]

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
>