V8's Oilpan Cuts Garbage Collection Pauses by 42% with Concurrent Sweeping
High-performance garbage collection for C++
Oilpan, Chromium's C++ garbage collector, is moving into V8 as a standalone library. The post explains how its concurrent sweeper reclaims dead objects on background threads while deferring finalizers to the main thread, cutting main-thread sweeping time by 25–50% (42% on average) in Chrome M78. It also covers conservative stack scanning, the Trace visitor pattern, and restrictions on destructors.
Background sweeping has shipped in Chrome M78. Our real-world benchmarking framework shows a reduction of main thread sweeping time by 25%-50% (42% on average).
- MaxBarraclough
It's a non-moving collector. It might be high performance by the standards of C++ garbage collectors, but I doubt its performance could be anywhere near what a decent JVM can manage, especially in the absence of finalizers/destructors.
As Ron Pressler (pron here on HN) has been emphasising recently, [0] the 'sweep' phase of a moving garbage collector is unaffected by the size or number of dead objects in the heap (at least in the typical case, where there are no finalizers). This isn't the case here though (it uses free lists), or in any C++ GC.
The policy of running all destructors on the same thread doesn't really seem like 'high performance' architecture either, even if there are good reasons for it.
Still a neat project though. I rather like this:
> Oilpan uses a Clang plugin that statically verifies, among many other things, that no heap objects are accessed during destruction of an object
I'm not sure I understand this:
> Oilpan is a garbage collector written in C++ for managing C++ memory that can be connected to V8 using cross-component tracing that treats the tangled C++/JavaScript object graph as one heap.
In what sense are they treated as one heap? How can they be, given that V8 uses a moving GC for its JavaScript heap? Does it just mean there's some mechanism for a C++ object to refer to a JavaScript object, and vice versa?
[0] https://youtu.be/xr73mR7ii9M?t=1081 Principles of Memory Management in Java, September 2026
- OskarS
It's interesting reading this, wondering how much C++26 static reflection could improve the ergonomics of a system like this. Like, if you tag the class with a specific attribute, can you have have it generate the Trace() function automatically? Can you have it automatically wrap the other GC classes using the Member<> template? I think implementing the Trace() function might be doable (you'd do it in the GarbageCollected<> base class that uses CRTP, right?), but maybe not wrapping the types, I'm not sure if reflection allows you to modify types of fields in that way.
- d_finch
Interesting, but I still see `std::shared_ptr` and careful ownership as the C++ way. GC feels like adding another runtime dependency.