Re: [gtk-list] Garbage Collection and other things (belated)

[Kenneth Albanowski <kjahds kjahds com>]

On Fri, 17 Apr 1998 attila@stalphonsos.com wrote:

> + Garbage collection is Hard.  Reference counts sound appealing, but
>   they end up actually not being a good idea except in very specific
>   circumstances.  Our environment started with a reference-count
>   system, and we went through the entire process of realizing that
>   this wasn't as good an idea as it sounds (and then found out that
>   lots of people had found this out before -- take a good look at the
>   GC literature).  We ended up with a much more sophisticated tri-color
>   scheme with some modifications for dealing with the fact that we had
>   objects that were "native" to different languages and object models,
>   and that the entire environment was inherently multi-threaded.
>   This sounds like it's more overhead, it but turns out that it performs
>   much better, gives you more levers to tweak, and saves memory.  There
>   is a lot of literature to suggest that GC'ed environments can
>   out-perform explicit memory allocation.

Yup, I've witnessed this in binding Perl to Gtk (and thus connecting two
disparate reference-counting GC schemes.) The result I've come up with
uses reference counting, with a trivial GC to free objects that exist as
pure cycles.

This was only feasible because of Gtk's "destroy" mechanism, that nicely
kills all signal handlers and other things that are likely to have cycles.

It works, but it does take up a bit of time, and it certainly more work
then one would want.

> + There are tools out there that specifically attack the problem of GC,
>   and do it pretty well.  The Boehm garbage collector from Xerox Parc
>   comes to mind as being the most general. In retrospect, though I
>   learned a lot by implementing several different kinds of GC, I
>   would've have been better off had I just used Boehm's GC from the
>   start.  It works with C and C++, threads, and will more or less do
>   exactly what you want so long as you don't violate a few invariants,
>   which are very clearly stated in his excellent papers.  It's worth
>   looking at even if you don't use it.

The main problem is that any dicussion of GC and C always winds up at the
same place: you can't implement automatic GC portably and reliably, and
its just not worth trying.

Perhaps we'll get it eventually (in the same way we've recently obtained
dynamic loading and threads), but it won't happen till it is time. 


-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)