Newsgroups: comp.lang.misc,comp.object,comp.lang.scheme,comp.lang.functional,comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!travelers.mail.cornell.edu!news.kei.com!news.mathworks.com!tank.news.pipex.net!pipex!newsfeed.internetmci.com!in1.uu.net!nntp.cadence.com!news
From: Simon Kinahan <simonk>
Subject: Re: (debunk-myth '(debunk-myth '(<-efficient gc malloc/free)))
Content-Type: text/plain; charset=us-ascii
Message-ID: <DH0GMA.A9w@Cadence.COM>
To: Qobi@CS.Toronto.EDU
Sender: news@Cadence.COM
Content-Transfer-Encoding: 7bit
Organization: Cadence NVision
References: <QOBI.95Oct22061418@qobi.ai> <46dm26$if4@jive.cs.utexas.edu> <QOBI.95Oct22124417@qobi.ai>
Mime-Version: 1.0
Date: Wed, 25 Oct 1995 15:34:58 GMT
X-Mailer: Mozilla 1.1N (X11; I; SunOS 4.1.3 sun4c)
X-Url: news:QOBI.95Oct22124417@qobi.ai
Lines: 57
Xref: glinda.oz.cs.cmu.edu comp.lang.misc:23520 comp.object:39835 comp.lang.scheme:14117 comp.lang.functional:6579 comp.lang.dylan:5588

qobi@qobi.ai (Jeffrey Mark Siskind) wrote:

>I've been comming to the conclusion that there are qualitatively three kinds
>of garbage, at least in the programs that I write:
>
>1. *Extremely* short-lived objects that result from using a function style.
>   Something like the matrix passed between M* and M+ in (M+ (M* A X) Y).

I agree with you about these. It should be exceptionally easy to spot them
at compile time, because they usually have not even one reference at
their own level in the program. What would you recommend though ? I am
tempted to say that they could be noted somehow as 'one use only'
and cleaned up when the recieving function (M+ here) returns.

>2. Objects created for use of a particular phase of a program. These objects
>   predictably become garbage en-masse at very precise points during execution.

These seem to be the sorts of things where people are right to say malloc/free
is better. Build a list to pass results from one stage to the next, and
then process and deallocate it at the same time, for example.

Do you know of any way of reliably spotting such objects, and separating
them from class 3 ?    

>3. Objects is a global data base that get asserted and retracted in a
>   data-dependent fashion as a result of large-time-scale interaction with a
>   program.

These, of course, are the things that realy need GC, and have C++ programmers
tearing their hair out working out how to tidy them up safely (myself
included, in my foolish days when I tried out C++). Such objects are
really 'out of it' for most of their lifetimes, there is only a small chance
of them dying at any given time. 
 
>Generational collection was invented primarily to deal with (1). But I think
>that it might not be the best tool for that problem. 

Wasn't it invented to try to deal with the whole range of lifetimes ? including
(1) of course.

>I think that
>compile-time life-time analysis is a better tool for dealing with both (1) and
>(2). The argument is the same as the original motivation behind eliminating
>hardware to do pipeline interlocking and run-time type checking/dispatching
>and using a load/store architecture instead of a stack-machine. All of these
>expend run-time resources (e.g. to do instruction scheduling, type inference,
>and register allocation) to do something that can be completely determined
>statically at compile-time. The same is true of GC in cases (1) and (2). It is
>only case (3) that cannot be determined statically and still requires GC.

You may be on to something important here. Do you have any idea how to
build a system based on these categories ?
 
Simon
-- 
     1

