Moving GC

[Brad Roberts]

Christopher Wright wrote:
> dsimcha wrote:
>> However, after thinking about it, I doubt D will go the route of
>> moving/more
>> precise GC.  I know I've advocated it in the past, but I've realized
>> that false
>> pointers aren't generally that big a deal if you delete a few huge
>> (>1MB) objects
>> manually.  Furthermore, I think it's necessary in a systems
>> programming language
>> to be able to allocate a big chunk of untyped memory.  Technically,
>> this could
>> still be done with a moving GC by using the C heap, but it would make
>> things
>> really, really complicated.
> 
> You'd have to do more bookkeeping:
> - this memory is referenced by something that I know is a pointer
> - this memory is referenced by something that might be a pointer (or
> some random bit pattern)
> - this memory is not referenced
> 
> This isn't unreasonable, and it really just depends on how complete and
> how fast D's runtime reflection is.

Maybe isn't good enough. You have to definitively be able to identify
every pointer to an object to be able to move the object since every
pointer must be adjusted.  The only alternative to that is double
indirection for movable objects.  With double indirection you point to a
pointer that the GC owns and can update when the objects are moved.

There's HUGE benefits to a moving gc.  The gc in java 6 is _extremely_
clever (and not all that hard to write either, at least most of it is..
there's a lot of details in the heuristics parts), but 100% relies on
moving objects.

Later,
Brad