Re: The cost of stack traces

[Bryce McKinlay <mckinlay at redhat dot com>]

Andrew Haley wrote:
> 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.
>   

Setting a flag to remember whether a shared library has debuginfo or not 
seems like a simple fix. This would at least prevent repeated 
invocations of addr2line when the info does not exist, which would solve 
the immediate problem.

I agree that changing the default to not show line numbers is a bad 
idea. Java developers _expect_ them to be there and not providing them 
would be an awkward deviation from other implementations. IMO, improving 
the performance of line number lookup is the best fix for the general case.

> 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.

The .debug_line section is relatively compact compared to other types of 
DWARF debug info: the line info for all of libgcj is under 1MB on i686. 
Reading it efficiently does require creating additional data structures 
at runtime, but I suspect it is possible to create an implementation 
that is dramatically more efficient than addr2line. 

I have toyed around in the past with a built-in .debug_line reader 
(based on Casey Marshall's code) but abandoned it at the time since that 
implementation was not significantly faster than using addr2line. That 
code was Java/nio based and did not do much in the way of caching or 
indexing of the debug_line bytecode, however. A C implementation which 
does this would be fast and wouldn't consume all that much memory beyond 
the (read-only) mmap'ed .debug_line section. I'd expect the overhead of 
finding a line number for a given frame could be made comparable to that 
of reading .eh_frame info during unwinding.

Bryce