April 10 2014 Meeting Notes

[Filip Pizlo]

>> On Apr 25, 2014, at 7:07 AM, Andreas Rossberg <rossberg at google.com> wrote:
>> 
>>> On 25 April 2014 00:16, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>>> On Apr 24, 2014, at 2:33 PM, Mark S. Miller wrote:
>>> 
>>> Excellent. Given that, how realistic is the performance concern for the non-exceptional situation? Where is the overhead?
>> 
>> the body of the for-of loop could directly or indirectly throw an exception or contain a break.The break can presumably be statically detected and cleanup handled by the break logic.  But the loop still needs the equivalent of a finally around it, just in case an exception is thrown from the body.  It's hander needs to invoke @@return on the generator.
>> 
>> The point of debate is the cost of setting up that finally-equivalent, potentially for every for-of loop. The argument is that for some/most(??) current implementations there is significant runtime overhead to this setup.
> 
> The broader argument is that this cost is imposed on the common use
> case and has to be weighed against the utility it adds for a case that
> is (1) rare, and (2) not well-motivated according to some participants
> of the discussion (e.g., it's not necessarily a good idea to rely on
> finally-blocks for scarce resource management in the first place,
> since they provide only weak guarantees either way).
> 
>> The contra argument is that there are technique that have zero to very low setup costs and that implementations may need to evolve to use them.
> 
> To be sure, AFAICT none of these techniques have been demonstrated in
> a JS-like language. Even in C++ land they have been a pipe dream for a
> long time.

Try-catch is free in Java unless you throw. I wouldn't compare to C++ because current C++ implementations are limited by things like ABI standards. All JS-like languages are still in the baby stage of VM development; it's unfair to extrapolate future performance from current performance given how quickly things are changing. 

It's just a matter of common sense that JS implementations move to totally-free entry/exit into try-catch and a sensible cost model for when you throw, regardless of how this proposal goes. The fact that either of these things is a performance cliff is simply a bug and it will likely be fixed soon, given the pace of JS VM evolution.

So I wouldn't let these performance concerns hold up figuring out the right semantics. 

-Filip