The cost of stack traces
Bryce McKinlay
mckinlay@redhat.com
Thu May 11 18:37:00 GMT 2006
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
More information about the Java
mailing list