Re: [JVMTI] RFA: JVMTI Stack Tracing

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Andrew Haley wrote:
 > > David Daney writes:
 > >  > Kyle Galloway wrote:
 > >
 > >  > Is libc async-signal safe?  What happens if the unwinder cannot produce 
 > >  > a stacktrace because the thread was stopped somewhere where there was no 
 > >  > unwind info?
 > >
 > > That seems to me like a problem.  gdb uses a bunch of heuristics to
 > > get the stack trace, but it still sometimes fails.
 >
 > I think the only way to make it robust would be to have a little thread 
 > local 'stack' of IP values.  You would push the IP each time you were 
 > entering native code and pop it each time you came back out.  The 
 > unwinder would then use these values to find the last time you were in 
 > java code and could generate the stack trace from there.  I have no idea 
 > of what Sun does in their implementation, but I can't help but think 
 > that they do something like that.  Forcing all native code to use JNI 
 > makes it easier to implement something like this because there are only 
 > a couple of places you would have to track the IP.

I know that Sun use a lookaside structure to handle security contexts,
rather than tracing the stack every time.

 > With CNI it is much more difficult, I think you would need help from the 
 > compiler to call some method before entering any native code (similar to 
 > how profiling is done I think).

Getting help from the compiler is not a problem for Java code, but
we're not always executing Java code.

 > Not that the current implementation should not go in.  Stacktraces that 
 > are not 100% reliable are better than no stacktraces at all.

Well, it's not just a matter of not being 100% accurate.  It might
abort.

Andrew.