The cost of stack traces

Thu May 11 16:14:00 GMT 2006

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.