Why Node.js VM Contextify Causes Memory Bloat and How to Fix It

Cause

Previously the TMS service suffered from high CPU and memory usage, requiring frequent restarts. Two main reasons were identified: a buggy html‑minifier that loops on malformed HTML, and misuse of the VM module that prevents memory from being released.

VM (Virtual Machine) Module

The VM module creates an isolated JavaScript execution context, similar to eval, preventing pollution of the current scope. It is a core Node.js module used internally by require to wrap and execute .js files via vm.runInThisContext.

const vm = require('vm');
const code = 'result = 2 * n;';
const script = new vm.Script(code);
const sandbox = { n: 5 };
const ctx = vm.createContext(sandbox);
vm.runInThisContext(code);
script.runInThisContext();
vm.runInNewContext(code, sandbox);
script.runInNewContext(sandbox);
vm.runInContext(code, sandbox);
script.runInContext(sandbox);

Problem Occurs

To isolate user‑uploaded code, a demo uses VM to run a Fibonacci function in a sandboxed context while benchmarking with ab. The first version creates a new sandbox inside each request, leading to memory spikes (~800 MB) and low QPS.

Memory usage jumps to ~800 MB.

Memory is released slowly after requests finish.

QPS is low.

A second version moves the sandbox declaration outside the request handler; memory stays around 19 MB and QPS improves significantly.

Investigating the Cause

The repeated creation of a new sandbox triggers vm.runInNewContext to “contextify” the object each time, allocating a ContextifyContext instance that holds three Persistent handles (sandbox, context, proxy_global). Persistent handles live on the V8 heap until explicitly disposed or reclaimed by GC, causing memory to accumulate.

V8’s garbage collector uses Handle, Local, and Persistent concepts. Handles are lightweight references; Locals are scoped to a HandleScope and are reclaimed when the scope exits. Persistent handles behave like heap allocations and survive beyond the scope, requiring manual disposal or GC callbacks.

Because GC runs infrequently (e.g., old space default 1 GB), the accumulated Persistent handles are not reclaimed promptly, leading to the observed memory bloat.

Solution

Option 1 – Declare Sandbox Outside the Callback

let sandbox = { fibonacci, number: 10 };
http.createServer(function (req, res) {
  sandbox.number = Math.floor(Math.random() * 20);
  vm.runInNewContext('a = fibonacci(number)', sandbox);
  res.end();
}).listen(8999, '127.0.0.1');

Option 2 – Reuse Script and Context

const code = 'a = fibonacci(number)';
const script = new vm.Script(code);
let sandbox = { fibonacci, number: 10 };
let ctx = vm.createContext(sandbox);
http.createServer(function (req, res) {
  sandbox.number = Math.floor(Math.random() * 20);
  script.runInContext(ctx);
  res.end();
}).listen(8999, '127.0.0.1');

Option 3 – Tune V8 GC Parameters

--trace_gc

– print GC logs. --expose-gc – expose global.gc() for manual GC. --max-new-space-size – set new space size (default 16 MB). --max-old-space-size – set old space size (default 1 GB). --gc-global – force a full Mark‑Sweep each cycle.

Adjusting these flags helps observe and control memory reclamation, but extreme values can degrade performance.

How to Detect Similar Issues Later

Use V8’s built‑in profiler ( node --prof) and process the generated log.

Debug with node‑inspector (Chrome DevTools).

Generate heap dumps via heapdump and inspect with Chrome.

Leverage v8‑profiler for CPU and heap snapshots.

Employ node‑memwatch to spot memory leaks.

Conclusion

While V8’s automatic memory management is powerful, over‑reliance on Persistent handles can cause leaks in high‑throughput Node.js services. Declaring sandbox objects outside request loops, reusing compiled scripts, or tuning GC flags are effective ways to mitigate the problem.

V8 is complex; misunderstandings are welcome for discussion.