gistfile1.md

Right now, the issue with the arguments object is basically the following:

• Arguments object is not actually allocated in optimized code. Element accesses and access to arguments.length are translated into loading from the stack.
• This means, you can't touch the stack while the arguments object is alive, because touching the stack would break this optimization (this is why, function calls with the arguments object as a parameter are not allowed, it can't be pushed to the stack).

Rest parameters, currently, do not implement this optimization. So they will always allocate an array (and the array allocation is always done in C++, which is not ideal).

This means, if we can enable optimized code to use rest parameters (I had trouble getting Crankshaft to work, although TurboFan happily just builds the array like it's supposed to), there's no problem passing it to other functions or using methods from Array.prototype.

Of course, if we did avoid allocating an actual object, and just used the stack load strategy, then you'd see the same deopt issues. It's probably better to just make allocation fast, so that you get a useful object all the time.

It's probably better to just make allocation fast, so that you get a useful object all the time.

Unless we know statically that both the rest array and arguments object never leaks, and methods of the rest array are never invoked, in which case why not

Is that specific static analysis already being done on V8?

@ruimarinho sort of.

Crankshaft will abort optimization if arguments is returned from a function, or pushed to the stack, so you end up falling back to the baseline code for the entire function. Baseline code will allocate a proper object, and can actually do this pretty quickly, but you still lose the optimizations that would otherwise be applied to the function.

But, there's no such analysis for rest parameters, and it's not clear that it's worth avoiding allocation. Making allocation fast seems like the best case scenario