Re: Beware: Rep spec on an enumeration type causes code explosion

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Joe Gwinn said

<<Exception handlers.  We were declaring a number of exception handlers at
  the beginning of each and every module, so every time the module was
  entered, the context had to be saved, and every time the module was
  exited, the context was popped off the exception stack and discarded,
  regardless of if an exception was ever raised.  This was easily solved;
  now, only tasks declare exception handlers, not modules.>>


Just so it is clear, this is by no means a necessary consequence of the
Ada language (and indeed the situation with exceptions is essentially
identical in C++).

The issue is how exceptions are implemented. It is indeed much easier
to handle exceptions by doing context saves on entry to an exception
frame, and then popping them off. Particularly in tasking environments
(where the current task context must be accessed to determine where
to store the context), and on RISC machines (where saving the context
can mean saving dozens of registers), this can be a very expensive
approach. With GNAT, we even discovered that Sun, for no good reason
at all, was doing a system call as part of setjmp!

In the case of GNAT, we used to use the system setjmp/longjmp for this
purpose, but, particularly because of the idiotically inefficient design
of setjmp in Solaris, we replaced this with our own builtin setjmp that
is much more efficient, but that is still only relative.

Really what is intended and expected by the Ada design is a "zero cost"
approach where the declaration of exception handlers costs nothing, and
you pay a price only when an exception is raised. This is done by building
appropriate data tables, so that the exception handler can figure out how
to restore the context without having wasted time saving it.

Such zero cost exception handling approaches are not science fiction, rather
they are pretty standard in the Ada world. I assume that the new Aonix
Object Ada has zero cost EH (the reason I assume this is that the runtime
is based on the old Alsys technology, and I helped write the zero cost
exception handling for this old technology :-) I certainly know that
Verdix Ada 83 technology uses a zero cost approach.

The difficulty with the zero cost approach is that it tends to be highly
machine dependent, and that is one of the reasons that it is been difficult
to do in the GNAT environment, which is so committed to machine independent
approaches. 

Nevertheless we regard switching to a zero cost exception scheme in GNAT to
be our highest priority technical improvement to the system, and indeed it
happens to be exactly what I am working on right now (I am answering this
while waiting for a new version to build that incorporates some of the 
necessary changes). This will first be built for the SGI version (that's
because SGI is funding some of the technical work for this modification),
but will be propagated to other versions soon after.

The bottom line here is that this is something you need to beat up on your
vendor about! Some of our customers have complained loudly at this problem
in GNAT, and as usual, the technical direction of GNAT, like any other
commercial compiler, is quite sensitive to user needs :-) :-) We know at
least one customer who would like to switch from Verdix (Rational)
technology, but this one inefficiency is holding them up (that's an SGI
customer, and hopefully the problem will be resolved very shortly, and
they will be able to do the switch they would like to).

If you have a style of programming which requires very large numbers of
exception handlers, then this is one of the aspects of compiler performance
that you need to carefuly evaluate. It is most certainly an issue that
you need to be aware of when using a language like Ad or C++ that supports
exceptions.

Robert Dewar
Ada Core Technologies