This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: __register_frame_info and unwinding shared libraries


Richard Henderson writes:
 > On Tue, Feb 15, 2005 at 05:27:15PM +0000, Andrew Haley wrote:
 > > So, now for my question: why do we not call __register_frame_info() or
 > > __register_frame_info_bases() ?
 > 
 > Because in the normal case for C/C++, folks don't use that many 
 > exceptions.  So delaying doing anything until it's needed is a win.
 > 
 > Obviously the normal case is different for Java.

Yeah.  In the big server application I'm working on, almost 40% of
total CPU time is spent inside one function,
_Unwind_IteratePhdrCallback().  This is for a few reasons: firstly,
java uses stack traces for things other than throwing exceptions.
Exceptions are relatively rare.

Also, in a big server application you have a lot of shared libraries:
this one has 86.  So, for every single stack frame we're doing many
excursions through _Unwind_IteratePhdrCallback().

 > > We'd avoid a great many trips through
 > > dl_iterate_phdr () and _Unwind_IteratePhdrCallback().
 > 
 > While I still like using dl_iterate_phdr instead of
 > __register_frame_info_bases for totally aesthetic reasons, there
 > have been changes made to the dl_iterate_phdr interface since the
 > gcc support was written that would allow the dl_iterate_phdr
 > results to be cached.

That would be nice.  Also, we could fairly easily build a tree of
nodes, one for each loaded object, then we wouldn't be doing a linear
search through them.  We could do that lazily, so it wouldn't kick in
'til needed.

Andrew.


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