Is a moving GC really needed?

[Lionello Lunesu]

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've experienced the problems of memory fragmentation first hand. In the 
project I'm working on (3D visualization software) I've had to track 
out-of-memory errors, which turned out to be because of virtual memory 
fragmentation. At some point, even a malloc/VirtualAlloc (the MS CRT's 
malloc directly calls VirtualAlloc for big memory blocks) for 80MB 
failed. Our problems were resolved by reserving a huge block (~1GB) of 
virtual memory at application start-up, to prevent third-party DLLs from 
fragmenting the virtual address space.

One of the reasons we ran into problems with memory fragmentation was 
that Windows is actually only using 2GB of virtual address space. Using 
Windows Address Extension (a flag passed to the linker), however, it is 
possible to get the full 4GB of virtual address space available. That's 
an extra 2GB of continuous virtual address space! In the (near) future 
we'll have 2^64 bytes of virtual address space, which "should be enough 
for anyone".

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

L.