This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The cost of stack traces


Bryce McKinlay writes:
 > 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.

Mostly, yes, 

 > I agree that changing the default to not show line numbers is a bad
 > idea. Java developers _expect_ them to be there

Always?  I vaguely remember JITs that didn't provide much of this when
optimizaing.  I might be wrong about that.

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

There is some sense in simply blacklisting libraries that don't have
debuginfo, for sure.  This will make most of the problem go away for
Fedora Core, but it might be mystifying for people to discover their
application slows down when they rebuild from source!  Still, that
isn't a strong objection: it solves the problem for many of our
end-users.

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

Perhaps it could, yes, but that overhead is pretty high.

DWARF unwinder data is a big disadvantage we have relative to other
VMs.  We'll sooner or later have to confront that problem, and when we
do we'll also be able to do something efficient with the line number
table.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]