EH Performance

[Eli Boling <eboling at mirrorfinish dot com>]

I've been looking at the EH implementation in gcc, and there are some
things that I have noticed.  At least one vendor has disabled EH in
their application because of this issue, and I'm wondering if thought
has been put into it already.

First of all, the eh_frame section is marked as read/write in the image
and, in the case of C++ auto destructor support, this section contains
flat pointers into the .gcc_except_table section.  This causes
relocations to be emitted when you build a shared object, which will
cause the eh_frame section to be paged in at application load time.
Since the eh_frame section is large, this would appear to impact the
startup performance of large applications.  In addition to this, when
the first exception is thrown in an application, the runtime libs do an
initialization step on the eh_frame data which walks across *all* of the
data in the entire application.  Since this data is large (Dwarf2), and
the steps have poor locality, it would appear that all of the eh_frame
data is then paged in again when the first exception is tossed.  For a
large application this could actually cause a significant performance
issue for the first exception being thrown, and that's not too good.
Can anyone give me any history on this topic?

There was a mention about an exception handling discussion list where
the design of eh for gcc was discussed some time ago.  Does anyone have
this list archived anywhere?  I'd like very much to read it.

Thanks in advance,
-Eli Boling