Re: [gtk-list] Re: Reference counting

["G. Sumner Hayes" <sumner collegium adsl net cmu edu>]

On Mon, Nov 24, 1997 at 07:38:14PM +0100, Marius Vollmer wrote:
>
> But reference counting breaks down when there is a cycle among the
> references.  I think there are variants of ref counting that can work
> with cycles but I expect them to lose the conceptual simplicity of
> `pure' ref counting.  [I'll skip `weak refs' for brevity.]

Also, despite appearances ref counting is often slower in total time
usage than mark-and-sweep.  On the other hand, individual latencies are
lower than naive mark-sweep and that is sometimes much more important,
depending on the application.  Incremental mark-sweep gives the best of
both worlds.  (copy-collect is probably not suitable for GTK as there
may be extremely large GC'd objects)

> 
> Therefore, we move on to fully automatic garbage collection.  Such a
> GC does not require the programmer to manually keep track of all
> `important' references but does all the magic behind his back.  Guile
> has such a garbage collector, for example, and all the other
> high-level languages have probably something equivalent.
> 

(Certainly ML, Lisp and Java do; Python uses ref-counting, at least in 1.4)

> Another conclusion we might draw: It doesn't make sense to provide
> *both* reference counting *and* explicit freeing routines.

Not true.  Many GC'd systems provide a free() function which tells the
collector to free that object immediately.  It is only used with large
objects that may have outstanding references but the programmer knows they
won't be used.  Using free() is considered somewhat dangerous but can
be a big performance win under the right conditions.  Having an explicit
free() also allows circular references to be busted apart and GC'd.

I would say, though, that GTK probably shouldn't have a free(); the mm
bogies haunting it now are the big thing stopping a lot of people from
using it, and leaking a small amount of RAM is much safer than SEGV'ing.
_After_ ref-counting is implemented it might be worthwhile to add an explicit
free() and call it only where it's really needed; it's more than likely that
this wouldn't be needed at all.

A possible compromise would be to run ElectricFence, ccmalloc, and 
Checker over the GTK sources for a while; this wouldn't be foolproof, but
might catch some of the more egregious errors without requiring as many
changes on the eve of a 1.0 release of things.  (I know that there's a 
partial code freeze (a chill?) on for GIMP; does that apply to GTK as well?)

> 
> > The original setup worked pretty well for the simple cases in C, but
> > not otherwise.
> 
> Hmm, I'm not sure, but I think there are already memory leaks with C.
> Some GtkAdjustments are never really freed I think.

There is a pretty good GC'd malloc()/free() for C pair available which I
would normally recommend except that the X calls are going to undo you if
you try to rely on it.  Implementing reference counting correctly is probably
worthwile, leaving room to move to mark-sweep if someone has a bunch of
spare time on their hands.

ref counting does leak circularly referenced objects, but this is often
not a problem in practice.  I doubt it would be a big deal in GTK.

-Sumner

-- 
rage, rage against the dying of the light