This is due to the complexity of Java: while those stacks have the same
textual representations, they have different associated addresses. Consider,
for example, what would happen if the JVM decides to compile a routine into
machine instructions, we take a jstack(), and then the JVM reoptimizes or
moves the position of that compiled routine. A subsequent jstack() would
show that the same function was called, but would have a different associated
address (which isn''t displayed). DTrace could make a better effort of
accumulating these disparate entries, but there are some cases where
that''s
not what you want.
Adam
On Tue, Mar 21, 2006 at 02:26:54AM -0800, Arild Stave
wrote:> I''m running a simple d-program to trace the jstack() on each
contextswitch. Looks like this :
>
> sysinfo:unix:swtch:pswitch
> /pid == 1113 && (tid == 21 || tid == 23 || tid == 17 || tid == 19
|| tid == 20 || tid == 24) && i < grense/
> {
> @stack[jstack()] = count();
> }
>
> The problem is the output is a hundred miles long, even though alot of the
"different" stacks are equal. How come dtrace sees this as different
outcomes? example from the output :
>
> libc.so.1`_so_send+0xc
> libnet.so`Java_java_net_SocketOutputStream_socketWrite0+0x148
> java/net/SocketOutputStream.socketWrite0*
> java/net/SocketOutputStream.socketWrite*
> org/apache/derby/impl/drda/DRDAConnThread.processCommands*
> org/apache/derby/impl/drda/DRDAConnThread.run*
> OSRAdapter
> StubRoutines (1)
>
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x528
>
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
>
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
> libjvm.so`__1cKJavaThreadDrun6M_v_+0x160
> libjvm.so`_start+0x13c
> libc.so.1`_lwp_start
> 2312
>
> libc.so.1`_so_send+0xc
> libnet.so`Java_java_net_SocketOutputStream_socketWrite0+0x148
> java/net/SocketOutputStream.socketWrite0*
> java/net/SocketOutputStream.socketWrite*
> org/apache/derby/impl/drda/DRDAConnThread.processCommands*
> org/apache/derby/impl/drda/DRDAConnThread.run*
> OSRAdapter
> StubRoutines (1)
>
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x528
>
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
>
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
> libjvm.so`__1cKJavaThreadDrun6M_v_+0x160
> libjvm.so`_start+0x13c
> libc.so.1`_lwp_start
> 2735
>
> libc.so.1`_so_send+0xc
> libnet.so`Java_java_net_SocketOutputStream_socketWrite0+0x148
> java/net/SocketOutputStream.socketWrite0*
> java/net/SocketOutputStream.socketWrite*
> org/apache/derby/impl/drda/DRDAConnThread.processCommands*
> org/apache/derby/impl/drda/DRDAConnThread.run*
> OSRAdapter
> StubRoutines (1)
>
libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x528
>
libjvm.so`__1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_+0x188
>
libjvm.so`__1cMthread_entry6FpnKJavaThread_pnGThread__v_+0x134
> libjvm.so`__1cKJavaThreadDrun6M_v_+0x160
> libjvm.so`_start+0x13c
> libc.so.1`_lwp_start
> 20780
>
> As you can see, these three are equal. And there are hundreds more looking
exactly the same. Why didn''t this come out as only one group? Do I have
to write my own program to sort these results?
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
--
Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl