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?
Node 26 added a bunch of profiling stuff that should make this a bit easier to pick apart. I'm being lazy and waiting for perfetto support on windows to get fixed so I haven't bothered yet
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
Node 26 added a bunch of profiling stuff that should make this a bit easier to pick apart. I'm being lazy and waiting for perfetto support on windows to get fixed so I haven't bothered yet
Interesting, but I still see `std::shared_ptr` and careful ownership as the C++ way. GC feels like adding another runtime dependency.
Takes me back to trying to wrangle memory in a large C++ app. True high-perf GC would've been a godsend then.
More GC for C++ in v8, I thought? Nope: (2020)