High-performance garbage collection for C++

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

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.

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.

Title misses a (2020)

More GC for C++ in v8, I thought? Nope: (2020)