exception handling poll

exception handling poll

[Richard Henderson]

A little poll for those that have been complaining about 
exception handling frame unwind info being included for C:

  Assuming the .eh_frame section is completely read-only, at what
  eh/text ratio would you find it acceptible that that information
  is always there?

Can you live with 10%?  8?  5?  3?


----------------------------

I was having a look at a "random" nice large program this evening,
f771, and trying to work out how big the frame info would be
assuming ideal generation.

Some basic numbers: 1533276 bytes text, 4210 functions.

The dwarf2 frame info requires 16 bytes/function static overhead for
eh info length, cie address, function address, and function length. 
For f771, that brings us up to a few more than 67k, or 4.4% even before
adding any actual information.

Depending on how the initial_information insn bits in the CIE is
interpreted, this could potentially encode all the information for 
all x86 with 3 CIEs.  Which means about 60 more bytes.  It would 
seem then, that somewhere around 4.5% is the best we could possibly
do on f771 with dwarf2 frame info. 

(I suppose some more large program data points would be good.  Anyone
have x86 glibc handy compiled with eh info?)

Now, with the current adv4/cfa_ofs/adv4/cfa_reg sequence on x86 to set
up the frame pointer, this eats up another 60204 bytes, 43366 of which
is in the adv4's.  Assuming we knew we could reduce these to adv, we'd
reduce that 43k to 8673 for a total of 25511.  Relaxing rigour for a
moment, changing to def_cfa would total 12630.  Adding these to our
base totals, we get 6.0% and 5.2% respectively.

Recording one saved register is adv/ofs for 1+2 bytes; recording two
or three (there are only 3 saved regs not including bp), takes 4.  Add
this in to our running total and we get 6.04% min and 7.16% max.

This 7.2% number is interesting because I think it is about as good as
can theoretically be done without linker help; assistance from within
the assembler doesn't help.  What would be required to get here is exact
length attributes on the insns in the i386.md file.  

With an inexact but bounding length attribute, we could minimize the
current lossage above this number from 4*3 to 1*3 bytes/FDE.  This would
make for about 8.0% on the running total.

So.  Given the number I posted last night at 12.5%, a patch I put 
together this evening that yields about 11% on x86, a rock-bottom
minimum somewhere between 4.5 and 6% (depending on other constraints)
and the fact that the sparc port is already down at 5.4%:

  Is it worth spending the effort required to get that last 5%,
  possibly by requiring a new version of gnu ld?  Or would I just
  be wasting my time since the overhead would still be considered 
  unacceptible?
  


r~

Re: exception handling poll

[Joe Buck]

> A little poll for those that have been complaining about 
> exception handling frame unwind info being included for C:
> 
>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

If the .eh_frame section does not get paged into memory, then I think 10% is
acceptable (remember that the in-memory penalty is essentially zero).  For
kernels or embedded code where there is no paging, the acceptable figure
is smaller, and I suspect that folks would use -fno-exceptions no matter
how small the penalty is (unless it is 2% or less).

Re: exception handling poll

[Joern Rennecke]

> So.  Given the number I posted last night at 12.5%, a patch I put 
> together this evening that yields about 11% on x86, a rock-bottom
> minimum somewhere between 4.5 and 6% (depending on other constraints)
> and the fact that the sparc port is already down at 5.4%:
> 
>   Is it worth spending the effort required to get that last 5%,
>   possibly by requiring a new version of gnu ld?  Or would I just
>   be wasting my time since the overhead would still be considered 
>   unacceptible?

Why don't you implement first a scheme that makes the linker strip all EH
info if there is no user of EH info?  That looks like a greater saving to
me.

Of course, a low-overhead EH scheme is still important if you need EH
info in shared libraries.

Re: exception handling poll

[Richard Henderson]

On Thu, Oct 16, 1997 at 09:22:42PM +0100, Joern Rennecke wrote:
> Of course, a low-overhead EH scheme is still important if you need EH
> info in shared libraries.

Yes, we do.

Having the linker strip out the section when it can determine that
it is not used is a good option, but am also trying to figure out
what can be done without requiring gnu ld, and a new version at that.


r~

Re: exception handling poll

[Oleg Krivosheev]

On Thu, 16 Oct 1997, Richard Henderson wrote:

> A little poll for those that have been complaining about 
> exception handling frame unwind info being included for C:
> 
>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

i'd like 8%.

no, i don't have any rational thoughts
but being less than 10% would be nice

thanks

OK

Re: exception handling poll

[John Carr]

>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

Probably 3%.

For the first egcs release we should:

1. Default C -fexceptions off on all targets.  Not one extra bit for
exception handling.

2. Get the overhead for code not using exceptions, but compiled with
exceptions enabled, under 8% (for "typical" code, whatever that is).
If that means setjmp exceptions on x86, then we do that.

3. Document and warn that the next egcs release will be binary
incompatible if exceptions are used.

Then we have a few months to fix exceptions and we can look at making
them better, smaller, faster, or compatible with the system compiler
without delaying a release.

Re: exception handling poll

[Stephen Williams]

On Thu, 16 Oct 1997, Richard Henderson wrote:

> A little poll for those that have been complaining about 
> exception handling frame unwind info being included for C:
> 
>   Assuming the .eh_frame section is completely read-only, at what
>   eh/text ratio would you find it acceptible that that information
>   is always there?
> 
> Can you live with 10%?  8?  5?  3?

I can no longer contain myself:

0%. (Well, maybe a tiny bit more then that.)

I use g++ for embedded targets, and I have spent much effort getting
executable sizes down. Exception handling would be really nice, but
x% costs real hardware, and real money. And prices are not linear, either.

Don't forget us embedded people, please:-)

-- 
Steve Williams
steve@icarus.com
steve@picturel.com

"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

template mangling (was: exception handling poll)

[Joe Buck]

I wrote:
> > And we'll pretty much want to to get more efficient mangling of
> > template functions.  Just for fun, try looking at the mangled symbols
> > generated for the methods of map<string,string> .
> 
> Aiee.  Tell me about it.  I recently fixed a reported problem in the
> assembler with ECOFF debugging that bombed because the stab for the
> class exceeded 4k, primarily due to a 336 character class name.

I had a proposal to fix the problem a year ago, but I've had no time to
work on it and it seems I won't in the immediate future.

In case anyone else on this list is interested, I'll post it again.
(it refers to 2.7.2, so map<string,string,less<string> > is a bit
different now).

Any volunteers to hack something like this up?

-----------------------------------------------------------------------
As some of you may have noticed, I've been griping about the huge
symbols that result from use of g++.  Things can be improved a lot
by revising the name mangling scheme to encode repeated types better.

The basic idea for the modification to the mangling scheme is that we add
a class list, which contains the n'th class seen so far, in left to right
order.  This augments the argument list, which is already kept.  A class
is "seen" when we reach the end of it, so for vector<Foo> we first see
Foo, then vector<Foo>.  These are coded in the template string using some
unused key letter, such as B.  We apply the repeated-argument encoding (T)
first.

There's a potential problem if the mangler and demangler don't agree
on the order in which the classes are seen, but I don't think that
this problem can arise here, since the class names should appear in
the same order in both demangled and mangled forms.

The coding is particularly effective on complex template types but
helps in other cases as well.

Here are some simple examples:

EgAndInstance::EgAndInstance(const EgAndInstance&)

was

___13EgAndInstanceRC13EgAndInstance

becomes

___13EgAndInstanceRCB0

B0 = class list entry 0.

ostream::operator<<(ostream &(*)(ostream &))

(this appears with manipulators) was

___ls__7ostreamPFR7ostream_R7ostream

becomes

___ls__7ostreamPFRB0_B0

Now here's a tricky one.  This symbol appears when we use
a map<string,string,less<string> >.

rb_tree<basic_string<char, string_char_traits<char> >,
pair<basic_string<char, string_char_traits<char> > const,
     basic_string<char, string_char_traits<char> > >,
select1st<pair<basic_string<char, string_char_traits<char> > const,
basic_string<char, string_char_traits<char> > >, basic_string<char,
string_char_traits<char> > >, less<basic_string<char,
string_char_traits<char> > > >::__copy_hack(void *, void *)

To make this symbol easier to understand, it is

rb_tree<string,
	pair<string const, string >,
	select1st< pair<string const, string >, string >,
	less<string > >
::__copy_hack(void *, void *)

We will build the following class list.

B0 = string_char_traits<char>
B1 = basic_string<char,B0> = string
B2 = pair<const B1,B1>
B3 = select1st<B2,B1>
B4 = less<B1>

(only B1 and B2 are re-used)

The old mangling is

___copy_hack__t7rb_tree4Zt12basic_string2ZcZt18string_char_traits1ZcZt4pair2ZCt

12basic_string2ZcZt18string_char_traits1ZcZt12basic_string2ZcZt18string_char_traits1ZcZt9select1st2Zt4pair2ZCt12basic_string2ZcZt18string_char_traits1ZcZt12basic_string2ZcZt18string_char_traits1ZcZt12basic_string2ZcZt18string_char_traits1ZcZt4less1Zt12basic_string2ZcZt18string_char_traits1ZcPvT1

The new mangling becomes (if I did this right)

___copy_hack__t7rb_tree4Zt12basic_string2ZcZt18string_char_traits1ZcZt4pair2ZCB1B1t9select1st2ZB2B1t4less1ZB1PvT1

Something like this is going to be essential to have STL work on platforms
that limit symbol name lengths (HP is one).  (Sun as has a 2048-character
limit in stabs).

------------
If something like this is developed, there should probably be a compiler
switch to enable the old or new schemes.  The same cplus_demangle could
handle either scheme.

Re: exception handling poll

[Richard Henderson]

On Fri, Oct 17, 1997 at 10:22:16AM -0700, Joe Buck wrote:
> And we'll pretty much want to to get more efficient mangling of
> template functions.  Just for fun, try looking at the mangled symbols
> generated for the methods of map<string,string> .

Aiee.  Tell me about it.  I recently fixed a reported problem in the
assembler with ECOFF debugging that bombed because the stab for the
class exceeded 4k, primarily due to a 336 character class name.


r~

Re: exception handling poll

[Joe Buck]

> 2. Get the overhead for code not using exceptions, but compiled with
> exceptions enabled, under 8% (for "typical" code, whatever that is).
> If that means setjmp exceptions on x86, then we do that.

Um, are you sure?  setjmp exceptions put extra code in the text section,
which must be paged in.  .eh_frame, on the other hand, is not paged
in normally (or at least, not once it is completely read-only), the
extra space is on disk.  Switching to setjmp exceptions means that you
pay more RAM and CPU (since there is overhead even when exceptions are
not thrown).  You only save disk space.  Is that really a good tradeoff?

> 3. Document and warn that the next egcs release will be binary
> incompatible if exceptions are used.

Well, I think we're going to break compatibility for C++ soon.  We
pretty much have to to support namespaces and templated iostreams.
And we'll pretty much want to to get more efficient mangling of
template functions.  Just for fun, try looking at the mangled symbols
generated for the methods of map<string,string> .

Re: exception handling poll

[Jeffrey A Law]

  In message < 199710171340.JAA23714@contents-vnder-pressvre.MIT.EDU >
  John Carr wrote:

  > Probably 3%.
  > 
  > For the first egcs release we should:
  > 
  > 1. Default C -fexceptions off on all targets.  Not one extra bit for
  > exception handling.
I think that's the direction we're heading.  I guess now is as good a time
as any to tell everyone :-)

Basically, we're going to be temporarily turning off -fexceptions for C
(hopefully starting with the next snapshot).  The basic idea is to turn
it off so the C folks won't pay the EH penalty until such time as we can
get the overhead down to something acceptable to most C programmers.

jeff

Re: exception handling poll

[John Carr]

> > If that means setjmp exceptions on x86, then we do that.
> 
> Um, are you sure?  setjmp exceptions put extra code in the text section,
> which must be paged in.

No, I'm not sure.  I guess we just can't win if exceptions are enabled
with the current architecture, and that's why I want the binary
incompatibility warning.

> Well, I think we're going to break compatibility for C++ soon.  We
> pretty much have to to support namespaces and templated iostreams.
> And we'll pretty much want to to get more efficient mangling of
> template functions.  Just for fun, try looking at the mangled symbols
> generated for the methods of map<string,string> .

Someone should keep a list of changes that would help gcc but break
compatibility so we can do them all at once.

Re: exception handling poll

[Oleg Krivosheev]

hi,

On Fri, 17 Oct 1997, Stephen Williams wrote:

> On Thu, 16 Oct 1997, Richard Henderson wrote:
> 
> > A little poll for those that have been complaining about 
> > exception handling frame unwind info being included for C:
> > 
> >   Assuming the .eh_frame section is completely read-only, at what
> >   eh/text ratio would you find it acceptible that that information
> >   is always there?
> > 
> > Can you live with 10%?  8?  5?  3?
> 
> I can no longer contain myself:
> 
> 0%. (Well, maybe a tiny bit more then that.)
> 
> I use g++ for embedded targets, and I have spent much effort getting
> executable sizes down. Exception handling would be really nice, but
> x% costs real hardware, and real money. And prices are not linear, either.
> 
> Don't forget us embedded people, please:-)

hmm...

can be EH exposed into C? Something like MS
__try, __catch etc ? Maybe after this embedded
people will be happy having added value for few %
bloat?

just a thought

OK

Re: exception handling poll

[Per Bothner]

Joe Buck <jbuck@synopsys.com> writes:
> Um, are you sure?  setjmp exceptions put extra code in the text section,
> which must be paged in.

I'm wondering if you and John Carr might be mis-understanding one other.
I understood John to mean that using setjmp would satisfy the
requirement of no cost in code that does not *contain a handler",
while still allowing exceptions to pass through such code.

Joe's point seems to be that having setjmp code in the text segment
is worse than having eh ranges in an eh section which is normally
not pages in.  That is true - the problem is that we would still
need some eh info for functions with no handlers, if they can
be thrown through, but that is not the case (I think) for a
setjmp-based solution, though it is otherwise more expensive.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: exception handling poll

[John Carr]

> I understood John to mean that using setjmp would satisfy the
> requirement of no cost in code that does not *contain a handler",
> while still allowing exceptions to pass through such code.

When I sent my mail I forgot that local variables with destructors
require exception handlers to run those destructors so most C++ code
is not handler-free and setjmp will introduce significant code
expansion.