Newsgroups: comp.lang.dylan,comp.lang.lisp,comp.lang.java
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in1.uu.net!world!dp
From: dp@world.std.com (Jeff DelPapa)
Subject: Re: Garbage collection cost (was Re: Parenthesized syntax challenge)
Message-ID: <DoKuz3.60B@world.std.com>
Organization: Chaos and Confusion
References: <DGApp8.J41@undergrad.math.uwaterloo.ca> <45r8en$mdu@camelot.ccs.neu.edu> <462uqo$nfn@jive.cs.utexas.edu> <46faa4$ssq@cwis-20.wayne.edu>
Date: Wed, 20 Mar 1996 17:52:15 GMT
Lines: 73
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:6644 comp.lang.lisp:21164 comp.lang.java:32995

In article <46faa4$ssq@cwis-20.wayne.edu>,
Kenneth R. Knight <knight@sphinx.biosci.wayne.edu> wrote:
>Programmers tend to believe that GC must be inferior since it is doing 
>the work of memory allocation/de-allocation for the programmer behind his 
>back. This seems like it must be bad since it goes against so much of the 
>programming idioms commonly used in C/C++ say. As proponents we cite 
>counterexamples to this, but they tend to be obscure (i.e. Java which 
>isn't widespread yet), bring undeserved baggage (LISP and its maligned 
>parenthasis), or considered slow. 
>
>Let me suggest another possible example of a real-world system that uses 
>GC at its core: Newtons.
>
>I don't know what type of GC is integrated into NewtonScript (can someone 
>say?), but it sure does make life easier in a system with very tight 
>resources. Now, I'll grant Newton programs can be quite slow at itmes. 
>This is because NewtonScript is usually byte-code interpreted like Java, 
>but it can be compiled (code size grows a good deal) which speeds many 
>things up tremendously. 
>

The newton GC is mark and sweep.  (the oldest style) -- It works ok if
your entire system is in memory.  More recent systems move stuff
around, as the compaction is a performance win in a paged system.

Unfortunately more modern systems are less than helpful here:  On the
lispm's (where the GC had low level assists), it could see the page
map, and skip pages that wern't currently in memory.  Thus it could
run frequently, and quickly, and without hitting the disk (even modern
disks can only manage about 100 operations/second).  Only when it
could no longer recover space from active store, would it page
anything in.

There is no real reason a modern system couldn't be built with this
feature, but it would require moving the gc into the OS, which
presents cultural incompatibilities right now.

>Just a thought in helping convince people of the advantages of GC 
>specifically and more generally, and more impotantly, dynamic languages 
>like NewtonScript (and Dylan which I really hope survives on the Mac in a 
>good major way, but I have my serious doubts).
>


My standard take on malloc/free is that it is conceptually
indistinguishable from double entry bookeeping.  If some accountant
stood up and proclaimed that keeping the inventory and books by hand
is obviously more efficient than letting the machine do it, they would
be ignored as a luddite crank.

Humans are good at grand concepts, but tend to forget every tiny
detail.  Machines are currently incapable of grand concepts, but are
real good at keeping track of countless different beans. We should let
them worry about where to put things, and use the mental cycles freed
by that to think up better aproaches to what we are actually trying to
do.  I can only think about a finite (hopefully large) number of
things at once.  I can use all of that to think about my problem, or
devote 25% of it to needless complexity worrying about when to free().

Mental energy expended on hand managing memory takes away from time
that should be spent getting the real problem solved.  And since
memory management isn't your goal (you are after all trying to build a
web server or somesuch), you could never justify memory managment
heroics like the GC that read the page map mentioned above, even if
you are bulding a large enough tool that such a hack would speed
things up (at least not until more conventional tactics had produced
something that resulted in runtimes that were measured with a
calendar).  It is a lot better to let a small group of specalists
worry about memory mangement as their product, than forcing everyone
to build their own every time.

<dp>

