Is a moving GC really needed?

[Lionello Lunesu]

Chris Miller wrote:
> On Mon, 02 Oct 2006 05:23:11 -0400, Lionello Lunesu 
> <lio at lunesu.remove.com> 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.)
>>
> 
> I believe it allows for very fast allocations, almost as fast as stack 
> allocation. This is something I'm very interested in.

Why would it allocate faster than a non-moving GC? (Ignoring for the 
moment the cost of moving.)

> It may also improve caching as allocated memory is more together.

This I understand, but what's the granularity (if that's the correct 
term) of a CPU cache?

http://en.wikipedia.org/wiki/CPU_cache#Example:_the_K8 : "The data cache 
keeps copies of 64 byte lines of memory."

I guess the chances are pretty low for two blocks to be moved close 
together and be cached together, and be accessed together..

L.