Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Eric Lippert wrote a <a href="http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx" rel="noreferrer"><strong>detailed blog post</strong></a> about this subject a while back (additionally comparing it to <em>VBScript</em>). More accurately, he wrote about <a href="http://en.wikipedia.org/wiki/Jscript" rel="noreferrer"><em>JScript</em></a>, 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.</p> <p>Quoted from that page:</p> <blockquote> <p>JScript uses a nongenerational mark-and-sweep garbage collector. It works like this: </p> <ul> <li><p>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.</p></li> <li><p>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 them.)</p></li> <li><p>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 post.)</p></li> <li><p>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.</p></li> </ul> </blockquote> <p>The main purpose of garbage collection is to allow the programmer <em>not</em> 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.</p> <p>There are a few particular points of which to be aware. The Apple developer site has <a href="http://developer.apple.com/safari/library/documentation/ScriptingAutomation/Conceptual/JSCodingGuide/Advanced/Advanced.html" rel="noreferrer"><strong>some guidelines</strong></a> on the matter. Two important ones from there:</p> <ul> <li>Use delete statements. Whenever you create an object using a new statement, pair it with a delete statement. This ensures that all of the memory associated with the object, including its property name, is available for garbage collection. The delete statement is discussed more in “Freeing Objects.”</li> <li>Use the var keyword. Any variable created without the var keyword is created at the global scope and is never eligible for garbage collection, presenting the opportunity for a memory leak.</li> </ul> <p>I would imagine that the practices should apply to all JavaScript engines (in different browsers), though because this is from an Apple site, they <em>may</em> be somewhat specific to Safari. (Perhaps someone could clarify that?)</p> <p>Hope that helps.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload