<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 05/01/2014 02:09 PM, Kevin
Modzelewski wrote:<br>
</div>
<blockquote
cite="mid:CAO=oM6sLBRVWahXvjTRL_oiZgzUqs705EugMKsZSeV=AmgOgKw@mail.gmail.com"
type="cite">
<div dir="ltr">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
<div>
<br>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The
exception manager: To manage exceptions, J3 reserves a<br>
word for the pending exception in the local storage of
each thread.<br>
After each method invocation, the word is tested. If an
exception<br>
has been raised and the function is able to trap the
exception, a<br>
branch to the exception handler is executed. Otherwise,
the function<br>
returns to the caller. This implementation is not optimal
because it<br>
requires a test and branch after each method invocation. A
more<br>
efficient implementation would use exception tables.
However, at<br>
time of writing the paper, the exception tables generated
by LLVM<br>
rely on the GCC runtime library [19] which is not
optimized for<br>
dynamically generated tables, at least on Linux.</blockquote>
</div>
<div><br>
</div>
<div>So now I'm reexamining whether C++-style exceptions are a
good choice for Python, which I would guess throws more
exceptions than Java.</div>
</div>
<div><br>
</div>
<div style="">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.</div>
</div>
</blockquote>
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. <br>
<br>
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. :)<br>
<br>
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. <br>
<br>
<br>
<blockquote
cite="mid:CAO=oM6sLBRVWahXvjTRL_oiZgzUqs705EugMKsZSeV=AmgOgKw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div style=""><br>
</div>
<div style="">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).</div>
</div>
</blockquote>
I don't know the answer to this. I'm not familiar with the
mechanism the old JIT provided in this area. <br>
<br>
Philip<br>
</body>
</html>