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!pipex!uunet!mole-end!mat
From: mat@mole-end.matawan.nj.us
Subject: Re: Reference Counting (was Re: Searching Method for Incremental Garbage Collection)
Message-ID: <1994Dec13.150511.11881@mole-end.matawan.nj.us>
Summary: Root causes ...
Organization: :
References: <D03Iwn.Jn5@research.att.com> <3boujh$o0c@news.parc.xerox.com> <JYL.94Dec9160456@yael.eng.sun.com>
Date: Tue, 13 Dec 1994 15:05:11 GMT
Lines: 45
Xref: glinda.oz.cs.cmu.edu comp.lang.c:120492 comp.lang.c++:102981 comp.lang.lisp:16047

In article <JYL.94Dec9160456@yael.eng.sun.com>, jyl@yael.eng.sun.com (Jacob Levy) writes:
 
>    The second time this happened to me, I deliberately converted to garbage
>    collection as a method to remove a number of known memory management bugs
>    and a memory leak.  ...
 
> You've just proven my point that 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.  ...
 
>    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.
> 
> Again I'd like to make a plug for linearity. 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, and linearity gives you the
> framework for reasoning about that and for isolating those instances.
> Lastly, linearity allows an especially efficient implementation of memory
> management that outpaces both GC based and refcounting based
> implementations.

I'd like to remind people (including those that didn't get it the first
time) is that the `need' for GC arises when (a) a _value_ is represented
using an indefinite number or selection of _objects_ and (b) there is no
relationship established between a given value representation and the
activity which (may) need it.

If you avoid these problems, you avoid the whole issue.

It's not always possible to avoid (a); what is necessary then is to avoid
(b).

There are a few problems in which this is not a practical approach.  There
are many more in which it is very practical.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
	(Training and consulting in C, C++, UNIX, etc.)
