Is a moving GC really needed?

[Lionello Lunesu]

Frits van Bommel wrote:
> Lionello Lunesu wrote:
>> Chris Miller wrote:
>>> On Mon, 02 Oct 2006 05:23:11 -0400, Lionello Lunesu 
>>> <lio at lunesu.remove.com> wrote:
>>>> 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.)
> 
> "Normal" allocators have to deal with fragmentation.
> With a moving GC you can allocate everything to the top of the heap and 
> rely on the GC to shrink the heap when you run out of space.
> So the allocator can basically be "increment top-of-heap-pointer by size 
> of allocation and return old value" (synchronized if in a multi threaded 
> environment, of course).
> That's pretty much the most efficient allocator possible (as long as the 
> GC doesn't need to run, anyway ;) )

Imagine doing that with 2^64 bytes of virtual memory! Maybe you don't 
even need to compact (although, small blocks will keep entire pages in 
memory.. bad idea)

L.