Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!mintaka!ai-lab!zurich.ai.mit.edu!jinx
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.lang.lisp
Subject: Re: Memory Management in Lisp?
Message-ID: <JINX.91Feb26214634@chamarti.ai.mit.edu>
Date: 27 Feb 91 02:46:34 GMT
References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM>
	<1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM>
	<PCG.91Feb23162955@odin.cs.aber.ac.uk>
Sender: news@ai.mit.edu
Reply-To: jinx@zurich.ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.
Lines: 24
In-reply-to: pcg@cs.aber.ac.uk's message of 23 Feb 91 16:29:55 GMT


    To rely on garbage collection, which is a worst case mechanism to use to
    reclaim storage when nothing is known a priori about value lifetime, for
    known lifetime cases is clearly wasteful. An analogy is using dynamic
    type dispatching when the type of a value is well known by design. Maybe
    we need sophisticated, checkable lifetime declarations (better than
    DYNAMIC-EXTENT), not just sophisticated, checkable, type declarations.


Hmm.  So you would argue for programming with overlays rather than
using a virtual memory system?  Or having programmers think about disk
sectors, head motion, and queueing operations on the disk rather than
using the OS-supplied facilities that hide such details.

Of course, there are applications where performance is so critical
that you cannot use virtual memory, or ignore details of disk access,
etc., but the vast majority can.  Programmer productivity is greatly
enhanced and the likelyhood of bugs is greatly decreased by using the
system-supplied facilities, albeit at a cost in performance.

I think automatic storage managment has the same characteristics as
these OS services, and should be avoided only under duress.  That does
not mean, however, that other facilities should not be made available
as well.