The cost of stack traces

[David Daney]

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

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.

Well that is where I stand.  It is not clear to me what should be done. 
  I feel a patch coming on...

David Daney