[gclist] Precise GC's performance

Darius Blasband darius@phidani.be
Fri, 8 Mar 1996 17:45:39 +0100 (MET)


> > - So, I measured this performance overhead, which gave me an average of
> >   17% (following some optimizations which have been suggested to me in this
> >   mailing list, I even reduced this figure to under 15%), which I considered 
> >   reasonable when compared to the advantage I saw in conservative GC, 
                                                      	 ^ Of course, I meant
                                                           precise GC...
> >   assuming that the actual GC could hardly be slower in a precise 
> >   environment.

> Yes. Pointers to all objects with a non-empty KILL method are 
> stored in a hash table. Because conservative collectors are essentially
> mark-and-sweep, the KILL method can be invoked before reclaiming the object's
> memory. 
> 
> An important finesse in the mark phase is to treat all the objects
> with non-empty KILL methods as roots (i.e., anything they point to is marked,
> even if they aren't marked themselves). 
> There are two benefits to this approach:

< Some VERY interesting stuff deleted here...> 

I deleted it, not because it is wrong (which I don't believe it was), but
because it is based on a C++-like assumption, that destruction code is
called just before deallocation. Hence, cycles problems, what if a refers
to b which refers to a, etc...

Acknoledging this problem, our design in YAFL was pretty different (admittedly,
this is more of a language design issue than just GC, but they are tightly 
correlated).

When the YAFL GC is started, a first mark pass is performed. Then, on all
objects which have been found not to be reachable anymore from the root sets,
the KILL method is applied if defined. No deallocation is performed yet. Hence,
no cycle problem.

Then, a brand new mark pass is performed, and all objects which have been
found unreachable on both of these passes are deallocated. This allows for
"last chance rescue": when a given object is being killed, it can rescue 
itself from deallocation by setting an external reference to itself as part
of its KILL method.

I don't know whether such a scheme can be implemented on top of Boehm's
GC. Any clue ?

Regards,

Darius