Creează un cont pentru a te abona la acest blog și a-i urmări articolele pe pagina Lectură.
-
Recently I’ve found myself repeating the same explanations to different people about how to test a V8 patch in Node.js, how to patch the Node.js fork run in V8’s integration CI, or how to get these patches into their repositories/CIs
-
Recently I landed a custom Python gdb unwinder in V8 that allows gdb to unwind through V8’s JIT-compiled frames on x64
-
A while back, I wrote about Building Node.js on Windows using the new ClangCL support, which was done on an actual x64 Windows machine
-
Recently, I landed a change that moves the Single Executable Application (SEA) build process directly into Node.js core - a hobby project I’d been tinkering with for some time
-
In earlier posts, I wrote about reviving require(esm) and its iteration process
-
More than a year ago, I set out to revive require(esm) in Node.js and
-
Recently Node.js started to support building with clang-cl on Windows.
-
Recently, I fixed a macOS-specific startup performance regression in Node.js after an extensive investigation.
-
In the previous posts we looked into how the Node.js executable was made a bit more reproducible after the Node.js snapshot data and the V8 code cache were made reproducible, and did a bit of anatomy on the unreproducible V8 snapshot blobs
-
In the previous post, we covered how the Node.js built-in snapshot is generated and embedded into the executable, and how I fixed the Node
-
In a recent effort to make the Node.js builds reproducible again (at least on Linux), a big remaining piece was the built-in snapshot.
-
Recently, I co-organized a hybrid unconference - the Node.js collaboration summit for 2024 H1
-
Recently I landed experimental support for require()-ing synchronous ES modules in Node.js, a feature that has been long overdue
-
In the previous blog post, I described the heap snapshot trick as an “abuse” of the heap snapshot API, because heap snapshots are not designed to interact with the finalizers run in the heap
-
In the previous blog post, I talked about how Node.js used memory usage measurement to test against memory leaks.
-
Like many other relatively big piece of software, Node.js is no stranger to memory leaks, and with them, fixes and regression tests
-
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
-
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
-
In the last post, I wrote about how I came to work on a memory leak in the vm compilation APIs in Node
-
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).