javascript V8 optimisation and “leaking arguments”

Question

I read in various places that it's advisable to be careful with the arguments object and that this is ok...

    var i = arguments.length, args = new Array(i);
    while (i--) args[i] = arguments[i];

But, is this ok or not?...

function makeArray (l) {
    var i = l.length, array = new Array(i);
    while (i--) array[i] = l[i];
    return array;
};
//...
//EDIT: put the function on an object to better represent the actual case
var o = {};
o.f = function (callback) {
    var args = makeArray (arguments);
    callback.apply(args[0] = this, args);
};

What is meant by "leaking arguments" and how does it affect optimisation?

I am focused on V8, but I assume it applies to other compilers as well?

to prove it works...

function makeArray (l) {
    var i = l.length, array = new Array(i);
    while (i--) array[i] = l[i];
    return array;
};
//...
//EDIT: put the function on an object to better represent the actual case
var o = {};
o.f = function (callback) {
    var args = makeArray (arguments);
    callback.apply(args[0] = this, args);
};
o.m = "Hello, ";
function test(f, n) {
    alert(this.m + " " + n)
}
o.f(test, "it works...")

Answer 1

The problem with arguments is same as with local eval and with: they cause aliasing. Aliasing defeats all sorts of optimizations so even if you enabled optimization of these kind of functions you would probably end up just wasting time which is a problem with JITs because the time spent in the compiler is time not spent running code (although some steps in the optimization pipeline can be run in parallel).

Aliasing due to arguments leaking:

function bar(array) {    
    array[0] = 2;
}

function foo(a) {
    a = 1;
    bar(arguments);
    // logs 2 even though a is local variable assigned to 1
    console.log(a);
}
foo(1);

Note that strict mode eliminates this:

function bar(array) {    
    array[0] = 2;
}

function foo(a) {
    "use strict";
    a = 1;
    bar(arguments);
    // logs 1 as it should
    console.log(a);
}
foo(1);

Strict mode however isn't optimized either and I don't know any reasonable explanation except that benchmarks don't use strict mode and strict mode is rarely used. That might change since many es6 features require strict mode, otoh arguments is not needed in es6 so...

Answer 2

This is a 2-fold problem:

1. You lose any and all possible optimizations and branch predictions
   The arguments object is unpredictible.
2. You leak memory. Really bad!

Consider the following code (run it at your own risk!):

function a(){return arguments;}

x=a(document.getElementsByTagName('*'));

window._interval=setInterval(function(){

    for(var i=0;i<1e6;i++)
    {
        x=a(x);
    }
},5000);

*{font-family:sans-serif;}

<p>Warning! This may overheat your cpu and crash your browser really badly!</p>

<p>I'm not responsible for any software and hardware damages!</p>

<p><b>Run at your own risk!!!</b></p>

<p>If you ran this code, press F5 to stop or close the browser.</p>

<p>If you want, you can try to <button onclick="window.clearInterval(window._interval);window.x='';">stop it</button>. (the RAM may remain unchanged)</p>

And now watch your RAM go up, when you run that (it goes up at a rate of around 300-500MB every 5 seconds).
A naive implementation that simply passes the arguments around may cause these problems.

Not to mention that your code will (generally) be a tad slower.

---

Note that this:

function a(){return arguments;}
function b(arg){return arg;}

x=a(document.getElementsByTagName('*'));

window._interval=setInterval(function(){

    for(var i=0;i<1e6;i++)
    {
        x=b(x);
    }
},5000);

*{font-family:sans-serif;}

<p>This may be safe, but be careful!</p>

<p>I'm not responsible for any software and hardware damages!</p>

<p><b>Run at your own risk!!!</b></p>

<p>If you ran this code, press F5 to stop or close the browser.</p>

<p>If you want, you can try to <button onclick="window.clearInterval(window._interval);window.x='';">stop it</button>.</p>

Won't have the same effect as the code before.
This is because b() returns the same variable, instead of a new reference to a new arguments object.
This is a very important difference.