RFC: stack trace generation

Andrew Haley aph@redhat.com
Tue Aug 3 18:10:00 GMT 2004

Boehm, Hans writes:

 > Note that there is some interaction here with the heap debugging
 > patch (which is still not in the tree).  In debug mode, the garbage
 > collector likes to put a stack trace in every object, which makes
 > stack traces much more performance critical.  Frame-pointer-based
 > unwinding seems OK.  David Mosberger's libunwind would probably
 > also be OK, though slower, since it does a fair amount of caching.
 > I haven't looked enough at dwarf2-backtrace.cc to see whether it
 > could be used directly.
 > Currently the GC usually does its own unwinding on X86.  Since heap
 > debugging currently requires a different build anyway, it would be
 > OK to just enable frame pointers (on X86) for those builds.

That seems sensible.  However, on many targets we won't ever be
building with frame pointers, so this won't be possible.

A caching version of backtrace() sounds like a nice idea.  Maybe not
even all that hard?  I'm not sure.


More information about the Java mailing list