[LLVMdev] x86 unwind support[MESSAGE NOT SCANNED]

[Jeffrey Yasskin]

On Mon, Jul 20, 2009 at 7:43 AM, Nick
Johnson<nicholas.paul.johnson at gmail.com> wrote:
> On Mon, Jul 20, 2009 at 10:09 AM, Mark Shannon<marks at dcs.gla.ac.uk> wrote:
>> Andrew Haley wrote:
>> If you can make your point without any references to any C/C++ specific
>> features it might be more convincing ;)
>>
>
> I did.  Recall my mention of java/c#/ruby/python's finally/ensure
> blocks, or C#'s using blocks.  For proper implementation, these need
> multi-level unwinds, as they specify that some code must run, even if
> an exception would bail-out.
>
>> I take it you have never used Python ;)
>> (Python uses exceptions to terminate loops, so it helps if they aren't
>> too slow)
>
> I have used python, and it is slow (sorry).  In fact, python
> Exceptions are implemented in python as a second return value, thus
> EVERY function, even those which don't throw exceptions, must pay the
> price.  And just because the python community does it, doesn't mean
> it's good programming practice.

:)

Working on Unladen Swallow, we've considered whether to try to port
Python to use Dwarf unwinding. It's a fairly simple tradeoff: with
return-value-exceptions you get a small cost in both time (a
predictable branch) and code size at each call site, whether or not
the call site is inside a try, but you get pretty cheap exception
throwing and propagation. With dwarf-exceptions, you have a small
space cost at each invoke (for the dwarf metadata), no time cost at
calls that don't throw, but fairly expensive exceptions when you do
throw them. Because Python throws exceptions for ending loops and
garbage-collecting generators, we expect return-value-exceptions to be
cheaper overall. In languages that throw exceptions more rarely (just
about everyone), dwarf-exceptions should be cheaper. Dwarf-exceptions
will still be worth investigating for Python eventually; we're just
not prioritizing it. Anyone who wants us to prioritize it higher
should bring data. :)

IronPython's and Jython's experiences are interesting too. IronPython
has had big problems with the cost of exceptions on the .NET platform.
Jython has _not_ had problems in the JVM, which indicates that the two
big virtual machines have made different tradeoffs for this. That
would make me very hesitant to say that either option is obviously
wrong.

Jeffrey