== Quote from Sergey Gromov (snake.sc...@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.
