[PATCH] Linux implementation for set_native_thread_name()

David Holmes david.holmes at oracle.com
Thu Jul 26 05:41:49 PDT 2012

On 26/07/2012 10:18 PM, Roman Kennke wrote:
> Am Donnerstag, den 26.07.2012, 22:00 +1000 schrieb David Holmes:
>> Roman,
>> On 25/07/2012 7:10 AM, Roman Kennke wrote:
>>>> I think it looks fine.
>>> Great! I posted an updated webrev for this (replaced snprint with
>>> jio_snprintf):
>> You are assuming that these non-posix pthread extensions will always
>> exist. Do we know that is true for all Linux's - including potentially
>> custom distributions on embedded systems? I think we need dynamic lookup
>> of the function, as done elsewhere, to verify that it exists.
> Do you mean at runtime, using dlopen or such? Or at compile time, using
> #ifdefs ?

Runtime using dlsym, the same way we look for the "optional" POSIX 
functions like clock_gettime. The support for this in linux/libc is very 
recent (in OS terms):


You might also follow the BSD version and add a Java prefix:

   if (name != NULL) {
     // Add a "Java: " prefix to the name
     snprintf(buf, sizeof(buf), "Java: %s", name);

though that concerns me if MAXTHREADNAMESIZE is only 16!

Can you tell me where this max name size is coming from? I can google 
different docs for pthread_setname_np and some say it internally limits 
the name length, while others say if the name is too long it gives an 
E2BIG error. The source code at


does not set a specific limit on the length but will return a error if 
it can't write the full name. In contrast the cygwin version:


sets a limit of 16(actually 15 characters plus NUL) and returns ERANGE.

This is why we try to stay away from the ill-defined _np functions.


>>> http://cr.openjdk.java.net/~rkennke/linux_threadname/webrev.01/
>> This also has the distribute_processes etc changes, which should be
>> handled seperately.
> Uff. I messed up something there. Please find the real webrev here:
> http://cr.openjdk.java.net/~rkennke/linux_threadname/webrev.02/
>>>> Do you have a bug number for this?
>>> No. (I don't have access to bugster anymore).
>> Bugster is nearly dead - long live Jira :)
> Wow, cool!
>>   But for now someone will need
>> to create a bug for this ... though it may already exist from when this
>> function was added.
>>>>     Also, how do we verify the result?
>>> I verified it using htop and by inspecting /proc/$PID/task/$TID/stat.
>>> Unfortuntately, I couldn't get top or ps to show the thread name, but
>>> maybe I'm just stupid (and I did not try very hard).
>> gdb? Not sure how this shows up on OSX. If the name doesn't appear in
>> anything useful then there's not much point implementing the method.
> Yes, gdb shows the thread name as well (dunno why I forgot about this
> most obvious use case).
>>> Also: which of the many repositories do I need to push this to?
>> It would go into hsx/hotspot-rt forest, but you can't push it directly.
>> All hotspot changes must go via JPRT so you will need a sponsor.
> Ok. I think Keith said he can do this. :-)
> Thanks!
> Regards,
> Roman

More information about the hotspot-dev mailing list