Is a moving GC really needed?

[Lars Ivar Igesund]

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.
> It may also improve caching as allocated memory is more together.

Also, the moving part can (and most likely will) lead to the implementation
of a generational GC, which should be able to reduce the time spent in
scanning with large amounts (I believe todays Java GC's often operate with
6 generations). All GC traits have pro's and con's, the current D GC is as
close as you come to a naive implementation, different types of
applications need different traits, so having different GC's available will
be necessary to secure a future for D.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi