Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This may depend on the specific garbage collector, so an answer would depend on which JavaScript engine you're using.</p> <p>First, I'll note that the best application code does two things. It achieves its technical goals of functionality and performance, and it is resilient to change. Additional code should serve enough of a purpose to justify the added complexity.</p> <p>With that said, according to the <a href="https://developers.google.com/v8/design#garb_coll" rel="nofollow">Google's notes on V8</a>, which is the JavaScript engine used by Chrome,</p> <blockquote> <p>V8 reclaims memory used by objects that are no longer required in a process known as garbage collection. To ensure fast object allocation, short garbage collection pauses, and no memory fragmentation V8 employs a stop-the-world, generational, accurate, garbage collector. This means that V8:</p> <ul> <li>stops program execution when performing a garbage collection cycle.</li> <li>processes only part of the object heap in most garbage collection cycles. This minimizes the impact of stopping the application.</li> <li>always knows exactly where all objects and pointers are in memory. This avoids falsely identifying objects as pointers which can result in memory leaks.</li> </ul> <p>In V8, the object heap is segmented into two parts: new space where objects are created, and old space to which objects surviving a garbage collection cycle are promoted. If an object is moved in a garbage collection cycle, V8 updates all pointers to the object.</p> </blockquote> <p>Generational garbage collectors tend to move objects between heaps, where all live objects are moved into a destination heap. Anything not moved to the destination is considered to be garbage. It's not clear how the V8 garbage collector identifies live objects, but we can look at some other GC implementations for clues.</p> <p>As an example of the behavior of a well-documented GC implementation, Java's Concurrent Mark-Sweep collector:</p> <ol> <li>Stops the application.</li> <li>Builds a list of objects reachable from the application code.</li> <li>Resumes the application. In parallel, the CMS collector runs a "mark" phase, in which it marks transitively reachable objects as "not garbage". Since this is in parallel with program execution, it also tracks reference changes made by the application.</li> <li>Stops the application.</li> <li>Runs a second ("remark") phase to mark newly reachable objects.</li> <li>Resumes the application. In parallel, it "sweeps" all objects identified as garbage and reclaim the heap blocks.</li> </ol> <p>It's basically a graph traversal, starting at a set specific nodes. Since disconnected objects aren't accessible, their connectedness to other disconnected objects shouldn't come into play.</p> <p>There's a good, if somewhat dated, white paper on the way Java garbage collection works at <a href="http://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf" rel="nofollow">http://www.oracle.com/technetwork/java/javase/memorymanagement-whitepaper-150215.pdf</a>. Garbage collection isn't unique to Java, so I'd suspect some similarity between the various approaches taken by Java virtual machines and other runtimes such as JavaScript engines.</p> <p>Raymond Chen wrote a <a href="http://blogs.msdn.com/b/oldnewthing/archive/2012/01/05/10253268.aspx" rel="nofollow">blog post</a> that pointed out that walking memory that you're about to free can have a negative impact on performance. The context was around freeing memory manually on application shutdown. Since blocks could have been swapped to disk, the act of traversing references can cause those blocks to be swapped in. In this case, the program is doing a traversal of blocks that would have just been marked as available and left untouched.</p> <p>So in a situation where the OS may have swapped out some of the blocks, the act of "assisting" the garbage collector, especially on longer-lived objects, may end up slowing things down.</p> <p>And if you're not generating enough data to be concerned about swapping out, then a reasonable garbage collector wouldn't take long enough to notice.</p> <p>So chances are it's not worth the effort, and could be counterproductive. Although it probably makes sense to drop the references to the heap "dominators". These are the objects that, if collected, would allow the collection of many other objects. So drop the reference to the collection itself, but not to each item within the collection.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

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