Memory management and hunting leakage in JavaScript

Garbage Collection

It is the process by which the program performs automatic memory management by reclaiming the memory occupied by objects that are no longer used in the program. An object when created uses memory which remains allocated until there are references for that object. The automatic accomplishment of freeing up memory occurs when these objects are considered not in use anymore, which is garbage collection, simply, destroying unused objects.

On the other hand, Manual Memory Management refers to the usage of instruction explicitly by programmers to deallocate the memory. In C programming, developers need to take care of memory allocation and deallocation using malloc() and deallocate() functions.

In Javascript, as no interface is exposed to memory management, all the memory management is relinquished to the user. It is garbage collection.

Memory Scheme in NodeJs

Memory Management in NodeJs is done via V8: ‘Google’s open-source high-performance JavaScript and WebAssembly engine’. The total memory allocated for program execution is Resident Set. This is further divided into the following segments

Fig. Memory scheme in V8

Code: The actual code being executed.

Stack: Static data including method, primitive values, and pointers defining control flow of the program and pointers to object in the heap are stored here.

Heap: A memory segment where V8 stores objects or dynamic data. Heap is the biggest memory block dedicated to storing reference types like objects strings and closures where Garbage Collection (GC) takes place.

It has two main sections:
New Space: The size of the new space is ~1–8MB and objects residing here are called New Generation.

Old Space: Objects which have survived two scavenge collections now are shifted from New space to Old Space and called Old Generation.

After certain old space memory is allocated, expensive Garbage collection (Mark-Sweep and Mark-Compact) occur. To get basic info on memory usage in our program, let us execute the following code in NodeJs program:

process.memoryUsage();

The output is:
 {
   rss: 365801472,
   heapTotal: 94416896,
   heapUsed: 79383696,
   external: 351234
 }

Sources of Memory Leakage

Memory leakage is defined as a situation when the memory not needed by the program is not returned to the operating system or pool of free memory.

1.Closures

Let us consider the following memory leakage meteors developers founded.

var theThing = null;

const replaceThing = function () {
  var originalThing = theThing;

  var unused = function () {
    if (originalThing)
      console.log("hi");
  };

  theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log(someMessage);
    }
  };
};
setInterval(replaceThing, 1000);

Explanation

In JavaScript, closure gives you access to the scope of outer function from an inner function. The inner function will have access to vars and parameters of the outer function. In the above example, functions defined inside replaceThing i.e. function someMethod and function unused shares the same parent scope.

Variable originalThing is only referenced from function unused. Function unused itself gets cleaned up when replaceThing is executed. However, the second closure someMethod will not get cleaned up, as it can be referenced from theThing which is in the global scope. As we can see someMethod do not refer to originalThing at all but still, orginalThing is not garbage collected. Why? Well, the typical way that closures are implemented is that every function object has a link to a dictionary-style object representing its lexical scope.

As soon as a variable is used by any closure, it ends up in the lexical environment shared by all closures in that scope. As somemethod shares closure scope with unused, the reference unused has to originalThing forces it to stay active. This prevents its collection.

2. Accidental global variables

Undeclared variables in JavaScript create the new variable inside the global object.

function foo(arg) {
    bar = "this is hidden global variable";
}
// is equivalent to:
function foo(arg) {
    window.bar = "this is explicit global variable";
}

In the case of the browser, the global object is “window”. In the NodeJs, a root node is typically the object “global” or “process”. The variable bar can never be collected as it is defined in the global scope introducing memory leakage.

3. Forgotten callBacks or timers

var someResource = getData();
setInterval(function() {
  var node = document.getElementById('domode');

  if(node) {
    node.innerHTML = JSON.stringify(someResource));
  }
}, 1000);

The whole block inside the interval handler becomes unnecessary if the node variable is unused. The handler cannot be collected as intervals are active and cause memory leakage.

4. Out of DOM Reference

var elements = {
  button: document.getElementById('button'),
  image: document.getElementById('image'),
  text:document.getElementById('text')
};
function doStuff() {     
  image.src = 'http://some.url/image';     
  button.click();     
}  
function removeButton() {
  // The button is a direct child of body.
  document.body.removeChild(document.getElementById('button'));
  // still have reference to button in global elements dictionary
  // cannot be garbage collected
}

Explanation
The button element is still in the dictionary and cannot be collected by garbage collection due to the reference to the button.

Let us consider a scenario: A HTML table is composed of many trs and tds. Removing the table from the DOM but keeping the tds reference to the cell, the GC will not collect everything. In fact, the table still remains in memory. The tds keeps the reference to the table and cannot be garbage collected. In other words, the reference to the table cell from the javascript code allows the table to remain in the memory.

5. Older Browsers and Buggy Extensions

Older browsers(IE6–7) were infamous for creating memory leakage as it could not handle circular reference between DOM objects and JavaScript Objects. Sometimes faulty browser extension may introduce memory leakage.

6. Event listeners & Caches

When the DOM element and its corresponding event listener don’t have the same lifecycle, it could lead to a memory leak. Caches that grow unbounded size can result in high memory consumption and can lead to memory leakage. Garbage Collection Mechanism

Garbage Collection phases:

The garbage collection occurs in two phases:

Scavenge

Memory allocation in the new space is cheap. The allocation pointer is increased when we want space in a new space. When this allocation pointer exceeds a certain limit, the scavenge algorithm is triggered quickly removing dead objects.

Mark, Sweep, and Compact Phase

The size of old space may exceed hundreds of MegaBytes and less frequent mark-sweep and mark-compact run over this space. The behavior of program and old space size shifts this garbage collection. Simply, objects are marked as “alive” or “dead” and the “dead” objects are removed followed by compacting memory for optimization.

Mark Phase: V8 uses three marking schemes namely:
White: undiscovered object,
Gray: object discovered, but its neighbors have not been discovered
Black: object and all of its neighbors discovered.

Sweep Phase: Memory of white (“dead”) objects are released.

Compact Phase: Memory organization proceeds in this phase for faster memory access, migrating objects from fragmented pages to the beginning of the memory region.

Traditional garbage collection implements Stop the World garbage collection where the program will be halted during the garbage collection.

Ornico — garbage collector in V8 Engine

It deploys parallel, incremental, and concurrent mechanisms in order to free the main thread.

Fig. V8 Ornico logo

Parallel: Still, Stop-the-world mechanism, where helper threads are introduced and roughly do equal amounts of work at the same time. The total pause time is divided by the number of threads introduced (plus some synchronization time).

Concurrent: The main thread is totally free to execute Javascript and helper threads to Garbage collection in the background.

Lazy/Incremental: This proceeds in a series of incremental pauses where the small part of the total work required is proceeded at once. The total amount of time spent in the main thread is not reduced, however, it spreads over time.

Hunting Memory Leakage

1. Using Node Inspector

Let us start our application in inspection mode:

node --inpsect=9229 index.js 

On the Chrome browser open:

chrome://inspect

Fig. Inspecting through Chrome Browser

After clicking inspect, dedicated Dev Tools will open as follows. Under Memory -> Profile, Click Take snapshot .

Fig. Taking Heap snapshot

Summary View

Fig. Summary view

This view is particularly helpful for tracking down DOM leaks. When the elements have been removed from DOM but their memory is retained due to reference in Javascript it causes DOM leakage. For source code refer here.

The constructor represents all objects created using this constructor.
Shallow size is the memory size that is held by the object itself.
Retained size is the memory size that is freed up once the object is deleted along with its’ dependent object.
Distance displays the distance to the root using the shortest simple path of nodes.

Comparison View

Fig. Comparision view

It is used to record and compare two (or more) memory snapshots and perform the comparison. Presence of delta in freed memory and reference count lets you confirm the presence and cause of memory leak which can be further drilled down:

Heap Comparision

Fig. Heap Comparision details

Containment View provides a better view of object structure allowing to dive into a low level.

Dominators View helps confirm that no unexpected references to objects are still hanging around (i.e that they are well contained) and that deletion/garbage collection is actually working.

2. Using Heap Dump Module and Loading

Alternatively, heapdump module allows taking a heap snapshot.

const heapDump = require('heapdump');
function writeSnapShot() {
  heapDump.writeSnapshot(function (err, filename) {
   console.log('dump written to', filename);
 });
}; 
module.exports = writeSnapShot;

Load the snapshot file in the Chrome Browser and proceed analysis as before.

Fig. Loading heap snapshot

3. Allocation Sampling / Timelines

Allocation over time series can be viewed through allocation profiling. Select the allocation instrumentation on timeline .

Fig. Selecting Allocation instrumentation in Timeline mode

The output is:

Fig. Allocation sampling details

The blue bars show up representing new memory allocations which are a candidate for your memory leakage. Click on the blue line to view the details on allocation profiling occurring at that time.

4. Timeline View

For UI tracking, a timeline view may be helpful.
In Chrome Dev Tools: Select Performance → Enable memory checkbox → Make the Recording.
Tip: Start Recording after forced garbage collection from by clicking collect garbage button.

The output is:

Fig. Timeline view

Fig. Magnified Timeline view

The blue line indicates javascript heap memory and the range consumed by the program within the sampling period is also specified. When clicked in the section of the broken blue line (memory usage), it is showing either Major GC and minor GC. As we can see that minor GC is occurring frequently than major GC.

The Greenline indicates the number of HTML nodes in the document. This increased HTML nodes in the program indicate the possibility of unreferenced DOM nodes that it is unable to be collected by GC causing memory leakage.

5. Command-line options

Node provides different command-line options to dig deeper into garbage collection. Consider the following command line:

node --expose-gc --trace-gc index.js

trace-gc: shows trace line following each garbage collection.
expose-gc: enables to call global.gc() to force the node to run garbage collection.
For more of the command-line text refer here.

6. Cloud Services and NPM Packages

Cloud services like GCP (Cloud Profiler)provide info of JavaScript heap details. Different npm packages are available that traces the garbage collection.

References

https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/

https://developers.google.com/web/tools/chrome-devtools/memory-problems

https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/

https://blog.risingstack.com/node-js-at-scale-node-js-garbage-collection/

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management