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!ix.netcom.com!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Reference Counting (was Searching Method for Incremental Garbage Collection)
Message-ID: <hbakerCzuoKv.E7J@netcom.com>
Organization: nil
References: <CzpJ7I.44D@world.std.com> <3b5rjj$kg8@scipio.cyberstore.ca>
Date: Sat, 26 Nov 1994 01:10:07 GMT
Lines: 83
Xref: glinda.oz.cs.cmu.edu comp.lang.c:117916 comp.lang.c++:100384 comp.lang.lisp:15809

In article <3b5rjj$kg8@scipio.cyberstore.ca> kevinw@whistler.com (Kevin Warne) writes:
>In article <CzpJ7I.44D@world.std.com>, tob@world.std.com (Tom O Breton) says:
>>objections to reference counting that IMO aren't as strong as they
>>appear. I await other opinions of course.
>>
>>0:      It orphans circular structures.
><stuff about good programming techniques snipped>

There are some cases where one or more elements of the circular
structure can't be reclaimed for other reasons.  A good example is the
case of 'properties' on 'property lists' of traditional Lisp (but not
usually Scheme) systems.  Since someone can create a reference to a
symbol out of thin air (i.e., by calling '(read)', or by interning a
character string at run-time), symbols can _never_ be reclaimed by the
standard garbage collector if they have ever been given a print name.
(I have argued elsewhere that 'gensym' should _not_ produce symbols
with print-names, and the print-names should be given out the first
time one tries to print them.)

Therefore, the programmer will have to go to some explicit effort --
even in Lisp -- to reclaim certain structures, whether or not they
have cycles.

>>1:      It's slow, due to count update overhead.
><more stuff about programming techniques snipped>
>
>Of course, if you pare down the references to the minimum needed
>and inc/dec as necessary, you'll have a fairly efficient system.  
>Unfortunately it won't be automatic.

I'm not sure what you mean by 'automatic' in this context.  If you
mean 'oblivious to the programmer's coding style', then I suppose that
you are right.  But what system programmer is ready to give up his
right to explicitly manage certain resources in certain situations?

What _would_ be nice, would be some way to know at _compile time_ if
certain constraints were violated, so that one would immediately know
that his program would eventually fail at run-time due to premature
evacuation (GC), or a storage leak (object never gets reclaimed).

The 'linear' style of programming achieves this goal, and I expect
that there may be other styles of programming which have interesting
compile-time and/or run-time properties.  I guess I'm not ready to
concede that all of the important memory management ideas were found
by 1960 (at least reference counting and GC; see CACM 1960 for both
Collin's and McCarthy's papers).

>As a form of acounting, reference counts (or mark bits, or whatever)
>are needed to track liveness.  To properly deallocate memory, you
>need this accounting information, the actual deletion code, and a
>well-formed policy for your application about just who is responsible
>for reclaiming memory.  With allocated memory comes the responsibility
>to deallocate that memory.  That responsibility is handed off from 
>one part of the code to another (either explicitly or inside the 
>programmer's mind) until that object is deleted.

What seems to be needed is some way to indicate 'ownership
responsibilities' as part of the _type_ of an object, so that such
things can be useful at compile time.  Obviously, if the rules are
simple enough for a programmer to learn and memorize, then there is
some hope that one could build them into compile-time tools to do the
same things.

>I believe this is what you were referring to when you wrote about
>top structures and head pointers..
>
>With an automatic memory manager, this responsibility along with the 
>actual deletion code stays inside the memory manager.  The programmer
>doesn't need to worry about transferring the responsibility to delete
>objects because the memory manager will take of it.

I'm not sure what fraction of all programmers is able (or ready) to
give up complete control of resource management to a 'black box'
system.  One need only look to human economic systems to see that
'private ownership' of resources can often be considerably more
efficient in the utilization of the available resources than can
'system' (i.e., governmental) management.

Henry Baker
Read (192.100.81.1) ftp.netcom.com:/pub/hb/hbaker/README for ftp-able papers.
WWW archive: ftp://ftp.netcom.com/pub/hb/hbaker/home.html
************* Note change of address ^^^        ^^^^

