Re: exceptions ( static analysis possible? )

bill@amber.ssd.hcsc.com (Bill Leonard)
Wed, 2 Aug 1995 15:24:04 GMT

          From comp.compilers

Related articles
Implementation and Optimization of exceptions ( static analysis possi sdm7g@elvis.med.virginia.edu (Steven D. Majewski) (1995-07-21)
Re: exceptions ( static analysis possible? ) bill@amber.ssd.hcsc.com (1995-08-02)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bill@amber.ssd.hcsc.com (Bill Leonard)
Keywords: errors, optimize
Organization: Harris Computer Systems, Ft. Lauderdale FL
References: 95-07-142
Date: Wed, 2 Aug 1995 15:24:04 GMT

"Steven D. Majewski" <sdm7g@elvis.med.virginia.edu> writes:
> The exception processing model I'm most familiar with ( from long
> years on a VAX, and from similar implementations for various
> languages ) is the stack based one, where every procedure or
> protected block of code has some stack based structure that indicates
> how ( and maybe what ) exceptions are handled. ( This is also the
> only language independent way I can think of to implement exception
> handling - although stack based doesn't have to imply the return
> stack - it could mean separate stacks for handlers for various
> signals. )


Although this is a fairly common (and relatively cheap) implementation
scheme, it is very inefficient. Opening and closing a block of code that
contains an exception handler requires manipulation of this stack. This
invokes overhead for exceptions even when no exceptions are raised and is
thus unacceptable in almost any performance-conscious application. (In
fact, the overhead can become larger than the code the handler is
protecting.)


An alternative implementation is to associate a statically-initialized data
structure with each block of code that has an associated exception handler.
This data structure contains the code address of the beginning and end of
the block of code plus a pointer to the beginning of the exception handler
code. It may also contain other information required for unwinding the
procedure call stack.


When an exception is raised or propagated, the runtime system consults the
data associated with the code where the exception is being raised and
transfers control directly to the handler.


The Harris Ada compiler uses such a technique, making exceptions run
reasonably fast. This technique uses more space -- the data structures
associated with the code may become fairly large (and must reside in the
program's address space so the runtime can access it). However, entering
and leaving blocks containing an exception handler is free of any exception
overhead. Thus, you are trading space for speed.


> Do any language implementations do static analysis and optimization
> of exceptions within a procedure - in effect, translating them into
> goto's and avoiding the overhead of handlers ?


The Harris Ada compiler also translates the "raise" statement to a direct
jump when the exception handler is in the same procedure as the "raise"
statement. This does not avoid the overhead of handlers (after all, the
exception handler *must* be executed), but it does avoid the overhead of
the runtime system's algorithm for finding which handler to execute.


> As exceptions are designed to handle dynamic or unpredictable
> errors, clearly static analysis cannot always be done


All the more reason why the overhead should be restricted to the time when
an exception occurs and not paid over and over throughout the execution
of the application.


Although you cannot always tell what exception will be propagated from,
say, a function call, you can always properly initialize the static
structure describing where the exception handler is located. Thus you can
completely avoid any runtime overhead until such time as an exception is
raised.


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.