GC, the simple solution

Lars Ivar Igesund larsivar at igesund.net
Sun Jun 4 08:29:30 PDT 2006


Frank Benoit wrote:

> Another garbage collector thread :)
> 
> The best garbage collector I can think about, is a reference counting
> one. To implement this:
> 
> * Every object needs a reference counter field.
> * Code using references, need to have code for incrementing/decrementing
> the counters.
> * Destructors are called immediatly if the counter goes zero.
> 
> What you get is a precise, incremental, realtime garbage collector.
> * all logic behaviour is deterministic
> * Member objects are still valid, while a destructor is called. => no
> more dispose/close patterns
> * implement games and realtime apps without worry about lags
> * implement secure application without worry about GC attack by valid
> refence data values.
> * consume only the needed memory
> * no more need for the auto object

Not entirely true in the general case, Frank ;)

There are always techniques to get around problems with an algorithm,
depending on what you want to achieve, but in general, a reference counted
GC is said to have these _negative_ properties: (paraphrased from Garbage
Collection: Algorithms for Automatic Dynamic Memory Management by Jones and
Lins)

* The cost of removing the last pointer to an object is unbounded
* Even if the general latency is good, the total overhead of adjusting
references is significantly greater than that of a tracing GC
* It has a substantial space overhead, making it less useful for smaller
heaps
* Cyclic references (already mentioned)

I think these makes RC less suited for the general case, whereas it might
fit very well in a tightly controlled system where low latency is required
(which I'm well aware that you need ;).

IMO, the best general GC (the default) would be one which can handle as many
cases as possible, and which is manipulable in those (preferably known)
cases which it don't handle out of the box. I think that one need to
combine features from several GC techniques (possibly also RC) to achieve
this. 

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi



More information about the Digitalmars-d mailing list