Re: __attribute__((cleanup(function)) versus try/finally

[Jason Merrill <jason@redhat.com>]

On 07 May 2003 15:18:01 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

> Now, with my scheme this function has no handler code; i.e, the EH
> run-time library will never transfer control back to this function.  

Yes.  With the alternative look-aside optimization I mentioned, the same
would be true.  And it wouldn't even require a library call to register the
cleanup.

> Even when using setjmp/longjmp the cost is just one setjmp at the start
> of the function, so that the stack can be unwound.

I think the longjmp_unwind scheme uses multiple setjmps, though I'm not
sure; it doesn't have the benefit of the whole-function analysis that the
compiler can do when inserting EH code.

> If pthread_cleanup_push uses try/finally, it's my understanding that
> there will be multiple calls to setjmp, before each of the calls to g.

I'm pretty sure there's just one at the beginning of the function, emitted
if needed.

The parallel look-aside optimization for the setjmp case could be to
register EH cleanups via a call into the EH runtime much like
pthread_cleanup_push; this would avoid the need for any setjmps if a
function only has cleanups.

> And in the non-setjmp case, there will be landing pads and unwind
> information for each of the exception regions, rather than just one for
> the entire function.

Landing pads, yes, but they're just one instruction unless an optimizer has
moved code there, in which case it's presumably beneficial.

Unwind info is always per-function.  There is, however, an entry in the
LSDA for each region, typically 4 bytes in a small function.  The
look-aside optimization would make this larger, of course.

> Adding EH to C is a very dramatic change.  The spirit of C is "no hidden
> stuff."  Calling exceptions "zero-cost" is a lie; we say that because
> they require no additional instructions be executed unless an exception
> is thrown, not because they actually have no cost.  The unwind tables
> are a significant cost, for example.

Significant, but not unreasonable IMO.  As I mentioned, Irix and Tru64
always emit them.  We always emit them for S/390 and x86-64.  Always
emitting them for pthreads code seems appropriate to me, and much easier
than creating a whole new system to deal with what is basically an already
solved problem.

> To that end, I've toyed with the following idea:
>
> - When building a library written in C, provide two sets of entry points
> for the globally visible functions
>[...]

This sounds like a rather heavy weight solution to this problem.  I'd much
rather re-use mechanisms we already have.

> This kind of solution is awfully attractive if you're on an embedded
> system.  (I want pthreads on my cell-phone, but I sure don't want to have
> extra unwind info around.  I want to be able to support C++, but if it's
> not in use, I don't want to have to pay the cost of supporting C++ by my
> making my C libraries bigger.)

Then you probably want to use setjmp/longjmp exceptions.  With the
optimization described above, it would be no more expensive than the old
mechanism.

Jason