Is a moving GC really needed?

[Sean Kelly]

Lionello Lunesu wrote:
> I've noticed that some design decisions are made with the possibility of 
> a moving GC in mind. Will D indeed end up with a moving GC? If so, why? 
> Is a moving GC really worth the extra trouble?
> 
> Being able to move memory blocks reduces memory fragmentation, am I 
> correct? Is this the only reason? (For the remainder of this post, I'm 
> assuming it is.)

Fragmentation shouldn't be an issue with the correct allocator strategy, 
see: http://citeseer.ist.psu.edu/johnstone97memory.html

I think the real reason is to speed up collections, as generational GCs 
(a class of moving GCs) begin by scanning only a segment of allocated 
memory which contains 'new' allocations.  Only if no free space is found 
does it bother to scan older generations.  On each collection, 'new' 
memory that is still alive typically graduates to an older generation. 
The idea behind this strategy is that memory which has been around for a 
while will probably be around for a long time, while a large number of 
allocations (in function temporaries) are discarded and available for 
collection almost immediately.

> Is the extra complexity and run-time overhead of a moving GC worth the 
> trouble, at this point in time?

Probably not, but it's more a goal to make D compatible with moving GCs 
than to write one at the moment.  But doing so is a big pain in some 
cases--default implementations of toHash and opCmp being particularly 
sore points.


Sean