Towards the end of 2025, I had the opportunity to work on a project sponsored by Jane Street to extend V8’s memory profiler API with a new metric: the total number of bytes allocated by an Isolate since its creation.
\nThe requirement sounds simple: count mutator allocations (i.e., allocations caused by JavaScript execution) while ignoring allocations performed by internal machinery, like GC threads. The motivation was to allow building regression tests that monitor allocation behavior over time. If you want more background on the motivation and initial proposal, I recommend the patch’s design document.
\nWhat initially looked like a small change turned into a surprisingly deep dive into V8’s allocation fast-paths, LAB management, and safepointing infrastructure.
\nMy first instinct was: “V8 already has a lot of allocation profiling infrastructure; surely there might be something close to what I need, right?”
\nThat question led me to the SamplingHeapProfiler, which internally uses AllocationObserver. This already tracks allocations and, importantly, it does not observe GC allocations, thanks to PauseAllocationObserverScope inside Heap::PerformGarbageCollection.
So I implemented a prototype: a new AllocationObserver with step_size = 1 that increments a counter on every allocation, then exposed that counter through an added total_allocated_bytes field in HeapStatistics.
This worked, produced correct numbers, and required minimal changes. However, there was one major problem: The performance overhead was catastrophic. The major reason behind such high overhead is that using allocation observers to observe all allocations means that every allocation in the program will need to go through the C++ observer's infrastructure, and this disables every fast path related optimization. I soon realized why SamplingHeapProfiler is opt-in and must be explicitly started (see StartSamplingHeapProfiler). Its observer is attached only at that point. We needed something much lighter than this approach.
One of the fast path related optimizations is LABs. A LAB (Linear Allocation Buffer) is a contiguous region where the mutator can allocate memory using a simple bump-pointer. It's created when a mutator requests some allocation, and instead of only allocating what was requested, it allocates more memory to be used by subsequent mutator allocations. Allocations from this buffer are extremely fast, and a huge amount of JavaScript code that triggers allocation is affected by this fast path, such as function declarations, object literals, arrays, closures, strings, etc.
\nIf an AllocationObserver must run for every allocation, every allocation becomes a slow-path and performance tanks.
This meant that profiling using observers was not acceptable for something that must always be enabled.\nStill, that prototype was valuable: it served as an oracle to validate later implementations.
\nWhile discussing alternatives with my colleague Andy Wingo, he suggested a promising idea: "Instead of counting allocations as they happen, count the LAB size when the LAB is freed. For active LABs, we get their size when the API is called."
\nThe intuition for this idea is as follows:
\nTo ignore GC allocations, we used MainAllocator::in_gc.
LAB freeing happens in FreeLinearAllocationAreaUnsynchronized [1] [2].
This approach solved the performance issue, but we needed to account for partially filled LABs when the API is queried. That led to adding a helper like:
\nuint64_t Space::GetTotalAllocatedBytesInLAA() const {
uint64_t total_bytes = 0;
HeapAllocator* allocator = heap_->allocator();
// Here we check spaces that might have allocations in their current
// LinearAllocationArea that hasn't been freed yet, which means that they
// weren't added to the total allocation counter.
MainAllocator* space_allocator = nullptr;
switch (identity()) {
case NEW_SPACE: {
space_allocator = allocator->new_space_allocator();
break;
}
case OLD_SPACE: {
space_allocator = allocator->old_space_allocator();
break;
}
case TRUSTED_SPACE: {
space_allocator = allocator->trusted_space_allocator();
break;
}
case CODE_SPACE: {
space_allocator = allocator->code_space_allocator();
break;
}
case SHARED_SPACE: {
space_allocator = allocator->shared_space_allocator();
break;
}
case SHARED_TRUSTED_SPACE: {
space_allocator = allocator->shared_trusted_space_allocator();
break;
}
default:
break;
}
if (space_allocator && space_allocator->top() > space_allocator->start()) {
total_bytes += space_allocator->top() - space_allocator->start();
}
return total_bytes;
}…which scanned each allocator’s active LAB and counted the remaining used bytes. This version passed correctness checks against the observer-based oracle.
\nBefore approval, reviewers suggested a couple of changes to simplify the logic:
\nThis lets us place the logic in a single point: MainAllocator::ResetLab.
Counting on LAB creation slightly overestimates total allocation because LABs are not always fully used before being freed. In my experiments, the overestimation was around +1%, which we considered acceptable for this API.
\nSpace::GetTotalAllocatedBytesInLAA #Another suggestion was to avoid scanning active LABs during GetHeapStatistics. Instead, they suggested freeing LABs from all threads before reading the counter, similar to what is done for LABs in main thread.
This required thread synchronization, which led me to investigate...
\nV8 uses safepoints to coordinate all threads so the runtime can safely examine the heap while avoiding race conditions.
\nSafepointScope waits until all threads reach a safepoint.LocalHeap::Safepoint to check if they must park.I experimented with a version using a safepoint inside GetHeapStatistics and implementing the following method:
uint64_t Heap::GetTotalAllocatedBytes() {
uint64_t total_allocated_bytes = 0;
safepoint()->IterateLocalHeaps([&](LocalHeap* local_heap) {
total_allocated_bytes += local_heap->allocator()->GetTotalAllocatedBytes();
});
return total_allocated_bytes;
}This removed the need for atomic counters, since each thread had its own local counter.
\nThe experiment worked and was interesting, but...
\nDespite the safepoint-based approach being correct, reviewers ultimately preferred the atomic counter solution. I'm not entirely clear on why they made this decision, but I'd guess that the simplicity of an atomic counter was the major reason.
\nPerformance evaluation using Speedometer, JetStream, and internal V8 benchmarks (SunSpider, Kraken, Octane) showed no detectable regressions.
\nThis is the version that ultimately landed.
\nEven though the initial requirement looked straightforward, implementing this feature required deep knowledge of several parts of V8’s memory subsystem—LABs, fast-path allocation, GC interactions, and safepoints. It was a delightful opportunity to gain a much deeper understanding of how V8 handles allocation at scale.
\nAfter the patch landed in V8, I worked on backporting it to Node.js’s HeapStatistics. The feature should already be in Node.js v25.
Thanks to Jane Street for sponsoring this work; to my Igalia colleagues Andy Wingo, Joyee Cheung, and Romulo Cintra for internal discussions and reviews; and to the V8 and Node.js reviewers who devoted their time to improving the patch.
\n", "date_published": "2026-04-08T00:00:00Z" } , { "id": "https://blogs.igalia.com/weblanguages/2026/01/01/introducing-the-web-languages-team/", "url": "https://blogs.igalia.com/weblanguages/2026/01/01/introducing-the-web-languages-team/", "title": "Introducing the ‘Web Languages’ Team", "content_html": "For a long time at Igalia, we've had our fantastic Compilers team, which consisted of people who worked on a wide array of projects — all the way from Low Level Compilers (LLVM) to JS Compilers (V8, SpiderMonkey, etc), JS Transpilers (Babel), NodeJS as well as foundational JS libraries (PDF.js).
\nThis big-tent approach served us well for a long time. However, with expansion of our work in the Web Languages space, we realized it was finally time to form the new 'Web Languages' team which has a sharper focus on shaping JavaScript standards via TC39, WHATWG, and WinterTC.
\nYou can visit our about page for more details, and read more about our work from last year in this blog post.
\nThis is a new chapter for us, we’re very excited to grow this dedicated Web Languages focus to keep expanding our scope and impact on the standards and tooling across the ecosystem.
\n", "date_published": "2026-01-01T00:00:00Z" } ] }