Since it seems on topic, I link a related project by an undergraduate at the University of Bologna <a href="https://saveriogiallorenzo.com/publications/sac2025a/sac2025a.pdf" rel="nofollow">https://saveriogiallorenzo.com/publications/sac2025a/sac2025...</a><p>Essentially, it’s a refinement of Bacon-Rajan’s cycle collector (sequential) that does not require auxiliary heap memory and handles failures when tracing complex object graphs because it uses a breadth-first technique that fundamentally prevents stack overflow scenarios.<p>What's particularly compelling is the Rust implementation, which weaves the type system and borrow checker into the algorithm's design. When dealing with garbage cycles, the algorithm doesn't just match current Rust GC alternatives, it outperforms them.
Nitpick: In section 3.3, for the Vec impl, instead of finalizing a child and then forgetting it, the child should be moved into a ManuallyDrop first. That way if the finalization panics it doesn't try to drop the child again while unwinding.
Why does this need to rely on `static` variables in the implementation? Can we use QCell-like lifetime branding tricks to have multiple independent GC-reference graphs that are assured at compile time to always be disjoint, and might undergo collection by separate threads?
An older non concurrent cycle collector is here: <a href="https://github.com/fitzgen/bacon-rajan-cc">https://github.com/fitzgen/bacon-rajan-cc</a>