extending libgcc's exception delivery path

[Godmar Back]

 Mike, thanks for your reply. 

I'm happy that you agree that it's desirable for gcc to interoperate
with other EH mechanisms.

Let me respond to some points you made and ask some questions:

> 
> Current implementation choices aren't always right.  The
> implementation can be extended to perform better for new uses.  I
> don't see this as a bad thing.
> 
> My guess is that the unit of compilation should be one registration
> call.
> 

I agree that implementation choices can be changed.  
The current scheme is okay for infrequent calls to register/unregister
and for a having a small overall number of modules.

Other issues that may have to considered when changing the implementation
are whether such changes require changes to the assembler/linker, and
whether such changes would require a larger memory overhead.

> > Secondly, having to generate dwarf2 frame information is frankly a
> > big hassle to do on the fly.
> 
> I don't find this compelling.  For example, we could add a DWARF2 JIT
> tag, complete with function to call when EH is hit in the region, and
> then you just build a singular canonical DWARF2 entry that just says,
> this is a JIT thing, come to me for all your jit code.  Really simple,
> learn the 40 bytes you have to throw out for it and you're done.
> 

What is and what isn't a hassle often depends on who's doing the work.
Your name is in the exception code that emits the dwarf2 information,
so you already have some degree of familiarity with it.  

When I started the integration work, I found one or two sources with
information about DWARF2 on the web, specifically
http://www.arm.com/Documentation/ISTSpecs/TIS-DWARF2.pdf
I did not found any information about the x86 specific mapping, so
I had to reverse-engineer the gdb-specific information from the 
config/i386 files.  I also checked intel's ftp site, but didn't find 
the relevant information (though I can' swear that it's not there, I 
just didn't find it.)  Does anybody have more pointers?
In general, should a jit writer have to learn dwarf2 in all its glory(?)

I believe there are other concerns too.  For instance, are libraries to 
emit dwarf2 information available?  The 10000 lines of code in 
dwarf2out.c may not be reusable.  While it may be possible to
patch the 40 bytes together for a simplistic jit such as kaffe, it's
doubtful whether this approach will scale to more sophisticated schemes
without such a library.

Even for kaffe, I bet that it's not just 40 bytes.  For each stackframe,
I have to:
- check whether a monitor associated with that frame must be unlocked
  and if so do it.   I don't actually know how I would do that with dwarf.
  Is it possible, i.e., can it be expressed?

- check whether the frame is inside some special assembly code for which
  I don't have exception handling information and if so skip it.  
  (Should work with dwarf, but we're exceeding the 40 byte boundary.)

- possibly deliver the exception objects in a register to a jit
  exception handler.  I'd use a generic handler here, but again it's 
  clumsy and possibly inefficient.

I also believe that there may be an efficiency argument to be made.
The DWARF2 information, from what I can tell, is interpreted for every
exception thrown,  currently twice per stackframe.  Bypassing DWARF does 
avoid repeatedly interpreting the same information over and over.

[ gcj/libgcj currently is about one to two orders of magnitude slower
than IBM's JDK as far as exception throwing is concerned.  That's
despite the fact that gcj doesn't fully implement backtraces yet.
Clearly, the exception path may not be worth optimizing for "real"
applications, but IMO that doesn't mean one should treat it as though
it's free.  Chase's 1994 paper on exception handling in C/C++ gives
a number of 10,000 instructions in the exceptional case per 1 instruction
in the common case.  (Range based exception handling may not spend
any instructions in the common case, but so what.)]

> Though the right long term interface for an independent jit compiler
> isn't exactly clear to me.  DWARF2 isn't probably it.  I'd almost
> perfer a library interface, were you could communicate raw ideas about
> the generation process to a state machine that would then build the
> DWARF2 stuff (if that was the scheme used by the runtime system).

I think I agree.

> 
> For the short term, I wouldn't mind the simplistic approach you
> propose.  By using the scheme, we can find out how we don't like it,
> and if we don't like it enough, someone will replace it with something
> better.  I would urge you to think seriously about the longer term,
> and one of the schemes above before just dropping in the code you
> posted.
> 

Once/if we get to that stage, that would be nice.

	- Godmar