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:
 > > 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*.
 > 
 > I know that.  That is why my priorities are sometimes different than 
 > yours.  My users are all software engineers that like stack traces that 
 > reveal as much information as possible.

I repeat, I'm only proposing to change the default.  If you want
verbose stack traces, you can turn them on, either at build time or by
setting an environment variable.

 > As defined in this e-mail thread, I now realize that do don't care about 
 > 'line-numbers'.  Thanks for helping me arrive at this conclusion.

I'll take that as a "don't".  :-)

 > What would you think about a patch that optionally fills in the fileName 
 >   property of StackTraceElement with a string representation of the IP 
 > and information obtained from dladdr related to that address?

Semms reasonable, as long as it doesn't do so by default.  Now that
really would confuse people!

By the way, I don't think the new stacktrace infrastructure makes
hex-only stacktraces difficult to generate.  See line 275 in
stacktrace.cc.

Andrew.


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