Enclosure Memory Copies

Question

function myClass()
{
  //lots and lots of vars and code here.

   this.bar = function()
   {
     //do something with the numerous enclosed myClass vars
   }

   this.foo = function()
   {
      alert('Hello'); //don't do anything with the enclosed variables.
   }
}

Each instance of myClass gets its own copy of bar and foo, which is why prototyped methods use less memory. However, I would like to know more about the memory use of inner methods.

It seems obvious to me that (1) below must be true. Do you agree?

1. Not only do distinct myClass instances have their own distinct copies of bar, but they also must have their own distinct copies of the myClass enclosure. (or else how does the bar method keep the myClass variables straight on a per instance basis?)

Now (2) is the question I'm really after.

1. Since the inner foo method doesn't use anything in the myClass enclosure a natural qustion is: Is javascript smart enough to not keep a myClass enclosure in memory for the use of foo?

Answer 1

This will depend entirely on the implementation not the language. Naive implementations will keep far more around than others. Any answer that is true for e.g. V8 (chrome's JS engine) may not be true for Spidermonkey (Firefox's) or JScript (IE) etc...

In my experience (this is definitely how GHC handles closures), the actual code of the functions (inner or outer) only exists once, but an "environment" mapping variables to values must be kept around for the closure (bar), so no, I wouldn't expect the JS implementation to keep around more than one copy of MyClass, but it will keep around a copy of its environment at least with this.bar, sensible implementations might realize that no environment is actually needed foo is not actually a closure, and thus does not need to keep a copy of the environment from the call to MyClass however do not rely on this behaviour.

Especially since the behavior of JS's eval function which evaluates a string in the same lexical environemnt as the eval call, it is quite likely that JS implementations always keep the lexical environment around.

Answer 2

I'm reasonably certain that any function has the a pointer to the entire state. It's irrelevant whether it references any variables it still has access to them.

Of course you do release that both bar & foo point to the same "entire state" of the object. So it doesn't take any more memory. I guess you have to allocate one more pointer internally so you can point to the "entire state" of the object but optimising for something like that is silly.

Whether it optimises it away is javascript engine specific. By all means read the chromium source and find out.

I'll see if I can dig some quotes out of the spec for you.

Entering Function code from the spec:

10.4.3 Entering Function Code The following steps are performed when control enters the execution context for function code contained in function object F, a caller provided thisArg, and a caller provided argumentsList:

1. If the function code is strict code, set the ThisBinding to thisArg.
2. Else if thisArg is null or undefined, set the ThisBinding to the global object.
3. Else if Type(thisArg) is not Object, set the ThisBinding to ToObject(thisArg).
4. Else set the ThisBinding to thisArg.
5. Let localEnv be the result of calling NewDeclarativeEnvironment passing the value of the [[Scope]] internal property of F as the argument.
6. Set the LexicalEnvironment to localEnv.
7. Set the VariableEnvironment to localEnv.

That tracks your environment to NewDeclarativeEnvironment.

NewDeclarativeEnvironment

10.2.2.2 NewDeclarativeEnvironment (E) When the abstract operation NewDeclarativeEnvironment is called with either a Lexical Environment or null as argument E the following steps are performed:

1. Let env be a new Lexical Environment.
2. Let envRec be a new declarative environment record containing no bindings.
3. Set env’s environment record to be envRec.
4. Set the outer lexical environment reference of env to E.
5. Return env.

This tracks your environment to E which is the [[Scope]] of the function Object

13.2 Creating Function Objects Given an optional parameter list specified by FormalParameterList, a body specified by FunctionBody, a Lexical Environment specified by Scope, and a Boolean flag Strict, a Function object is constructed as follows:

1. Create a new native ECMAScript object and let F be that object.
2. Set all the internal methods, except for [[Get]], of F as described in 8.12.
3. Set the [[Class]] internal property of F to "Function".
4. Set the [[Prototype]] internal property of F to the standard built-in Function prototype object as specified in 15.3.3.1.
5. Set the [[Get]] internal property of F as described in 15.3.5.4.
6. Set the [[Call]] internal property of F as described in 13.2.1.
7. Set the [[Construct]] internal property of F as described in 13.2.2.
8. Set the [[HasInstance]] internal property of F as described in 15.3.5.3.
9. Set the [[Scope]] internal property of F to the value of Scope.
10. Let names be a List containing, in left to right textual or

Turn's out the spec is just telling you things you already know. Every functions contain the Scope. As the other poster mentioned it is upto individual implementation to "optimise" some of the scope away in terms of memory management.

If you ask me you really don't care about this unless you have >million instances of these objects.

The following block from the spec is more applicable:

The outer environment reference is used to model the logical nesting of Lexical Environment values. The outer reference of a (inner) Lexical Environment is a reference to the Lexical Environment that logically surrounds the inner Lexical Environment. An outer Lexical Environment may, of course, have its own outer Lexical Environment. A Lexical Environment may serve as the outer environment for multiple inner Lexical Environments. For example, if a FunctionDeclaration contains two nested FunctionDeclarations then the Lexical Environments of each of the nested functions will have as their outer Lexical Environment the Lexical Environment of the current execution of the surrounding function.

The two nested functions both have the same reference to the outer Lexical Environment