Re: please review new branch feature/byte-unwind-protect

[Stefan Monnier]

> It's partly for efficiency -- I didn't benchmark it though.

I'd be interested to see some benchmarks, as well (e.g. comparing
old-unwind-protect vs new-unwind-protect vs prog1, where the prog1 case
is used as the "speed of light" reference).

> Also this seems like an un-finished to-do item from the lexical binding
> conversion.

Not exactly "unfinished", but yes, it's a good change.

> I don't think there's a cost to this change.

There's always costs:
- fewer bytecodes left.
- incompatility of .elc files.
- potentially slower execution (hopefully it's the reverse, but without
  measuring it, it's difficult to be sure).
- subtle changes (e.g. the debugger backtrace, or the behavior of
  called-interactively-p when called from within the 2nd part of an
  unwind-protect).
>From where I stand I think they're worth the trouble, tho it depends on
the benchmarks (I don't have a good intuition for the cost of setjmp,
mostly, so while I think/hope that it will make things faster, I'm not
completely sure).

BTW, when I wrote those FIXME, the implementation strategy I was thinking
of was:
- use byte-codes with a similar semantics to the ones you introduce.
- implement the pushunwindprotect by pushing onto the specpdl stack
  an entry that contains a reference to the bytecode stack and
  bytecode's pc (note: no setjmp).
- when running the unwind_protect during a non-local exit (i.e. from
  unbind_to), run the byte-code interpreter using that saved stack and pc.


        Stefan