Garbage Collection for Systems Programmers

[Walter Bright]

On 3/31/2024 8:52 AM, Anonymouse wrote:
> We don't have a moving, recompacting, generational GC though. This doesn't 
> invalidate the points he makes, but it's not quite apples vs apples.

D doesn't have a moving collector because if there is a pointer into a GC 
allocated object, and the object is moved, then the pointer is pointing to 
garbage. There goes memory safety out the window.

It is possible to detect those pointers and "pin" that particular allocation so 
it doesn't move, and I wrote such a collector long ago. It's called a partially 
compacting collector. (I thought I had invented this, but then later found a 
paper on it.)

This could be done for D, it isn't that hard.

As for a generational collector, this relies on the collector being notified 
when an allocated object gets mutated. This requires adding a "write gate" to 
the generated code. All writes through pointers execute additional code to 
notify the collector that the object changed.

This is fine if all memory is allocated via the collector. But in a mixed 
allocator environment, you're looking at a severe performance cost. So D doesn't 
do that.

At one point I did implement a scheme whereby the the GC's pages were marked 
"read only", and so when a write was done, the CPU would seg fault. A handler 
was made for the seg fault which notified the GC that it changed, and made the 
page writeable again. This involved no extra code for writes.

Unfortunately, benchmarking showed that it was way too slow to be viable. Oh well.