Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How does garbage collection work in JavaScript?

How does garbage collection work in JavaScript? Is it similar to .NET garbage collection? And is it because the implementation of garbage collection in VBScript is bad that people avoided it and established a preference for JavaScript as their standard client-side language?

like image 336
Ali Tarhini Avatar asked Dec 01 '10 12:12

Ali Tarhini


People also ask

How does garbage collection work in JS?

Some high-level languages, such as JavaScript, utilize a form of automatic memory management known as garbage collection (GC). The purpose of a garbage collector is to monitor memory allocation and determine when a block of allocated memory is no longer needed and reclaim it.

Is there a garbage collector in JavaScript?

There's a background process in the JavaScript engine that is called garbage collector. It monitors all objects and removes those that have become unreachable.

How does a garbage collection work?

In the common language runtime (CLR), the garbage collector (GC) serves as an automatic memory manager. The garbage collector manages the allocation and release of memory for an application. For developers working with managed code, this means that you don't have to write code to perform memory management tasks.

How do I force garbage collection in JavaScript?

You can't force garbage collection (not in any sane fashion). If your variables aren't going out of scope automatically, just set them to null . Show activity on this post. Best advice is to define them in scope that makes them eligible for garbage collection.


1 Answers

How does garbage collection work?

The short answer is: When a block of memory (an object, say) is no longer reachable, it is eligible to be reclaimed. When, how, or whether it is reclaimed is entirely up to the implementation, and different implementations do it differently. But at a language level, it's automatic.

For example:

function foo() {     var bar;      bar = new ReallyMassiveObject();     bar.someCall(); } 

When foo returns, the object bar points to is automatically available for garbage collection because there is nothing left that has a reference to it.

Contrast with:

function foo() {     var bar;      bar = new ReallyMassiveObject();     bar.someCall();     return bar; } // elsewhere var b = foo(); 

...now a reference to the object survives the call, and persists until/unless the caller assigns something else to b or b goes out of scope.

Also contrast with:

function foo() {     var bar;      bar = new ReallyMassiveObject();     bar.someCall();     setTimeout(function() {         alert("Three seconds have passed");     }, 3000); } 

Here, even after foo returns, the timer mechanism has a reference to the timer callback, and the timer callback — a closure — has a reference to the context where it was created, which in turn contains the bar variable. As a result, in theory, what bar refers to isn't available for garbage collection immediately when foo returns. Instead, it's kept around until the timer fires and releases its reference to the callback, making the callback and the context it refers to eligible for GC. (In practice, modern JavaScript engines can and do optimize closures where they can. For instance, in the above, static analysis shows the callback doesn't refer to bar, and doesn't contain any eval or new Function code that might refer to it dynamically at runtime, so the JavaScript engine can safely leave bar out of the context the function refers to, thus making what it refers to eligible for GC — and modern ones do). (More about closures in this article.)

JavaScript has no problem handling cleaning up circular references, btw, so for instance:

function foo() {     var a, b;      a = {};     b = {};     b.refa = a;     a.refb = b; } 

When foo returns, the fact that a is referring to b and vice-versa isn't a problem. Since nothing else refers to either of them, they can both get cleaned up. On IE, this is not true if one of the objects is a host-provided object (such as a DOM element or something created via new ActiveXObject) instead of a JavaScript object. (So for instance, if you put a JavaScript object reference on a DOM element and the JavaScript object refers back to the DOM element, they keep each other in memory even when no one is referencing either of them.) But that's an IE bugissue, not a JavaScript thing.

Re:

is it because the vbscript GC is bad that people reverted to javascript as their standard client side api?

JavaScript was the original client-side web scripting language. VBScript only came later, when Microsoft came out with a browser, and was only ever supported in Microsoft browsers. JavaScript was and is the only client-side scripting game in town if you want to work with the broadest range of browsers. <subjective>It's also about eight times the language classic VBScript ever was. ;-) </subjective>

like image 61
T.J. Crowder Avatar answered Sep 21 '22 08:09

T.J. Crowder