Moving GC

[dsimcha]

== Quote from Sergey Gromov (snake.scaly at gmail.com)'s article
> Fri, 12 Dec 2008 15:05:46 +0000 (UTC), dsimcha wrote:
> > I've been playing around with custom memory allocation schemes for some
> > programs, which are based on regions.  These work great, and are significantly
> > faster for the use cases I'm using them for, than the general allocation
> > scheme.  However, everything would break if it were used with reference types
> > and a moving GC because, as far as the GC knows, the regions I'm allocating
> > from it are untyped.
> >
> > What are the odds that some D implementation gets a moving GC in the
> > foreseeable future?  Are they significant enough that I should avoid relying
> > on the GC being non-moving, or is worrying about such things just overdoing
> > trying to be future-proof?
> Is this at all possible for a conservative GC to be moving?  It's one
> thing when some unused memory is kept allocated due to false pointers,
> and another when some data resembling pointers changes unpredictably.
> And GC is to stay conservative as long as unions are supported.

There are different levels of conservatism, though.  For example, IIRC, the Mono
GC scans the stack conservatively and pins all objects that have apparent pointers
from the stack.  However, it scans the heap precisely and moves objects that only
have pointers from the heap.  In theory (not saying it will or even should
actually happen) D could implement a mostly precise GC that makes the conservative
assumption only in the case of unions, and pins objects that may be pointed to by
pointers contained in unions.

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.