JDK-7102541 : RFE: os::set_native_thread_name() cleanups
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs23
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-10-19
  • Updated: 2019-05-17
  • Resolved: 2014-10-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9 Other
9 b37Fixed openjdk8u222Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8175078 :  
Description
The MacOS X Port project used the following changeset for the initial
push from macosx-port/hotspot -> HSX-23:

    http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/436b4a3231bf

    7098194: integrate macosx-port changes

and that changeset includes a new method for setting a native thread
name.


David H made the following code review comment:

On 10/11/11 10:48 PM, David Holmes wrote:
>
> src/os/<os>/vm/os_<os>.cpp
>
> + void os::set_native_thread_name(const char *name) {
> +   // Not yet implemented.
> +   return;
> + }
>
> I hate seeing "shared" code that is not implemented on 3 out of
> 4 supported platforms. Though it seems Linux will also support
> pthread_setname_np as of March 2010 (not sure which kernel or
> glibc versions needed). If not for the fact this also adds an
> exported JVM method to set the native thread name, we could
> otherwise bury this in the platform specific native thread
> creation code (which might also obviate the need for the new
> _is_attached logic - see next point). I also wonder what Java
> code is using this new JVM API?
>
> Also wondering where the "current thread only" restriction came about? 


My replies (guesses) to David H:

> I suspect that this new API is used by other pieces of the MacOS X
> port project, but I don't know that for sure. Again, we need an
> Apple person to jump in here. 
> 
> If the API is restricted to the "current thread", then we don't have
> to worry about races and locking. Also, I'm wondering why there is no
> return code.


Here is a reply from Roger H:

On 10/12/11 12:34 PM, roger hoover wrote:
> The native thread name addition was a huge win, both for us
> debugging and for our developer customers.  The only complaint
> we had was from other projects whose code attached to Java and
> (in initial revisions) had their threads renamed.  It is exported
> so that Thread.java can set the native thread name.
>
> I have no explanation for the lack of a return code.  I can only
> surmise that it is an oversight that was not caught by the compiler.
>
> The other pieces are:
> macosx-port/jdk/src/share/native/java/lang/Thread.c:
>     {"getThreads",        "()[" THD,   (void *)&JVM_GetAllThreads},
>     {"dumpThreads",      "([" THD ")[[" STE, (void *)&JVM_DumpThreads},
> -->    {"setNativeName",    "(" STR ")V", (void *)&JVM_SetNativeThreadName},
> };
> -and-
> macosx-port/jdk/src/share/classes/java/lang/Thread.java
>     /**
>      * Changes the name of this thread to be equal to the argument
>      * <code>name</code>.
>      * <p>
>      * First the <code>checkAccess</code> method of this thread is called
>      * with no arguments. This may result in throwing a
>      * <code>SecurityException</code>.
>      *
>      * @param      name   the new name for this thread.
>      * @exception  SecurityException  if the current thread cannot modify this
>      *               thread.
>      * @see        #getName
>      * @see        #checkAccess()
>      */
>     public final void setName(String name) {
>         checkAccess();
>         this.name = name.toCharArray();
> -->        if (threadStatus != 0) {
> -->            setNativeName(name);
> -->        }
>     }


Here is a reply from Paul H on the thread:

On 10/12/11 2:56 PM, Paul Hohensee wrote:
> If set_native_thread_name() is an implementation of an extension to Thread,
> then I'd recommend leaving it and the supporting code out (and there's a lot of
> it, vis jvm.cpp as you point out) until the core libs people figure out how
> they want to handle it.  Maybe file an RFE for the work. 


My reply to Paul H:

On 10/12/11 4:33 PM, Daniel D. Daugherty wrote:
> If I remove that support, then I won't be able to use the resulting
> VM with the rest of the macosx-port forest, right? Part of my
> bring up strategy relies on my being able to use the HSX-23 port
> bits with the rest of the macosx-port built bits... 


Another comment from Paul H:

> True.  But it may not be used in it's current form. 


And my reply about it being used:

On 10/12/11 4:53 PM, Daniel D. Daugherty wrote:
> I think it is:
>
> jdk/src/share/javavm/export/jvm.h:JVM_SetNativeThreadName(JNIEnv *env, jobject jthread, jstring name);
> jdk/src/share/native/java/lang/Thread.c:    {"setNativeName",    "(" STR ")V", (void *)&JVM_SetNativeThreadName},
> jdk/src/share/classes/java/lang/Thread.java:            setNativeName(name);
> jdk/src/share/classes/java/lang/Thread.java:    private native void setNativeName(String name); 


Tom R's addition to the thread:

On 10/12/11 5:39 PM, Tom Rodriguez wrote:
> The important point is that it doesn't expose any new API.
> It's just a side effect of calling the regular setName.
>
> I was a bit dubious about its utility so I googled
> pthread_setname_np and found out it allows debuggers to report
> useful names for threads instead of just the thread number.
> On linux it's even accessible through /proc.  Presumably the
> mac does something similar.  It seems like a fairly cool
> feature.  We might want to do it on linux as well and maybe
> even put proper names on our internal threads (eventually).


And Roger H's reply to Tom:

On 10/12/11 5:49 PM, roger hoover wrote:
> It makes a big difference.  gdb tells you what the threads are,
> and we get that info as well in native crash dumps.  Here is a
> snippet from a crash dump on our jdk6 implementation.  This also
> helps JNI developers because they can understand in which thread
> their code is crashing:
>
> Thread 14:  Java: VM Thread
> 0   libSystem.B.dylib             	0x00007fff802abd7a mach_msg_trap + 10
> 1   libSystem.B.dylib             	0x00007fff802ac3ed mach_msg + 59
> 2   libclient64.dylib             	0x000000010100d8f5 jio_snprintf + 37807
> 3   libclient64.dylib             	0x000000010102c4aa jio_vsnprintf + 26334
> 4   libclient64.dylib             	0x000000010100d25d jio_snprintf + 36119
> 5   libclient64.dylib             	0x000000010100d103 jio_snprintf + 35773
> 6   libclient64.dylib             	0x00000001010a3ef7 JVM_Lseek + 188645
> 7   libclient64.dylib             	0x00000001010a3c47 JVM_Lseek + 187957
> 8   libclient64.dylib             	0x000000010100d1c4 jio_snprintf + 35966
> 9   libSystem.B.dylib             	0x00007fff802e4fd6 _pthread_start + 331
> 10  libSystem.B.dylib             	0x00007fff802e4e89 thread_start + 13
>
> Thread 15:  Java: Reference Handler
> 0   libSystem.B.dylib             	0x00007fff802abd7a mach_msg_trap + 10
> 1   libSystem.B.dylib             	0x00007fff802ac3ed mach_msg + 59
> 2   libclient64.dylib             	0x000000010100d863 jio_snprintf + 37661
> 3   libclient64.dylib             	0x000000010100d723 jio_snprintf + 37341
> 4   libclient64.dylib             	0x00000001010b24ff JVM_MonitorWait + 3999
> 5   libclient64.dylib             	0x00000001010b198c JVM_MonitorWait + 1068
> 6   libclient64.dylib             	0x00000001010b15fa JVM_MonitorWait + 154
> 7   libjvmlinkage.dylib           	0x0000000100093b9b JVM_MonitorWait + 59
> 8   ???                           	0x0000000104011d6e 0 + 4362149230
> 9   ???                           	0x000000010400685a 0 + 4362102874
> 10  ???                           	0x000000010400685a 0 + 4362102874
> 11  ???                           	0x0000000104001438 0 + 4362081336
> 12  libclient64.dylib             	0x00000001010a50ba JVM_Lseek + 193192
> 13  libclient64.dylib             	0x00000001010b1148 JVM_StartThread + 2565
> 14  libclient64.dylib             	0x00000001010b103e JVM_StartThread + 2299
> 15  libclient64.dylib             	0x00000001010b0fde JVM_StartThread + 2203
> 16  libclient64.dylib             	0x00000001010b0e80 JVM_StartThread + 1853
> 17  libclient64.dylib             	0x00000001010b0c95 JVM_StartThread + 1362
> 18  libclient64.dylib             	0x000000010100d1c4 jio_snprintf + 35966
> 19  libSystem.B.dylib             	0x00007fff802e4fd6 _pthread_start + 331
> 20  libSystem.B.dylib             	0x00007fff802e4e89 thread_start + 13
>
> Thread 16:  Java: Finalizer
> 0   libSystem.B.dylib             	0x00007fff802abd7a mach_msg_trap + 10
> 1   libSystem.B.dylib             	0x00007fff802ac3ed mach_msg + 59
> 2   libclient64.dylib             	0x000000010100d863 jio_snprintf + 37661
> 3   libclient64.dylib             	0x000000010100d723 jio_snprintf + 37341
> 4   libclient64.dylib             	0x00000001010b24ff JVM_MonitorWait + 3999
> 5   libclient64.dylib             	0x00000001010b198c JVM_MonitorWait + 1068
> 6   libclient64.dylib             	0x00000001010b15fa JVM_MonitorWait + 154
> 7   libjvmlinkage.dylib           	0x0000000100093b9b JVM_MonitorWait + 59
> 8   ???                           	0x0000000104011d6e 0 + 4362149230
> 9   ???                           	0x000000010400685a 0 + 4362102874
> 10  ???                           	0x00000001040069b3 0 + 4362103219
> 11  ???                           	0x00000001040069b3 0 + 4362103219
> 12  ???                           	0x0000000104001438 0 + 4362081336
> 13  libclient64.dylib             	0x00000001010a50ba JVM_Lseek + 193192
> 14  libclient64.dylib             	0x00000001010b1148 JVM_StartThread + 2565
> 15  libclient64.dylib             	0x00000001010b103e JVM_StartThread + 2299
> 16  libclient64.dylib             	0x00000001010b0fde JVM_StartThread + 2203
> 17  libclient64.dylib             	0x00000001010b0e80 JVM_StartThread + 1853
> 18  libclient64.dylib             	0x00000001010b0c95 JVM_StartThread + 1362
> 19  libclient64.dylib             	0x000000010100d1c4 jio_snprintf + 35966
> 20  libSystem.B.dylib             	0x00007fff802e4fd6 _pthread_start + 331
> 21  libSystem.B.dylib             	0x00007fff802e4e89 thread_start + 13
>
> Thread 17:  Dispatch queue: com.apple.libdispatch-manager


And another comment from David H:

On 10/12/11 7:59 PM, David Holmes wrote:
> - set_native_thread_name:
>
> Ok so I have to go back to earlier emails here. Makes sense that
> Thread.setName is augmented to call JVM_SetNativeThreadName.
> However I don't like the semantics of this particular addition.
> setName has no usage restrictions on it, but set_native_thread_name
> is a no-op unless called by the current thread. By restricting it
> to the current thread it simplifies synchronization logic, but it
> seems a somewhat arbitrary restriction in terms of the functionality,
> given the more general nature of the setName API. I guess this is
> Yet Another RFE: set_native_thread_name should not be restricted
> to only the current thread.
>
> BTW: are the JDK changes associated with this also being pushed at
> some stage? If so are the hotspot changes being pushed first? 


My replies to David H:

On 10/13/11 8:07 AM, Daniel D. Daugherty wrote:
>> I guess this is Yet Another RFE: set_native_thread_name should not
>> be restricted to only the current thread.
>
> We definitely need to get some clarity about the addition of
> JVM_SetNativeThreadName(). I'm not fond of APIs without return
> values so that's one thing to log in the new bug. The "must be
> current thread" semantic should also be hashed out/clarified.
>
> Like any API between the JDK and HotSpot, changing it will be a
> pain and require coordination.
>
>> BTW: are the JDK changes associated with this also being pushed at some stage?
>
> Yes, but the exact process has not been finalized. Since there
> are changes being made/coordinated by multiple teams, I'm not
> sure which JDK8 sub-repos will be used.
>
>
>> If so are the hotspot changes being pushed first?
>
> I'm planning to push this changeset to RT_Baseline today.

Comments
Fix Request jdk8u. We at Amazon have found this patch very useful for debugging. Patch applies cleanly net of line numbers.
13-05-2019

See discussion: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-October/015528.html to understand where this RFE ended up. There is no Solaris support at present. The details of which platforms are supported and what constraints there are are to be written up as a release note.
14-10-2014

Stopping work until I figure out how to get stable Solaris 12 running to develop the fix on.
25-02-2014

According to comments in https://sourceware.org/bugzilla/show_bug.cgi?id=16578 the limit of string in pthread_setname_np() is controlled by TASK_COMM_LEN. Looking through Linux emails on the size of TASK_COMM_LEN, it seems unlikely that it will be increased any time soon, which is a sentiment shared in the glib issue comment.
17-02-2014

Filed https://sourceware.org/bugzilla/show_bug.cgi?id=16579 asking for MAXTHREADNAMESIZE definition on Linux.
13-02-2014

Filed https://sourceware.org/bugzilla/show_bug.cgi?id=16578 asking to increase the limit of strings allowed on Linux from 16 to something longer.
13-02-2014

Lookup could/should happen during VM initialization as we do for other pthread functions.
13-02-2014

Timings taken while running Java2D: Time cost of the 1st call to os::set_native_thread_name is called: - Linux: 49,246 nanoseconds (we need to dynamically lookup pthread_setname_np() the 1st time we call it) - Mac: 7,000 nanoseconds Total cost of os::set_native_thread_name (24 threads): - Linux: 370,541 nanoseconds (0.370541 milliseconds) - Mac: 162,000 nanoseconds (0.162 milliseconds) So it looks like the cost is acceptable on both platforms.
12-02-2014

With the following implementation on Linux we have working named native threads, though they show concatenated in gdb as expected to 15 chars: gerard@Ubuntu13:~/Desktop/work/jdk9/hotspot$ hg diff diff -r 50bb249de889 src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp Tue Jan 21 16:45:10 2014 -0600 +++ b/src/os/linux/vm/os_linux.cpp Wed Feb 12 16:27:56 2014 -0600 @@ -109,6 +109,8 @@ #define MAX_PATH (2 * K) +#define MAXTHREADNAMESIZE 16 + // for timer info max values which include all bits #define ALL_64_BITS CONST64(0xFFFFFFFFFFFFFFFF) @@ -5000,8 +5002,18 @@ } void os::set_native_thread_name(const char *name) { - // Not yet implemented. - return; + typedef int (*pthread_setname_np_func)(pthread_t, const char*); + static int looked_up = 0; + static pthread_setname_np_func _pthread_setname_np = NULL; + if (looked_up == 0) { + looked_up = 1; + _pthread_setname_np = CAST_TO_FN_PTR(pthread_setname_np_func, os::dll_lookup(RTLD_DEFAULT, "pthread_setname_np")); + } + if (_pthread_setname_np != NULL) { + char buf[MAXTHREADNAMESIZE]; + snprintf(buf, sizeof(buf), "%s", name); + _pthread_setname_np(pthread_self(), buf); + } } bool os::distribute_processes(uint length, uint* distribution) {
12-02-2014

Filed an issue with GDB asking for the custom thread names to show in the back trace: https://sourceware.org/bugzilla/show_bug.cgi?id=16568
12-02-2014

It took me a while to figure this out, but gdb on Linux behaves a bit different than lldb on Mac, and "t a a bt" will display back traces of all threads, but without their custom names: (gdb) t a a bt Thread 2 (Thread 0x7ffff6fd6700 (LWP 4192)): #0 0x00007ffff73c771d in write () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff7355243 in _IO_new_file_write (f=0x7ffff769d1a0 <_IO_2_1_stderr_>, data=<optimized out>, n=9) at fileops.c:1262 #2 0x00007ffff7355122 in new_do_write (fp=fp@entry=0x7ffff769d1a0 <_IO_2_1_stderr_>, data=data@entry=0x7ffff6fd3720 "err00: 0\n", to_do=to_do@entry=9) at fileops.c:538 #3 0x00007ffff7355b9e in _IO_new_file_xsputn (n=9, data=<optimized out>, f=0x7ffff769d1a0 <_IO_2_1_stderr_>) at fileops.c:1346 #4 _IO_new_file_xsputn (f=0x7ffff769d1a0 <_IO_2_1_stderr_>, data=<optimized out>, n=9) at fileops.c:1278 #5 0x00007ffff7329c94 in buffered_vfprintf (s=s@entry=0x7ffff769d1a0 <_IO_2_1_stderr_>, format=format@entry=0x400cea "err00: %d\n", args=args@entry=0x7ffff6fd5da8) at vfprintf.c:2362 #6 0x00007ffff732497e in _IO_vfprintf_internal (s=0x7ffff769d1a0 <_IO_2_1_stderr_>, format=0x400cea "err00: %d\n", ap=ap@entry=0x7ffff6fd5da8) at vfprintf.c:1307 #7 0x00007ffff732ef57 in __fprintf (stream=<optimized out>, format=<optimized out>) at fprintf.c:32 #8 0x0000000000400a3a in print_message (arg=0x0) at main.cpp:12 #9 0x00007ffff7bc4f6e in start_thread (arg=0x7ffff6fd6700) at pthread_create.c:311 #10 0x00007ffff73d59cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Thread 1 (Thread 0x7ffff7fe0740 (LWP 4188)): #0 0x0000000000400bee in main (argc=1, argv=0x7fffffffdf58) at main.cpp:51 Only "info threads" will: (gdb) info threads Id Target Id Frame 2 Thread 0x7ffff6fd6700 (LWP 4192) "KITTY" 0x00007ffff73c771d in write () at ../sysdeps/unix/syscall-template.S:81 * 1 Thread 0x7ffff7fe0740 (LWP 4188) "HELLO" 0x0000000000400bee in main (argc=1, argv=0x7fffffffdf58) at main.cpp:51 ie. we see 2 threads named "HELLO" and "KITTY" using pthread_setname_np() API That, in itself makes the native threads names a bit less useful on Linux, in my opinion. It would be nice if gdb displayed threads' names in "t a a bt" output, similar to lldb when issued corresponding "bt all" command.
11-02-2014

On Solaris according to man page: Standard C Library Functions pthread_attr_init(3C) The pthread_attr_init() function initializes a thread attri- butes object ( attr) with the default value for each attri- bute as follows: Attribute Default Value Meaning of Default _______________________________________________________________________________________ contentionscope PTHREAD_SCOPE_PROCESS resource competition within process detachstate PTHREAD_CREATE_JOINABLE joinable by other threads stackaddr NULL stack allocated by system stacksize 0 1 or 2 megabyte priority 0 priority of the thread policy SCHED_OTHER traditional time-sharing policy inheritsched PTHREAD_INHERIT_SCHED scheduling policy and parameters are inherited from the creating thread guardsize PAGESIZE size of guard area for a thread's created stack threadname NULL string to be associated with this thread ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ so if the thread name is available at the construction time, we're good.
10-02-2014

Filed an issue with Apple (bugid: 16025890) at https://bugreport.apple.com asking to enhance the pthread_setname_np API, so that it can be called from any thread, like on Linux OS.
10-02-2014

Here is an example of a list of threads running the Java2D.jar app on Mac OS X: thread #1: tid = 0x2cb14b, 0x00007fff8b9c2a1a libsystem_kernel.dylib`mach_msg_trap + 10, name = 'AppKit Thread, queue = 'com.apple.main-thread, stop reason = signal SIGSTOP thread #2: tid = 0x2cb14c, 0x00007fff8b9c6a3a libsystem_kernel.dylib`__semwait_signal + 10 thread #3: tid = 0x2cb14d, 0x00007fff8b9c7662 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager thread #4: tid = 0x2cb150, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #5: tid = 0x2cb151, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #6: tid = 0x2cb152, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #7: tid = 0x2cb153, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #8: tid = 0x2cb154, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #9: tid = 0x2cb155, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #10: tid = 0x2cb156, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #11: tid = 0x2cb157, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #12: tid = 0x2cb158, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #13: tid = 0x2cb15a, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #14: tid = 0x2cb15b, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: Reference Handler thread #15: tid = 0x2cb15c, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: Finalizer thread #16: tid = 0x2cb15d, 0x00007fff8b9c6e6a libsystem_kernel.dylib`__workq_kernreturn + 10 thread #17: tid = 0x2cb163, 0x00007fff8b9c2a56 libsystem_kernel.dylib`semaphore_wait_trap + 10, name = 'Java: Signal Dispatcher thread #18: tid = 0x2cb164, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: C2 CompilerThread0 thread #19: tid = 0x2cb165, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: C2 CompilerThread1 thread #20: tid = 0x2cb166, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: C2 CompilerThread2 thread #21: tid = 0x2cb167, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: C1 CompilerThread3 thread #22: tid = 0x2cb168, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: Service Thread thread #23: tid = 0x2cb169, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10 thread #24: tid = 0x2cb180, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: AWT-Shutdown thread #25: tid = 0x2cb18e, 0x00007fff8b9c2a1a libsystem_kernel.dylib`mach_msg_trap + 10 thread #26: tid = 0x2cb191, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: Java2D Queue Flusher thread #27: tid = 0x2cb195, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: Java2D Disposer thread #28: tid = 0x2cb1a3, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: AWT-EventQueue-0 thread #29: tid = 0x2cb1ec, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: TimerQueue thread #30: tid = 0x2cb1ee, 0x00007fff8b9c6716 libsystem_kernel.dylib`__psynch_cvwait + 10, name = 'Java: Intro Taking into account the 16 character limit on Linux OS: "Java: Java2D Queue Flusher" reduces to "Java: Java2D Qu" or "Java2D Queue Fl" if we drop the "Java: " prefix. "'Java: C2 CompilerThread0" reduces to "Java: C2 Compil", or "C2 CompilerThre" if we drop the "Java: " prefix. so on Linux we need to drop the "Java: " prefix and shorten from the end if we want to end with unique names: "Reference Handler" --> "ference Handler" "Signal Dispatcher" --> "gnal Dispatcher" "C2 CompilerThread0" --> "CompilerThread0" "Java2D Queue Flusher" --> "D Queue Flusher" "AWT-EventQueue-0" --> "WT-EventQueue-0" We might need to modify the places where we use the API internally and drop the "Java: " prefix and also get creative with the names: "Reference Handler" --> "ReferenceHandlr" "Signal Dispatcher" --> "SignalDispatchr" "C2 CompilerThread0" --> "C2 CompilerT0" "C2 CompilerThread1" --> "C2 CompilerT1" "C2 CompilerThread2" --> "C2 CompilerT2" "C1 CompilerThread3" --> "C1 CompilerT3" "Java2D Queue Flusher" --> "Java2DQueFlushr" "AWT-EventQueue-0" --> "AWT-EventQueue0" Lastly, we may want to insert debug assert that checks the length of the thread name and triggers the assert to let ourselves know when the thread name can not be set as requested due to limited string length. For now we can intercept all the calls in os::set_native_thread_name() and check for these hardcoded thread names, and if we need to modify the names on the fly, then we should print out some warning to std err (only in debug build) to let the users know, they need to modify the names themselves.
10-02-2014

pthread_setname_np(const char* string) on Mac OS X has a limit of 64 characters, including the terminating null byte.
07-02-2014

The setter function is needed for the Java code to pass through the name change to the VM. The Java code does not need to query the native name (which may not even exist). In a generic sense "yes a test would want to check that what was written can be read back" however: a) the API would have to be private and thus not accessible to the test anyway; else it would need formal approval and I for one would not support adding it b) the OS may constrain the length of the native thread name and/or the VM might augment the passed in name (the OSX code prepends "Java:"; consequently the test can't know for sure what to expect to read back from the VM. This functionality came in as part of the OSX port but only provided an implementation on OSX (not even BSD in general). It provides an ease-of-use enhancement when doing low-level debugging, and due to name length restrictions may not even assist with uniquely identifying different threads. Given the portability issues and the fact we don't seem to have a way to add this on Solaris, I'm inclined to simply leave this as WNF.
04-02-2014

Question: if we have the setter function, shouldn't we also have a getter function? It would help, for example, with verifying that the API works - a test that we should probably have in our nightly runs.
03-02-2014

It seems that the JVM_SetNativeThreadName symbol has been already exposed in the http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7116189
03-02-2014

Note Roman's webrev was updated: http://cr.openjdk.java.net/~rkennke/linux_threadname/webrev.02/ Also see discussion starting with Roman's proposal here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-July/006211.html We may need to use dynamic lookup to see if this _np function is available at runtime. There was also some conflicting information regarding the name length limitation.
03-02-2014

For Linux: according to http://repo.or.cz/w/glibc.git/blob_plain/HEAD:/NEWS pthread_setname_np was added in glibc Version 2.12. http://cr.openjdk.java.net/~rkennke/linux_threadname/webrev.00/src/os/linux/vm/os_linux.cpp.udiff.html
31-01-2014