In the last post I wrote about how I finally managed to fix the memory problems in the vm APIs, and it turned out that there was another issue blocking users from upgrading away from the End-of-Life Node.js v16 - vm.Script compilation could be ~100x slower in v16 in some cases. In this post, let’s look at what was causing the performance regression, and the fix/workaround developed for it.

In the last post I wrote about how a new memory management model in Node.js vm APIs was designed to fix the long-standing leaks and use-after-free issues, and we finally put together a PR that the Node.js core CI and CITGM CI were happy with. The road to landing it and releasing it to LTS still turned out to be bumpy, however.

In the last post, I wrote about how I came to work on a memory leak in the vm compilation APIs in Node.js, attempted a fix, and reverted it because the fix turned out to be unsound and introduced a use-after-free. In this post I will write about how I got to another fix that ended up working.

This year I spent some time fixing a few long-standing issues in the Node.js vm APIs that had been blocking users from upgrading away from Node.js v16 (End-of-Life). It had been an interesting journey, so I decided to write a few blog posts about it. Hopefully they can be helpful for posterity.

Up until V8 10.0, the class field initializers had been broken in the V8 startup snapshot - a feature used by embedders like Node.js and Deno to speed up the bootstrapping of themselves or user applications. This post is going to cover how the startup snapshot support was implemented, as part of the work our team did on the class features in V8. To learn about the optimizations we did for instance initialization with the new class features, checkout another post published in the V8 blog.

Update: this blog post is now outdated. Since some time around 2022-2023 no more extra setup is required to build V8 on Apple ARM64 CPUs. This post is only preserved here for archeological purpose.

This post stems from a recent Twitter conversation and a bug I was trying to fix. I’ve also seen some questions asked in the issue tracker about this from time to time. A lot of people are already aware that a substantial part of Node.js is implemented in JavaScript, and many naturally think that Node.js loads its builtins from separate JS files on disk when the process is launched (which is very intuitive, but not true unless you use a special build-time flag). So in this post I’ll try to explain how the whole thing comes together at the moment, hopefully it can be helpful to someone searching about it on the Internet or to code archeologists in the future.

In this post, I’ll jot down some notes that I took when refactoring the uncaught exception handling routines in Node.js. Hopefully it could be useful for other people who are interested in this part of the code base, or for code archaeologists in the future.

I recently ran into a V8 test failure that only showed up in the V8 fork of Node.js but not in the upstream. Here I’ll write down my workflow used to debug the failure in case anyone (or myself) need to do this again and don’t know where to start.

I thought about writing some guides on this topic in the nodejs/node repo, but it’s easier to throw whatever tricks I personally use on the Internet first - I am also going to heavily use the pronouns “I”, “We” and “You” in this post, and talk about my personal preference here, both of which we always try to avoid in the repo ;)