[LLVMdev] Question about implementing exceptions, especially to the VMKit team

[Philip Reames]

On 05/01/2014 02:09 PM, Kevin Modzelewski wrote:
> Hi all, I'm working on implementing exceptions in Pyston, and I was 
> hoping to get some guidance from the list.  I think I've learned 
> enough about C++-style DWARF exceptions to convince myself I have a 
> workable approach, but then I found this VMKit paper (2010) which says
>
>     The exception manager: To manage exceptions, J3 reserves a
>     word for the pending exception in the local storage of each thread.
>     After each method invocation, the word is tested. If an exception
>     has been raised and the function is able to trap the exception, a
>     branch to the exception handler is executed. Otherwise, the function
>     returns to the caller. This implementation is not optimal because it
>     requires a test and branch after each method invocation. A more
>     efficient implementation would use exception tables. However, at
>     time of writing the paper, the exception tables generated by LLVM
>     rely on the GCC runtime library [19] which is not optimized for
>     dynamically generated tables, at least on Linux.
>
>
> So now I'm reexamining whether C++-style exceptions are a good choice 
> for Python, which I would guess throws more exceptions than Java.
>
> Does anyone have advice on the subject?  I'm wary of the costs of 
> having to branch after every function call, but maybe that ends up not 
> being too much of a performance drain if the CPU can predict them 
> correctly?  But then again, it looks like VMKit has moved to a 
> setjmp-longjmp approach, which makes me think that there must have 
> been some overhead that they wanted to avoid.
We have a local implementation which supports both check-after-call and 
unwind tables.  I don't have good performance numbers across a wide 
suite of benchmarks (yet), but our early numbers showed using C++-style 
exceptions to be a significant win on the normal path.  We haven't 
measured the exception path yet.

An interesting point is that (at least in theory), you don't need to 
pick one strategy.  You could use c++ style exceptions for "cold 
throws", and check-after-call for "warm throws".  This is quite a bit of 
infrastructure to build mind you.  :)

We've also considered the idea of speculating that functions don't throw 
and de-optimizing if it turns out they do.  We haven't implemented this 
yet, but on the surface, it sounds like a pretty good idea.  Note that 
you'd need a recompilation mechanism to support the best use of this.


>
> I'm also curious about why libgcc is slow on dynamically generated 
> tables, and if that's still true with MCJIT (I assume the VMKit change 
> was made while on the old JIT).
I don't know the answer to this.  I'm not familiar with the mechanism 
the old JIT provided in this area.

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140502/c7224bcf/attachment.html>