[PATCH] Linux implementation for set_native_thread_name() (original) (raw)

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 jiosnprintf): 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):

http://sourceware.org/ml/libc-help/2010-03/msg00015.html

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

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

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

http://sourceware.org/ml/libc-help/2010-03/msg00015.html

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:

http://www.mail-archive.com/cygwin-patches@cygwin.com/msg05387.html

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.

David

http://cr.openjdk.java.net/~rkennke/linuxthreadname/webrev.01/ This also has the distributeprocesses 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/linuxthreadname/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