Reddit: SafeD - The Safe Subset of D

[Kevin Bealer]

Sean Kelly Wrote:

> == Quote from Kevin Bealer (kevinbealer at gmail.com)'s article
> > Mark/sweep doesn't have the problem of circular reference counts, but on
> > the other hand, there is no way to figure out which blocks were parents
> > of which others, so that destruction order is essentially random.  There
> > is no way to fix this reliably, especially since the circular links can
> > mean that the objects are both parents of each other -- so what order do
> > they get destroyed in?
> 
> This should probably be qualified by saying that there is no efficient way to
> find the parent object, and in the case of circular chains, there may not even
> be a parent object.  However, in the general case the GC could theoretically
> maintain enough bookkeeping information to destroy objects hierarchically
> when possible.  But I suspect that doing so would greatly increase both the
> memory needed for a scan and the time involved.  Thus, guaranteeing in-
> order destruction simply isn't practical, even when it's possible.
>  
> Sean

Yes -- especially for a precise collector in a language like Java, but I'd be
reluctant to make assumptions about the data in this way in a conservative
collector;  I think the bookkeeping you mention would require the GC to
have nearly perfect type information, which would make it impossible to
do many things.

If object A has noisy data that happens to point into B's area, then you have
a relationship from A to B.  If B also has a relationship to A, then you get a
cycle, and the GC has to fall back on unordered destruction.  If B expects
the GC to make sure that A still exists this could be a problem.

Unless the user specifically marks these relationships, it seems difficult to
do this reliably.  This could be done of course, but as long as we need to
change B, why not make B handle cleanup in its own destructor?

For extra control over B's behavior, the B object could take a function
pointer (not a delegate) that told it how to clean itself up.  I think we can
assume that function pointers won't point to anything collectable.  Maybe
something like this:

class B {
    // I don't remember the function pointer syntax... 
    void setDestructHandler(void (*foo)(B*));
};

Kevin