Merging the MacOS X Port into HotSpot Express 23 (7098194)
roger hoover
rhoover at apple.com
Wed Oct 12 16:49:09 PDT 2011
On Oct 12, 2011, at 5:39 PM, Tom Rodriguez wrote:
>
> On Oct 12, 2011, at 3:53 PM, Daniel D. Daugherty wrote:
>
>>> On 10/12/11 6:33 PM, Daniel D. Daugherty 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.
>>>>
>>>> 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...
>>>
>>> True. But it may not be used in it's current form.
>>
>> 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);
>
> 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).
>
> tom
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
More information about the hotspot-dev
mailing list