Finding memory leaks is a very difficult task, especially when it comes to modern JS code that makes use of many third party libraries. For example, I am currently facing down a memory leak in rollup, involving babel and a custom babel plugin. I am exploring several common strategies to hunting them down:

1. Understand your runtime, its memory de-allocation scheme, and follow best practices regarding that scheme.
   • This article claims that all modern JS runtime implementations use a Mark-and-sweep garbage collector. One of its major strengths is that it can properly deal with circular references. (The article also links this very outdated workshop paper. Don't pay much attention to it, since it is all about circular references, which should not be an issue anymore.)
   • This article goes in-depth on V8 memory management (NOTE: Node and Chrome are both based on V8).
2. If you find that memory or GC usage explodes beyond your expectation, analyze your heap memory profile to find out where memory gets allocated.
   • This SO answer explains how to do that in Chrome, but its links are outdated. This is a direct link to the relevant Chrome documentation (as of 2021).
   • For Node, I found a lot of outdated information. Currently, the easiest way to analyze your heap memory profile seems to be using the experimental --heap-prof command line argument (e.g. node --heap-prof node_modules/rollup/dist/bin/rollup -c to analyze a rollup build). Then open it in Chrome Dev Tools, via Memory -> Load.
   • Once analyzed, we can understand where/how most memory was allocated; but one crucial question has not yet been answered:
3. Given you know who the culprit (the memory hog) is, how can you find out why/where they are still lingering? And, more importantly: What is the GC root (stack pointer) of the memory hogging object?

This last question is also my question here: How can we analyze the object allocation tree in Node (or in V8 in general)? How can I find out where the objects that I identified in step (2) are kicking around?

Often, it is the answer to this question that tells us where to change our code to stop the leakage. (Of course, if your issue is memory churn, rather than memory leaks, then this question is probably not that important.)

In my example, I know that the memory is occupied by Babel AST nodes and path objects, but I don't know why they linger, that is I don't know where they are stored. If you just run Babel on its own, you can verify that it is not Babel leaking the memory. I am currently trying all kinds of tricks to find out where they are being stored, but still no luck.

Sadly, so far, I have not found any tools to help with question (3). Even relevant in-depth articles (like this and its slidedeck here) MANUALLY draw up heap allocation steps. Feels like there is no such tool, or am I wrong? If there is no tool, maybe is there a discussion about this somewhere?