Re: The cost of stack traces

[Andrew Haley <aph at redhat dot com>]

Casey Marshall writes:
 > On May 11, 2006, at 7:07 AM, Andrew Haley wrote:
 > 
 > > One thing that seems almost to have got completely lost in all this
 > > talk about how to make stack traces faster is the sheer pointlessness
 > > of it all.  Many (if not most) of the installed gcj-compiled libraries
 > > don't have debuginfo and usually no-one cares about the line numbers
 > > anyway.
 > >
 > > One thing we could do is detect libraries with no debuginfo and from
 > > that point onwards not bother looking for it.
 > >
 > > By all means let's make the traces faster but there are surely better
 > > uses of our time.
 > 
 > I don't agree that it's pointless. Lots of people (probably for the  
 > worse, but that isn't the point) rely on source and line numbers in  
 > stack traces to diagnose problems. It really is the best compromise  
 > to not having __LINE__ and __FILE__ in Java.
 > 
 > In the end, this is a feature that developers using GCJ (who are your  
 > users!) are going to want. Because you personally find it useless  
 > isn't what they (I!) are going to want to hear.

I wasn't proposing to disable it, just change the default.

What I am saying is that many gcj-compiled libraries -- certainly all
of those in Fedora Core, and probably on other GNU-based operating
systems as well -- don't have debuginfo, and so stack traces don't
print line numbers and source filenames.  However, we heroically try,
again and again, to discover that information.

I am not objecting to a DWARF reader built-in to gcj.  That sounds
like a nice idea.  But if it takes a significant amount of time or
memory from real-world *applications*, then I don't think it should be
enabled by default in a release gcj runtime library.

Andrew.