Why is the garbage collector implemented manually and not using an external crate?

[marc-thieme]

As far as I can tell, Steel is implementing their own garbage collector in crates/steel-core/src/gc.rs . I was wondering why that is, afterall you would presume that there are more performant/better tested/etc. external crates available than a hand-writte one.

Is it just that there are no good GC crates available? Or are requirements too specific?

[mattwparas]

Good question, so there are a variety of reasons, the bulk of which comes down to time and how it grew organically.

First, I was curious to explore the lengths to which reference counting could be used to a certain degree - reference counting on its own has its drawbacks, but due to the implementation of steel, by using reference counting we can assert that the vast majority of values are dropped when they go out of scope. The only time we really need garbage collection that is not reference counting is with:

• Data structures with interior mutability (to avoid memory leaks via cycles)
• Closures which mutably capture values

On the first point, right now I believe the implementation allows for memory leaks - structs and mutable vectors are the only mutable data structures, besides any externally added custom structs that can hold Steel values. These right now are naively just using a gc pointer that I've implemented crudely, and will eventually want to swap to something more efficient.

On the second point, for mutably captured variables, I have a proper gc that simply does mark and sweep, and it is terribly inefficient. However - this is purely based on my own preference. I prefer to program without mutation, and the only kind of mutation I tend to reach for are set! on global variables - but very rarely if at all do I use mutable local variables.

Another reason is that I wanted to explore how to achieve mutation in place more easily without the overhead of a mark and sweep garbage collector, and the built in list data type will support mutation in place when we can assert that it has no other references to it.

All in all, there are a bunch of trade offs I've made here - eventually I want there to be no memory leaks, so I'll need to swap in those data structures to either leverage the terrible gc that I've written (which, I wrote because I wanted to learn!) - or, we swap in a more battle tested implementation, which I'm not above doing. As you'll see - the Gc type you've referenced is actually just a thin wrapper around Rc - the point being that eventually I could experiment with other implementations as well fairly easily since we could change the underlying implementation to use something else. There are some very promising gc implementations in Rust that I would like to explore, but I've only got so much time in the day and something has to get punted 😄