This is far from the cutting edge of GC technology. I do have aspirations to get to that cutting edge. However that’s not important today, but being able to reclaim memory is.

We could have used Boehm GC (for example) as a very easy way to add a GC. However, and without intending any disrespect, projects that use Boehm GC as an interim solution seldom find the motivation to replace it with a permanent solution later. Even though it’s be possible to make a collector tuned to their particular needs, since Boehm GC works fairly well the need to replace it is never strong enough to overcome the effort required. Maybe this naive collector will motivate us to work on this in the future.

While it’s possible to make some rather good collectors that are conservative and non-moving (we’re curious about the riptide collector) we think this is a limiting factor. An objects' location within the heap can be used to tell the collector different things about that object. A generational collector will often use an object’s location to know how long ago it was allocated (what generation and sometimes what step of that generation it is in). For generational collectors, but also some others, objects will need to be moved eg as they survive each generation.

A moving collector needs to re-write pointers as objects are moved, therefore it needs accurate information about which values are pointers, making it an accurate collector (and not a conservative collector). This can be a difficult thing to retrofit, therefore moving to accurate collection early is an important priority. While generational collection often gives large performance gains, it may be a better test of the GC to implement compacting first. Before making this change we will probably which to revise the heap layout.