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


David Daney writes:
 > 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.
 > 
 > I take exception with that last part :->

I stand by it.  Usually, gcj-compiled programs are *used*.

 > Really the whole reason that stack traces exist is to make
 > debugging easier (or even possible).  I am not trying to be
 > pedantic about having libgcj behave identically to the JDK.  There
 > are countless times (several per day) where by looking at a stack
 > trace I have discovered the cause of some bug.  Without the stack
 > trace I would have to run the program in gdb and hack around for a
 > while.  It wouldn't surprise me if stack traces saved me an average
 > of an hour a day.

That's beside the point.  I wasn't proposing to turn stack traces off.
I was proposing to turn filenames/line numbers off, by default.

 > I would be almost as happy if instead of file/line number pairs, that 
 > raw addresses were produced, but the new StackTraceElement 
 > infrastructure has made that less easy (currently impossible I think).

 > > 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.
 > 
 > We all have different priorities.  I know that WRT libgcj that
 > yours do not exactly coincide with mine.
 > 
 > One of my priorities is to make it possible to fix bugs in large
 > java programs running on Linux systems with less than 32MB of RAM
 > and no swap devices.  Often we have to strip all debugging
 > information, so having a line number decoder (based on addr2line or
 > some built-in decoder) does not help.

So why do you care about line numbers?

Andrew.


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