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

[Gaël Thomas]

Hi Kevin,

I have beginning a new implementation of exception in VMKit with the
dwarf exception tables. Unfortunately, I have not finished yet, so I
can not answer :) I'm pretty sure that, today, dwarf is a better
solution than our test after each method invocation. But I don't have
any evidence for that...

Anyway, using the dwarf exception tables with VMKit is not so
complicated, so you can also try. If you need help, just tell me.
Basically, I have not yet exhaustively tested them (at least, it
works), mainly because I'm re-writting all VMKit to use MCJIT!

Gaël



2014-05-01 23:09 GMT+02:00 Kevin Modzelewski <kmod at dropbox.com>:
> 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.
>
> 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).
>
> thanks,
> kmod



-- 
-------------------------------------------------------------------
Gaël Thomas, Associate Professor, UPMC
http://pagesperso-systeme.lip6.fr/Gael.Thomas/
-------------------------------------------------------------------