Node.js interview questions: V8 internals and memory

So the scavenge is the minor GC, it cleans up new space. New space is small and most of what's in there is already dead, so scavenges finish fast, around a millisecond I think, and they run all the time. Mark-sweep-compact is the major GC and it goes over the entire heap. It marks everything that's still reachable, sweeps the dead objects, and compacts memory to cut down fragmentation. That's the expensive one, and historically that's where the noticeable pause spikes came from. Newer V8 softens this with incremental and concurrent techniques, so a lot of the marking happens in the background and the stop-the-world part stays short. For latency you basically watch the major GC. Frequent scavenges are normal and cheap. Long or frequent major collections show up directly in your tail latency.

I'd go with heap snapshots. Take one snapshot, let the process run and grow for a while, take a second one, and then use the comparison view in Chrome DevTools to see which object types grew between the two. If I can't attach DevTools, there's v8.writeHeapSnapshot() or the inspector protocol to dump snapshots to disk. Once I can see what's accumulating, strings or closures or some specific class, I'd look at its retainers to find whatever's holding it. Usually it's a cache with no eviction, or event listeners getting added over and over and never removed, or closures capturing large data. Since it only shows up in production, I'd try to reproduce it under realistic load in staging, or maybe snapshot a production instance carefully. And I'd watch process.memoryUsage() over time to confirm it's really heap growth and not something else.

That's the kernel OOM killer. It terminates the process when the container's total memory crosses the cgroup limit. With Node the usual cause is that V8's default heap limit doesn't match the container. V8 sizes its heap from the memory it detects, which can be way more than 512MB, so the heap grows past what the container allows and the kernel kills the process before V8 even thinks it's out of memory. The fix is setting --max-old-space-size explicitly, around 400MB for a 512MB container I think, so V8 collects harder and throws a heap-out-of-memory error instead of getting killed. It's also worth checking for a memory leak, because a leak will hit any limit eventually. And setting the flag through NODE_OPTIONS keeps it consistent across entrypoints.

So a closure keeps a reference to the variables from its enclosing scope, which means as long as the closure itself is reachable, those variables can't get garbage collected. The leak pattern is basically a long-lived closure capturing something large. Like an event handler or a setInterval callback that references a big object, that object stays alive for as long as the handler stays registered. The fix is to remove listeners when you don't need them anymore, clear your intervals, and avoid capturing large objects in callbacks that outlive the request. Copy out the one field you actually need instead of holding the whole object. In heap snapshots these show up as objects retained by closures. A closure retains its captured variables, so a leaked or forgotten closure leaks everything it captured, or something like that.

So V8 creates hidden classes that describe the structure of an object, which properties it has and where they sit. Objects built with the same properties in the same order share a hidden class, and that lets V8 read properties at fixed offsets instead of doing dictionary lookups. Inline caches remember which hidden class a piece of code has seen at a given property access, so the next access with the same shape stays fast. When a call site sees a lot of different shapes it becomes megamorphic and falls back to slower generic lookups. That's how two identical functions end up so different, I think. One gets objects with a consistent shape and keeps its fast path, the other gets mixed shapes and loses its optimizations. The standard advice is to build objects with a consistent structure, same properties, same order, especially in hot code paths.

So Buffers in Node get allocated outside the V8 heap, which means heapUsed doesn't include them. process.memoryUsage() breaks the total into a few fields. heapTotal and heapUsed cover V8's managed heap. external is memory tied to JS objects but allocated in C++, which includes Buffers, and arrayBuffers is the portion belonging to ArrayBuffers and Buffers specifically. rss is the total resident memory of the whole process. A gap like 200MB of heap against 1.5GB of RSS usually means heavy Buffer usage, file or network data being held in memory, or maybe memory used by native addons. First step is reading the external and arrayBuffers fields. If they're large, the memory is in Buffers, and then you go look for code retaining them, like caching file contents or accumulating socket data somewhere.

So JSON.parse is synchronous, which means parsing 100MB blocks the event loop for however long the parse takes, easily hundreds of milliseconds I'd guess, and no other request gets served during that window. And you pay for the memory more than once. The raw body arrives as Buffers, that gets converted to a JavaScript string, and then the parsed object graph gets built on top, which together can reach several hundred megabytes for a 100MB payload. That allocation burst also forces extra garbage collection work, so more pauses. The usual mitigations are limiting payload sizes, paginating the API so responses stay small, or using a streaming JSON parser that processes the document incrementally instead of holding all of it at once. And for services that really have to handle large payloads, moving the parse off the main thread with a worker thread is an option.

So WeakMap holds its keys weakly, meaning if the key object becomes unreachable everywhere else, the entry gets collected along with it. That makes it the tool for attaching metadata to objects without keeping them alive, like caching computed data per request object. WeakRef is a reference that doesn't keep its target alive. You call deref() and get back either the object or undefined if it was already collected. FinalizationRegistry lets you register a callback that runs after an object gets collected, which is handy for cleanup. Two things to be careful about, I think. Finalization timing isn't guaranteed, so it shouldn't be your primary cleanup path. And a WeakRef cache can lose entries whenever the GC runs. In server code the common one is WeakMap. The other two are more niche, caches, native resource tracking, that kind of thing.

So V8 compiles hot functions with its optimizing compiler, TurboFan, based on assumptions it picks up while the code runs. Like, this parameter is always a number, or the objects reaching this call site all have one particular shape. Deoptimization is what happens when one of those assumptions breaks. V8 throws away the optimized code and drops back to slower baseline execution, and it might re-optimize later. Common triggers are passing a new type to a function that had only seen one, changing an object's shape, or arithmetic that overflows the range V8 compiled for. To actually see it you can run Node with --trace-deopt, which prints each bailout and its reason, or profile and spot a hot function that's still running unoptimized. The practical advice is to keep hot functions type-stable, consistent argument types, consistent object shapes.