Moving GC

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> == Quote from Christopher Wright (dhasenan at gmail.com)'s article
> >
> > This isn't unreasonable, and it really just depends on how complete and
> > how fast D's runtime reflection is.
> This would incur more memory overhead as well.  Right now, we make
> do with one bit per block that indicates whether the block should be
> scanned for pointers, while this may theoretically require a pointer
> to TypeInfo per block in order to perform precise scanning.
> Sean

Under what use cases would this extra few bytes really matter?  What kinds of
programs allocate so many objects that this overhead would be significant in practice?

Note that I'm not advocating a moving GC, because in a systems language like D,
where working with pointers and untyped memory blocks is supposed to be feasible,
I think it would create more problems/limitations than it solves.  For example,
now it's ok to store a pointer to GC allocated memory in an area not scanned by
the GC, such as the C heap or a memory block marked as NO_SCAN, as long as you
also have another pointer to it somewhere else.  With a moving GC, this would
become problematic.

However, a more precise non-moving GC (scans the whole heap precisely, only
imprecise on the stack) would be nice if it can be reasonably implemented.