Try out rust-gc, a garbage collector for Rust!


So this has been baking for a while, and I think it’s ready for a wider audience.

The README file contains basic instructions for how this can be used,
as well as a link to our original design (I also have a half-written
blog post about this design that’s been languishing for a while, which I
may finish at some point).

I’m not sure if this is ready for “proper” usage yet, but it has a
working API and is sound, as far as I can tell (aside from the issue
with destructors).

Please let us know of any bugs or unsoundness you come across. Contributions (especially of testcases) welcome!


Does this things like having a Vec<Gc<u8>> on the stack (i.e. meaning that the only connection between the GC’d pointers and being live is the random Vec pointer)? The fact that Rust allows data to be stored-in/secreted away essentially anywhere in memory was a major sticking point in my own GC experiments quite a while ago.


Yeah, you can stick Gc pointers wherever you want.

It doesn’t track “stack roots”, it tracks “accessible transitively via the stack”-roots (it’s not stack scanning). The moment you stuff this Vec<Gc<u8>> into another GC’d object, the root counter will be decremented for the internal Gcs.

The goal was to write a non-stack scanning GC that doesn’t need lints to be sound. This one almost fits the bill (barring the destructor issue which is independent of memory management design).


Oh, neat strategy!

(I poked around a bit and opened #8 and #9 to improve the performance a bit.)



extern crate gc_derive;
extern crate gc;

use gc::Gc;

#[derive(Trace, Finalize)]
struct Foo {
    x: Gc<Foo>,
    y: u8,
    // ...

I’m wondering how do you construct the first Foo if you need a Foo instance to construct it?


You don’t. In general you have an Option there or something mutable.


Then should the doc be revisited? It really makes me confused.
I can hardly imagine the intention of this code.


It was.