This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: RFC: stack trace generation
- From: Andrew Haley <aph at redhat dot com>
- To: "Boehm, Hans" <hans dot boehm at hp dot com>
- Cc: "'Bryce McKinlay'" <mckinlay at redhat dot com>, David Daney <ddaney at avtrex dot com>, java at gcc dot gnu dot org
- Date: Tue, 3 Aug 2004 19:06:18 +0100
- Subject: RE: RFC: stack trace generation
- References: <0C3EFB691636964BBF914AE56AE83A89502249@hplex4.hpl.hp.com>
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.
Andrew.