GC, the simple solution

Daniel Keep daniel.keep.lists at gmail.com
Sun Jun 4 03:40:51 PDT 2006


"GC, the simple solution"

No such thing.

Summary:

* Ref counting by default: good grief no!
* Ref counting as an option: good grief yes!
* Is there a perfect solution for memory management: don't be ridiculous.

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

What you also get that you might not want:

* because references are on the object, you can't have array slices
* it's also incompatible with pointers: if the pointer is to a member of
an object, how on earth do you update the refcount then?
* slower in the immediate sense (incref & decref calls, plus it'll mean
less code in L1 and L2 CPU cache, which can kill performance in some
architectures)
* requires all objects to have destructors to decref child objects
(implicit or otherwise)
* without auto, makes it impossible to ensure an object's destruction
when you leave scope: you can leak references
* inability to free cycles
* inability to even *run* destructors where cycles are involved, because
there is no order in which they can logically be executed and still be valid

Those last two are the main problem with reference counting, along with
the others and slightly added complexity in the compiler.

Python, however, does not suffer the cycle problem.  Know why?

Because they have a *mark & sweep* garbage collector to clean up the cycles.

Seriously, I don't want to see the current GC replaced by a reference
counting scheme.  The current system is just fine for the majority of
applications.  Where it falls down are real-time systems which can't
allow for the non-deterministic GC pauses, and where you want to keep
your memory profile to a minimum.  Anything that has pauses of activity
can just run a background GC thread to keep the memory footprint down.

To this end, I think implementing an incremental or concurrent GC should
be the next port of call for optimising D's memory management.

As it stands, you can implement reference counting yourself: you just
need to write an allocator, and call the incref and decref functions
manually.  However, I do think that having built-in *support* for
Reference counting would be fantastic.  The less that stuff like this is
left in the hands of the programmer, the better.

What I think we all need to keep in mind is that NO memory management
scheme is good for all cases.  There will always be some weird corner
case which doesn't work well with our scheme of choice, and that we
don't give a rat's about, but is VERY important to someone else.

So far D does automatic GC (the best default, IMHO [1]), manual
management, and RAII.  Throw optional ref counting in to the mix, and I
think we'll have pretty much 99% of cases covered.

	-- Daniel

[1] The best default since it's unobtrusive, and *safe*: unless you're
doing strange things, it's very hard to leave dangling references with a
GC.  This allows people to get on with writing the damn program, and
worry about managing memory later (if ever).

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/



More information about the Digitalmars-d mailing list