Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Kevin Modzelewski <kmod <at> dropbox.com>
Subject: Question about implementing exceptions, especially to the VMKit team
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Thursday 1st May 2014 21:09:09 UTC (over 3 years ago)
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
> ef´Čücient 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
 
CD: 3ms