Hey Adam,
As you probably figured out, those two stacks contain a bunch of JITed
code. The hotspot JVM should provide the facilities for DTrace to
interpret those symbolically. Printing of C symbols use an orthogonal
-- and far simpler -- mechanism.
Can someone from the Apple team comment on this?
Adam
On Fri, Mar 25, 2011 at 11:15 AM, Adam Cath <adam.c...@gmail.com> wrote:
> Hi folks,
>
> I can't get jstack() to yield meaningful results for any Java program on my
> Mac. Here's what I've tried:
>
> 1) dtrace -n 'hotspot*:::method-entry { trace(copyinstr(arg1, arg2));
> jstack(); }'
> 2) Launch my app with -XX:+ExtendedDTraceProbes
>
> And I get two types of results:
> ---------------
> 5 32730
> _ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP13methodOopDesc:method-en
> try java/lang/Object
> libclient.dylib`JVM_RaiseSignal+0x7cb5b
> 0x3fcafd0
> 0x4002ff4
> 0x380439d
> 0x3801374
> libclient.dylib`JVM_Lseek+0x2317c
> libclient.dylib`JVM_Lseek+0x22f24
> libclient.dylib`JVM_StartThread+0xa4f
> libclient.dylib`JVM_StartThread+0x954
> libclient.dylib`JVM_StartThread+0x8e3
> libclient.dylib`JVM_StartThread+0x756
> libclient.dylib`JVM_StartThread+0x605
> libclient.dylib`JNI_CreateJavaVM_Impl+0xc9fe
> libSystem.B.dylib`_pthread_start+0x159
> libSystem.B.dylib`thread_start+0x22
>
> ---------------
> 6 32730
> _ZN13SharedRuntime19dtrace_method_entryEP10JavaThreadP13methodOopDesc:method-en
> try org/eclipse/swt/internal/carbon/OS
> libclient.dylib`JVM_RaiseSignal+0x7cb5b
> 0x3ca3d5e
> 0x3d56ab4
> 0x3803ec1
> 0x3803fe5
> 0x3803fe5
> 0x380439d
> 0x3803ec1
> 0x3803fe5
> 0x3803fe5
> 0x3804503
> 0x3804503
> 0x3804027
> 0x3804027
> 0x3804027
> 0x3801374
> libclient.dylib`JVM_Lseek+0x2317c
> libclient.dylib`JVM_Lseek+0x22f24
> libclient.dylib`JVM_Lseek+0x22efa
> libclient.dylib`JVM_NewInstanceFromConstructor+0xcf2
> libclient.dylib`JVM_InvokeMethod+0x401
> libclient.dylib`JVM_InvokeMethod+0x178
> libjvmlinkage.dylib`JVM_InvokeMethod+0x4f
> libjava.jnilib`Java_sun_reflect_NativeMethodAccessorImpl_invoke0+0x26
> 0x3811490
> 0x3804027
> 0x3804027
> 0x3804503
> 0x3804027
> 0x3803ec1
> 0x3803ec1
> 0x3803fe5
> 0x3801374
> libclient.dylib`JVM_Lseek+0x2317c
> libclient.dylib`JVM_Lseek+0x22f24
> libclient.dylib`JVM_Lseek+0x22efa
> libclient.dylib`JVM_FindLoadedClass+0xe05
> libclient.dylib`JVM_FindLoadedClass+0xc84
> java`0x358f
> java`0x5b66
> Foundation`__NSThreadPerformPerform+0x1fa
> CoreFoundation`__CFRunLoopDoSources0+0x61b
> CoreFoundation`__CFRunLoopRun+0x42f
> CoreFoundation`CFRunLoopRunSpecific+0x1c4
> CoreFoundation`CFRunLoopRunInMode+0x61
> java`0x51b6
> java`0x4bdf
> java`0x2335
> java`0x27
> ---------------
>
> These stacks are not terribly informative. It seems unlikely that every
> single Java method is called by JVM_RaiseSignal. And of course, there are
> those long chains of symbol-less frames, including several which claim to be
> recursive (0x3804027 recurs twice? Really?).
>
> Some data points: dtrace does correctly print out the method names, so it is
> managing to get some symbol information. Also, the jstack command-line
> utility works correctly for the same process.
>
> I'm on Mac OS 10.6.6, using the Apple JVM (I've tried 1.5 and 1.6). I get
> the same behavior regardless of what program I run. I asked dap to try it on
> his machine and he gets similar nonsense.
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
>
--
Adam Leventhal, Delphix
http://dtrace.org/blogs/ahl
275 Middlefield Road, Suite 50
Menlo Park, CA 94025
http://www.delphix.com
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
