CODEWITHSUNDEEP
javascript
Mark Nguyen
Mark Nguyen

Reputation: 7448

Garbage collector: deleting a reference to an object that has references to another object

From what I understand, the JS garbage collector removes objects that are no longer referenced. Suppose I remove a reference to an object and that object has a property which is a reference to another object. Will both objects be removed?

e.g 

var objectA = {
    prop1: "property",
    prop2: "property"
}

var objectB = {
    refToA: objectA
}

// Remove reference to objectA
delete objectA;

// Remove reference to objectB
delete objectB

Are both objects now completely removed from memory?

Upvotes: 2

Views: 675

Answers (1)

Elias Van Ootegem
Elias Van Ootegem

Reputation: 76413

Short answer: Yes. An object that isn't referenced anywhere is completely removed from memory, regardless of what is referenced by that objects properties.

In your snippet, things are fairly straightforward, though mem-management can get tricky when you start using closures:

var objA = (function()
{
    var objAb = {who:'An object literal in closure scope',globalReference:'None!'};
    return {who:'Return value, is an object literal that references a closure object'.
            closureObj : objAb};
})();
var objB = {who:'some object',objAb:{who:'object literal, referenced by objB.objAb'}};
var objBAb = objB.objAb;//reference to obj literal, referenced by objB.objAb
var objAb = objA.closureObj;//reference to obj literal, referenced by objA.closureObj, which in turn references the closure object literal

delete objB.objAb;
console.log(objBAb);//<-- the object literal that was declared as a property of objB still exists
delete objAb;//<-- this reference is gone, but the closure obj still exists 
console.log(objA.closureObj);//<-- object is there

Basically, objects are nameless entities. The variables used to access them are references, the never, ever contain the actual object itself. That floats around in JS-space. When you use delete someVar, all you do is unset the actual value of that variable, which is a memory address (sort of).

If the JS GC can't find any variables that reference a location in memory that contains an object, it will reclaim that memory.
It's as simple as that.

When you apply this logic to the following code:

var objA = (function()
{
    var closureObj = {iam:'An object literal defined inside a closure scope'};
    var functionsAreObjects = function()
    {//nameless function object, inside closure scope, too
        return closureObj;
    };
    var resetFunction = function()
    {
        this.closureReference = functionsAreObjects();//assign return value to this
    };
    return {iam:'The returned object literal',
            closureReference:closureObj,
            reset:resetFunction,
            getClosureReference:functionsAreObjects};
})();
delete objA.closureReference;//the closure object IS NOT GC'ed

In the previous example, the last delete statement would haven sufficed to GC the closure object literal. However, now objA has two methods (properties that reference function objects). These methods still reference the closure object, and are still referenced by objA, so the closureObj can't be GC'ed yet. So, this is where things get tricky:

delete objA.closureReference;
delete objA.reset;
delete objA.getClosureReference;

We've deleted all properties that can link back to the closureObj, so it stands to reason that it'll be GC'ed, right? --Erm, not quite. Chrome's V8 does deallocate the memory, but I've heard of similar code causing leaks in Opera, and it's not out of the realm of possibility's that perhaps IE will not excel at reclaiming the memory.

Also, we've effectively created a getter method with getClosureReference, so in real life, this is very likely to occur:

//do stuff
delete objA.closureReference;
var objB = objA.getClosureReference();//<-- created new reference to closure object
//do some more stuff
delete objA.reset;
delete objA.getClosureReference;

In this case, the closureObj can't be GC'ed, because it's still being referenced by objB somewhere. Only when that variable goes out of scope will closureObj be deallocated. Not only is this a very solid argument against global variables (they never go out of scope, and thus never get GC'ed), it also goes to show that closures, neat though they are, require some more overhead from the developer: letting a variable go out of scope doesn't necessarily mean the memory is freed: some closure could expose a reference to an object, or a function that references that object...

I've posted a question on this matter a while ago but it might explain a few things.
And just for fun, if you want an example of nested closures (closers in closures, in closures, passing references to each other, and other objects) try finding out when what can be GC'ed in the following code

Upvotes: 3

Related Questions