[gclist] ref-counting performance cost

[Bill Birch]

----- Original Message -----
From: "Henry G. Baker" <hbaker@netcom.com>
To: "Paul Haahr" <haahr@jivetech.com>
Cc: <gclist@iecc.com>
Sent: Monday, September 04, 2000 1:47 AM
Subject: Re: [gclist] ref-counting performance cost


> > I've definitely seen memory, files, and windows dealt with using all
> > three approaches more frequently than reference counting.  With good
> > reason:  all three have much better performance than reference counting
> > and are usually easier to implement correctly, even if they don't apply
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > to all circumstances.
>
> The "hard" reality after the software industry's 40 years of
> experience with both ref counting and gc is that the underlined
> statement above is probably the most important issue of all.  No
> matter how good a technique is in theory, it must provide benefits in
> practise.  _Every_ ref counter I've ever come into contact with
> requires a GC to back it up.  The best examples of ref counting --
> Unix file systems -- prove this rule, because they always require some
> sort of gc process (although they don't call it that!) to clean up
> after crashes.
>
I totally agree that RC collectors are very hard to code. One slip and
you've got a leak... My view is that RC collectors deserve more research
because they are so popular. RC collectors are interesting because of  the
optimisations that can be worked. RC collectors can be used in real time.
Add to that the spice of work-arounds for the cyclic problem makes for a
fertile research area. I don't understand why academics shun working on RC
collectors. Is it easier to publish papers on GC than RC? The bottom line is
that whilst GC is technically superior, an effective implementation is
complex. The average Joe Programmer does it with RC and probably finds it
tough to debug but meets his/her ship dates.