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]

The cost of stack traces


As some of you may be aware, I've been doing benchmarking of servers
with a mind to improving gcj performance.

I've recently come across a situation where stack traces greatly
slowed down an application.  Basically, this all comes down to an
interaction between the way that loggers work and the way we do stack
traces.  We're using addr2line to get the line number and filename,
but this leads to a huge number of addr2line process being spawned.

In the past we have considered building a reader for DWARF debug info
into libgcj, but this may not help as much as we imagine: a perusal of
the profile data for addr2line reveals that much of the CPU time is in
libbfd itself -- the big effort isn't just spawning addr2line
processes, it's actually doing the work of reading the debug info.

And all of this is often supremely pointless in Fedora, where many of
the gcj libraries don't have any debuginfo to read.

The effect of all this is dramatic: running a test load in JOnAS is

   38m18s with addr2line, and
   22m49s without.

I suggest that we set the default use_addr2line to false.  People will
still get the method info, just not the filename and line number of
the source file.

Another possibility is to keep the addr2line processes alive between
invocations of stacktrace.  This is a fairly small change to
NameFinder, but has the disadvantage of consuming a lot of long-term
resources.

Andrew.


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