Newsgroups: alt.lang.design,comp.lang.c,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!swrinde!pipex!uunet!maunakea!kurt
From: kurt@Data-IO.COM (Kurt Guntheroth)
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Message-ID: <D0pv6C.Luu@maunakea.Data-IO.COM>
Sender: usenet@maunakea.Data-IO.COM (The News)
Nntp-Posting-Host: rabies
Organization: Data I/O Corporation
References: <JYL.94Dec8204808@frstprsn.eng.sun.com> <D0JzqA.nB@maunakea.Data-IO.COM> <JYL.94Dec9160456@yael.eng.sun.com>
Date: Mon, 12 Dec 1994 21:18:12 GMT
Lines: 90
Xref: glinda.oz.cs.cmu.edu comp.lang.c:120301 comp.lang.c++:102743 comp.lang.lisp:16009

In article <JYL.94Dec9160456@yael.eng.sun.com> jyl@toss.eng.sun.com writes:
>
>   Twice in my career I have had the experience of implementing a system twice;
>   the first time using reference counting and the second time using garbage
>   collection.  It was my experience both times that reference counting was
>   devilishly difficult to get working right, and garbage collecting, with its
>   concentration of memory management activity into a few modules, was simpler
>   and more efficient. 
>
>I thought the purpose of using OO technology is to promote reuse.

That is a wonderful thought.  I agree that having a decent OO tool might
have made implementing reference counting less onerous, and perhaps even a
bit faster at runtime.

Of course, we don't have the luxury of living our whole lives in the
present, with plentiful object oriented tools.  My first experience was
in 1980, and was a largish Pascal program.  We might have used Simula,
but we were at two different sites, and the only machine we had at both
locations was a VAX that had, alas, no simula compiler.  My second experience
was an embedded application written in C.  No OO tool was available that
year for our target, though we searched diligently.

>I agree
>that for some implementation techniques it may be more difficult to get
>refcounting right than it might be to implement GC.

Which is my claim, in a nutshell.

>However, if you're
>implementing a reusable component the payoff for your difficulty is many
>many memory bugs in code that uses your component being pointed out close
>to their source.

Obviously your application rules your experience.  Also obviously, your
experience includes building components rather than systems.  I found that
in a complex environment with multiple pointers into a given object,
(sometimes accidental) deallocation happened distant from allocation.

>Your argument about the software engineering aspect of refcounting vs GC
>("with its concentration of memory management activity into a few modules")
>belies your attitude - you seem to hint that you stopped doing ANY memory
>management except through the use of the garbage collector.

>Speaking
>as a purist, without regard to product deadlines, I consider a program that
>leaks memory as incorrect, even if the bugs don't manifest themselves in
>unbounded heap growth. Your definition of correctness might be different,
>of course:-).

It's true, by implementing GC I could stop worrying about memory management.
There was the collector and the allocator, and that's it.  You say it like
it's a Bad Thing.  You argue that if I am not explicitly deallocating every
byte, my program is incorrect and my users are suffering.  Somehow I fail to
see it that way.  My users have effective, running apps instead of the buggy
ones they used to have.  My colleagues got to stop worrying about memory
management, and they stopped introducing bugs into the system.

>GC tends to hide the problems instead of
>allowing a user to correct them. GC didn't remove your bugs, instead you
>were able to hide them so as to be able to deliver your product.

A narrow-minded (and in this argument self-serving) definition of "bug" with
which I disagree.  I say if my program runs faster, fails to exhibit buggy
behavior, and gets delivered, then it is correct.

>   I like garbage collection.  I think it's easier to implement and more
>   efficient than reference counting.
>
>These are selfish reasons for liking GC. If you're creating a reusable
>component then these reasons are irrelevant.  Your client's convenience and
>ease of use is paramount.

My users do not know or care how my code is implemented.  They care that it
is effective, bug-free, and delivered on time at reasonable cost.  Somehow I
doubt even your customers would dislike an easy-to-implement method if it is
also more efficient.  You seem to have a religious conviction of the
superiority of reference counting.  Perhaps you have a need to suffer.

>I've really not seen that many
>cases where more than one reference to any memory location is needed (i.e.
>it doesn't limit expressiveness that much). In those cases that absolutely
>need to employ multiple references to a location, you need to use
>specialized mechanisms to manage the memory

So here's where we see "your mileage may vary".  My experience is in
systems, not in components.  Because I had many cases of multiple references
(having different lifetimes) to dynamic structures, I found reference
counting impossible to implement efficiently.  And GC was simple, efficient,
and effective.  Sorry we disagree, but calling me a fool won't impress anyone.
