What is JavaScript garbage collection? – Dev

The best answers to the question “What is JavaScript garbage collection?” in the category Dev.


What is JavaScript garbage collection? What’s important for a web programmer to understand about JavaScript garbage collection, in order to write better code?


Beware of circular references when DOM objects are involved:

Memory leak patterns in JavaScript

Keep in mind that memory can only be reclaimed when there are no active references to the object. This is a common pitfall with closures and event handlers, as some JS engines will not check which variables actually are referenced in inner functions and just keep all local variables of the enclosing functions.

Here’s a simple example:

function init() {
    var bigString = new Array(1000).join('xxx');
    var foo = document.getElementById('foo');
    foo.onclick = function() {
        // this might create a closure over `bigString`,
        // even if `bigString` isn't referenced anywhere!

A naive JS implementation can’t collect bigString as long as the event handler is around. There are several ways to solve this problem, eg setting bigString = null at the end of init() (delete won’t work for local variables and function arguments: delete removes properties from objects, and the variable object is inaccessible – ES5 in strict mode will even throw a ReferenceError if you try to delete a local variable!).

I recommend to avoid unnecessary closures as much as possible if you care for memory consumption.


Eric Lippert wrote a detailed blog post about this subject a while back (additionally comparing it to VBScript). More accurately, he wrote about JScript, which is Microsoft’s own implementation of ECMAScript, although very similar to JavaScript. I would imagine that you can assume the vast majority of behaviour would be the same for the JavaScript engine of Internet Explorer. Of course, the implementation will vary from browser to browser, though I suspect you could take a number of the common principles and apply them to other browsers.

Quoted from that page:

JScript uses a nongenerational
mark-and-sweep garbage collector. It
works like this:

  • Every variable which is “in scope”
    is called a “scavenger”. A scavenger
    may refer to a number, an object, a
    string, whatever. We maintain a list
    of scavengers — variables are moved
    on to the scav list when they come
    into scope and off the scav list when
    they go out of scope.

  • Every now and then the garbage
    collector runs. First it puts a
    “mark” on every object, variable,
    string, etc – all the memory tracked
    by the GC. (JScript uses the VARIANT
    data structure internally and there
    are plenty of extra unused bits in
    that structure, so we just set one of

  • Second, it clears the mark on the
    scavengers and the transitive closure
    of scavenger references. So if a
    scavenger object references a
    nonscavenger object then we clear the
    bits on the nonscavenger, and on
    everything that it refers to. (I am
    using the word “closure” in a
    different sense than in my earlier

  • At this point we know that all the
    memory still marked is allocated
    memory which cannot be reached by any
    path from any in-scope variable. All
    of those objects are instructed to
    tear themselves down, which destroys
    any circular references.

The main purpose of garbage collection is to allow the programmer not to worry about memory management of the objects they create and use, though of course there’s no avoiding it sometimes – it is always beneficial to have at least a rough idea of how garbage collection works.

Historical note: an earlier revision of the answer had an incorrect reference to the delete operator. In JavaScript the delete operator removes a property from an object, and is wholly different to delete in C/C++.


To the best of my knowledge, JavaScript’s objects are garbage collected periodically when there are no references remaining to the object. It is something that happens automatically, but if you want to see more about how it works, at the C++ level, it makes sense to take a look at the WebKit or V8 source code

Typically you don’t need to think about it, however, in older browsers, like IE 5.5 and early versions of IE 6, and perhaps current versions, closures would create circular references that when unchecked would end up eating up memory. In the particular case that I mean about closures, it was when you added a JavaScript reference to a dom object, and an object to a DOM object that referred back to the JavaScript object. Basically it could never be collected, and would eventually cause the OS to become unstable in test apps that looped to create crashes. In practice these leaks are usually small, but to keep your code clean you should delete the JavaScript reference to the DOM object.

Usually it is a good idea to use the delete keyword to immediately de-reference big objects like JSON data that you have received back and done whatever you need to do with it, especially in mobile web development. This causes the next sweep of the GC to remove that object and free its memory.


Good quote taken from a blog

The DOM component is “garbage collected”, as is the JScript component, which means that if you create an object within either component, and then lose track of that object, it will eventually be cleaned up.

For example:

function makeABigObject() {
var bigArray = new Array(20000);

When you call that function, the JScript component creates an object (named bigArray) that is accessible within the function. As soon as the function returns, though, you “lose track” of bigArray because there’s no way to refer to it anymore. Well, the JScript component realizes that you’ve lost track of it, and so bigArray is cleaned up–its memory is reclaimed. The same sort of thing works in the DOM component. If you say document.createElement('div'), or something similar, then the DOM component creates an object for you. Once you lose track of that object somehow, the DOM component will clean up the related.