6

I understand that closures keep the execution context alive by saving a reference to the executed function.

I'm wondering whether the whole context is saved or only the required parts.
In the former case I need to structure the functions in a way that no memory is wasted. This should be the design goal anyway, but I would like to know if JavaScript takes care of it, too.

Here's a simple example (on the basis of Single Page Web Applications, Mikowski/Powell, p. 56):

var ctx;
var outer_function = function () {
    var dummy = 'not required for output';
    var output = 'output';
    var inner_function = function () {
        return { output: output };
    }
    return inner_function;
};

ctx = outer_function();
// returns { output: 'output' }
ctx();

Is the dummy object stored in the closure after the execution of outer_function even though it is not accessible and won't be used?

Peopleware
  • 1,329
  • 1
  • 25
  • 39
  • 2
    Probably similar http://stackoverflow.com/a/864549/575527 – Joseph Jan 11 '16 at 13:30
  • I guess `dummy` is not stored. I might be wrong but to satisfy a closure, that variable must be referenced in a function. This reference marks it to be kept alive. – Rajesh Jan 11 '16 at 13:39
  • As fas as i know, the whole (engine-internal) Object is stored, that holds all the variables from a particular scope is "stored". But this might be differentiate between the particular JS-Engines. – Thomas Jan 11 '16 at 13:55
  • @Rajesh I had the same guess, that's why I'm asking. The answer linked by Joseph suggests the opposite. But that was a couple of years ago, maybe something's changed. – Peopleware Jan 11 '16 at 13:57
  • Related to http://stackoverflow.com/questions/35000424 – Peopleware Feb 05 '16 at 10:42

2 Answers2

5

We can see that Chrome eliminates unused variables (unless there is a direct eval call). Consider the following code (here's a fiddle to follow along with):

var bar = function() {
    var hello = "world";
    var unused = "nope";
    return function(s) { console.log(hello); debugger; return s; };
}
var g = bar();
g(1);

bar returns a function that has access to the inner variables hello and unused. The variable hello is used inside of the returned function, but unused is not. unused is entirely inaccessible after the termination of bar.

When we run this code with Dev Tools already open (to break on the debugger statement), we see:

Dev Tools shows that "Closure" scope only includes <code>hello</code>

We see that only hello has survived in the Closure scope. unused has disappeared. We can confirm this by going to the console (while the code is still paused) and seeing that hello is defined but accessing unused produces a ReferenceError.

This is the fundamental principle of garbage collection in action: if a variable becomes completely inaccessible, it should be freed. No one specified that JavaScript engines must free completely inaccessible variables, but it's an obvious performance win that is indistinguishable (in language-completeness terms) from not garbage collecting unused variables.

However, direct calls to eval can access otherwise inaccessible variables. If we modify our returned function to include a direct call to eval...

var foo = function() {
    var hello = "world";
    var unused = "nope";
    return function(s) { console.log(hello); debugger; return eval(s) };
}
var f = foo();
f(1);

We see that all local Closure-scope variables are now preserved:

"Closure" scope includes <code>hello</code>, <code>unused</code>, and <code>arguments</code>

This is because the environment cannot safely garbage collect any local variables, e.g., for fear that eval(s) might evaluate to unused.

You might wonder: how can the engine reliably detect the existence of eval calls? Couldn't you do something like window["ev"+"al"](s) instead, in a way that the engine can't reliable detect? The answer is that such an "indirect" eval call does not have access to closure-scope variables and executes in the global scope. Only direct calls that use the identifier eval as part of a function call can access local variables, and that's easy to detect.

If you're interested in learning more about direct eval calls, see my answer on global.eval is not able to visit variables in the lexical scope.

Incidentally, this is one of the main performance-based reasons why "eval is evil". The presence of a single direct call to eval in your code prevents the entire closure from being garbage-collected.

Community
  • 1
  • 1
apsillers
  • 107,868
  • 16
  • 221
  • 236
0

If you put an eval statement inside the closure, you can access the closure-scope variables by their name even if they weren't used inside the closure. EDIT: as apsillers points out in the comments, browsers could probably optimise away unused variables EXCEPT if there's an eval statement inside the closure, in which case everything must be kept. It doesn't mean they do, but it's possible.

var ctx;
var outer_function = function (code) {
    var dummy = 'not required for output';
    var inner_function = function () {
        return { output: eval(code) };
    }
    return inner_function;
};

ctx = outer_function('dummy');
ctx(); // { output: 'not required for output'}
Domino
  • 5,681
  • 32
  • 55
  • 1
    I believe `eval` is the *only* edge case like this, and engines can check for check for any instance of `eval` specifically. Only "direct" calls to `eval` can access closure-scoped variables (e.g., `window["ev"+"al"](...)` is not a direct call and has its code placed in a global scope, rather than the local scope) so it's possible to detect the existence of an `eval` that can access local vars pretty easily. – apsillers Jan 11 '16 at 14:14
  • @apsillers Yeah, I guess you're right. And then if there's an eval the engine will have no way to tell which variables it should keep so it would keep everything. I'll edit that in. – Domino Jan 11 '16 at 14:23
  • On a side note, you can pass `'code'` to `outer_function` and it will eval to `'code'`. It amuses me. That's because parameters are also closure-scope variables. – Domino Jan 11 '16 at 14:26