René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"vm contexts never get freed after Jest runs a big test file (Node 24+, retained maps)","articleBody":"### Version\n\nv24.21.0 (also v24.8.0, v24.15.0, v26.10.0; not v22.14.0 or v22.18.0)\n\n### Platform\n\n```text\nDarwin \u003chost> 25.6.0 Darwin Kernel Version 25.6.0: Fri Jul 31 19:17:26 PDT 2026; root:xnu-12377.161.14~5/RELEASE_ARM64_T6041 arm64\n```\n\n### Subsystem\n\nvm\n\n### What steps will reproduce the bug?\n\nI put a small repro here: https://github.com/markmssd/nodejs-repro/tree/vm-context-retained-maps\n\n```sh\ngit clone -b vm-context-retained-maps https://github.com/markmssd/nodejs-repro.git\ncd nodejs-repro\nnpm install\nnpm run repro        # \"still in memory\" goes up to 8\nnpm run repro:fixed  # same thing with --retain-maps-for-n-gc=0, stays at 1\n```\n\nJest runs each test file in its own `vm` context. `many.test.js` has 3000 trivial tests, which is enough to get Jest's per-test code optimized, and then there are seven files with a single test each. `counting-environment.js` is Jest's node environment plus a small counter: after each test file it runs a GC and prints how many test-file globals are still around.\n\n### How often does it reproduce? Is there a required condition?\n\nEvery time on Node 24 and 26. You just need one test file that does enough per-test work for Jest's code to get optimized. 3000 empty tests does it. In our real project, about 120 tests is enough, because our setup files register around 12 beforeEach hooks.\n\n### What is the expected behavior? Why is that the expected behavior?\n\nOnce a test file is done, its context should be garbage collected, so only the file that's currently running should still be in memory:\n\n```\ntest files finished: 1, still in memory: 1\ntest files finished: 2, still in memory: 1\n...\ntest files finished: 8, still in memory: 1\n```\n\nThat's what I get on Node 22, and on Node 24/26 with `--retain-maps-for-n-gc=0` (`npm run repro:fixed`).\n\n### What do you see instead?\n\nOn Node 24 and 26, none of the test files after `many.test.js` ever get freed:\n\n```\ntest files finished: 1, still in memory: 1\ntest files finished: 2, still in memory: 2\n...\ntest files finished: 8, still in memory: 8\n```\n\nThis is how I found it: in our real test suite, one Jest worker running 180 test files ended up holding 44 old contexts and about 1.1 GB of heap. With `--retain-maps-for-n-gc=0` it's 2 contexts and around 330 MB. In CI our workers peak at 1.4–1.9 GB of retained heap, and 670–820 MB with the flag.\n\n### Additional information\n\n- The old contexts aren't strongly reachable. A heap snapshot (`v8.writeHeapSnapshot()`, whose GC tries to reduce memory) frees them, and afterwards the snapshot only shows the current one. Plain `global.gc()` calls never do, which is why I think it's the retained maps. `--retain-maps-for-n-gc=0` makes it go away completely.\n- `--no-maglev` mostly hides it (2 stay alive instead of all of them), I assume because less code gets optimized.\n- I did find one strong path, but it only keeps a single previous test file alive: from Jest's runtime, through the `FeedbackVector` / `AllocationSite` of `createInitialModule`, the boilerplate object's `Map` → `DescriptorArray` → `AccessorPair` (a `module.parent` getter Jest defines on every module with `Object.defineProperty`), and from that getter's closure to the test file's environment.\n- I couldn't reproduce it with a plain `node:vm` loop (new context each iteration with a hot function inside), so it probably depends on how Jest's code is shared between the outer realm and the contexts.","author":{"url":"https://github.com/markmssd","@type":"Person","name":"markmssd"},"datePublished":"2026-10-03T23:32:26Z","url":"https://github.com/nodejs/node/issues/66490"}