The problem with the D GC

[Sean Kelly]

Benji Smith wrote:
> The only comment I'd like to add is this:
> 
> At the same time as we're thinking about how to use a precise collector 
> instead of a conservative collector, we should also think about how to 
> implement a generational copying collector, since it might be necessary 
> to add new constructs to the core language (pointer pinning, for 
> example) to facilitate the new collector semantics.

Personally, I'm not convinced that a traditional moving GC will be the 
way to go in D.  Unless we are given some way to obtain type info for 
data on the stack and in the static data segment, anything directly 
referenced by these regions would have to be implicitly pinned.  And 
typically, long-lived data is referenced directly from such links.  A 
programmer could work around this limitation by using proxy classes, but 
this seems like a lot of trouble just to allow for generational garbage 
collection.  However, there are variants on the idea that sound like 
they have potential, one of which I believe is being discussed.  As for 
pointer pinning--it's fairly easy to add to the GC, so I don't see that 
as an obstacle to future design.  The bigger problem is sorting out 
efficient implementations of Object.opHash and such for objects whose 
only persistent uniquely identifying characteristic is their address.


Sean