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: <hbakerCzw37p.EyA@netcom.com>
Organization: nil
References: <3b5rjj$kg8@scipio.cyberstore.ca> <CzuxH4.7s2@world.std.com> <3b7pd3$954@scipio.cyberstore.ca>
Date: Sat, 26 Nov 1994 19:23:49 GMT
Lines: 79
Xref: glinda.oz.cs.cmu.edu comp.lang.c:117970 comp.lang.c++:100439 comp.lang.lisp:15820

In article <3b7pd3$954@scipio.cyberstore.ca> kevinw@whistler.com (Kevin Warne) writes:
>In article <CzuxH4.7s2@world.std.com>, tob@world.std.com (Tom O Breton) says:
>>Others, like constraining a structure to only take references it can
>>own, would require communication from the programmer, though I'd love to
>>be shown wrong.
>
>I think that future programming languages will have constructs for compile-time
                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>behavior as well as run-time behaviour.  The compile time behavior will be a
>superset of what is handled now with makefiles, macros, preprocessors, etc.  
>Through code that executes at compile-time, developers will be able to specify
>exactly how their classes and objects can be used.  Given such objects and
>metaobjects, I think such behaviour is possible...  Right now, probably not...

Traditional Lisp macros, compiler-macros and advisors can already
fulfill some of these roles.  It would be nice if we could better
formalize some of these tasks.

>Waitasec...  The implication here is that GC is and will always be slower than
>hand-coding all the deletes.  That's just not true.  
>
>1.  A collector deallocates a large number of objects all at once.  Hand-coded
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This depends upon the collector, but is generally true.
>    deletes happen 1 at a time.  This makes a difference when writing the 
>    memory manager.  The deallocation costs for a good collector are minimal.
>    (e.g., copying + non-copying collectors, implicit reclamation, etc.)
>    The deallocation costs for a good explicit memory manager are about the 
>    same (or slightly higher) as the allocation costs.

'Finalization' is becoming a more and more important issue, so the
interaction of GC and finalization needs to be clarified.  With explicit
deallocation, the timing of finalization is usually better defined.

>2.  Deallocation is part of the critical path when using explicit memory 
>    management.  A spreadsheet recalc that allocates a lot of temporary 
>    memory is going to have to deallocate that memory.  And the user is going
>    to have to wait through that deallocation.  A collector can defer collection
>    to application idle time, further decreasing the cost of deallocation.  

There's no reason why 'lazy' and/or parallel deallocation can't be done
with explicit deallocation.

>4.  For short-lived processes, a collection might not be required at all.  
>    This dynamic optimization isn't available to applications that hard-code their
>    deletes.

You have just made a pretty good argument for more tailored memory
management strategies.

>5.  Collectors can be made parallel.  Parallel collectors can run on separate
>    processors, with the appropriate speed benefits for otherwise singlethreaded
>    applications.

Other kinds of memory management schemes can also be made parallel.
'Decomposers' can easily be run as a separate thread -- especially
in the context of 'lazy' deallocation.

>6.  Collectors don't need to be black boxes for speed-hungry developers.  There
>    are many collectors with very flexible interfaces.  Developers can use their
>    knowledge of a collector's operation to further tune their application.  And
>    a good collector should be flexible enough to coexist with an explicit memory 
>    manager.

Good idea.  Now how to develop good, high-level protocols for communication
with an automatic resource manager.

>But reguardless of where you draw the line, I suggest that most applications today
>would benefit from the use of GC.

Although much work has been done on GC for 'distributed' applications,
I don't think that the benefits of GC for these applications have been
so clearly demonstrated yet.

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 ^^^        ^^^^

