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

james cheng james.cheng at oracle.com
Wed Mar 16 22:54:15 UTC 2016


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().

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


More information about the hotspot-runtime-dev mailing list