RFC: stack trace generation
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