3 ms·
I have a Lisp OS that I'm developing, and it has a real-time garbage collector. The way it does this is that the garbage is detected using the weizenbaum varia
by procrastitron 18y ago
I have a Lisp OS that I'm developing, and it has a real-time garbage collector.
The way it does this is that the garbage is detected using the weizenbaum variant of reference counting instead of some form of mark-and-sweep. There are a couple reasons that people tend to prefer mark-and-sweep over reference counting:
1. The reference counts have to be maintained on every assignment operation.
2. Reference counting can break if the heap-allocated memory has cycles.
The first issue is basically what you described when you asked 'is it possible to make a garbage collector that can somehow run "continually"'. The answer is yes, and the way you do that is with reference counting. However, this extra work means that you have a performance hit when compared to mark-and-sweep GCs. It's an example of the classic tradeoff between low latency and high throughput; and most applications are better off with high throughput.
The second issue is the more fundamental one, because cycles in heap allocated memory mean that the reference counts on those memory cells will never drop to zero; hence they will never be reclaimed. Most GCs that use reference counting fix this problem by also using a mark-and-sweep pass to collect cyclic data structures. Of course, this would still not be a real-time collector, so it doesn't fit my needs. Instead I changed the language to not allow cyclic data structures to be created in the first place. The way I did this was to simply make my Lisp dialect purely functional.