Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!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: Date: 2 Mar 91 23:08:26 GMT References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> <21797@yunexus.YorkU.CA> Sender: news@ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 89 In-reply-to: oz@yunexus.yorku.ca's message of 2 Mar 91 04:43:36 GMT In article <21797@yunexus.YorkU.CA> oz@yunexus.yorku.ca (Ozan Yigit) writes: Path: ai-lab!snorkelwacker.mit.edu!shelby!unix!Teknowledge.COM!uw-beaver!ubc-cs!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!yunexus!oz From: oz@yunexus.yorku.ca (Ozan Yigit) Newsgroups: comp.lang.lisp Date: 2 Mar 91 04:43:36 GMT References: <1991Feb15.191259.20090@aero.org> <1991Feb15.223520.17267@Think.COM> <1991Feb18.191549.7575@aero.org> <1991Feb19.030719.1137@Think.COM> Sender: news@yunexus.YorkU.CA Organization: York U. Communications Research & Development Lines: 32 In article jinx@zurich.ai.mit.edu writes: [quoting Piercarlo Grandi] > > 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. This must be the usual gang-up-on-Piercarlo week ;-) I think your interpretation makes Piercarlo's views appear much more radical than they actually are. Heck, you know the type of analsis that goes into scheme compilers [for example] to avoid heap allocation [McDermott, Dybvig etc] better than I do. Aren't nemory allocation strategies based on lifetimes [Hanson] and Generational GC mechanisms are in essence use exactly the idea of making use of some knowledge about the extent of things? [Do weak references count as a similar mechanism?] So, what is so offensive about his suggestions? I certainly want Lisp systems to provide quality memory management just like I want my OS to provide good virtual memory and disk IO. That does not imply, however, that most (or any) users should be doing memory management themselves any more than it implies that users should be bypassing the virtual memory system or the system's supplied IO facilities. I agree that Lisp memory management needs to improve, but I doubt that the way to do this is to throw it out the window and revert to C-style explicit memory management. Explicit memory management is very error-prone, and (in my case) reduces my productivity significantly. I am much less likely to trust a program that manages memory explicitly than one that does not. Having said this, I will repeat what has already been said. It is trivial to do ``malloc/free'' memory management in Lisp. No one stops you from doing it. It is also trivial to make it extent dependent: (define-macro (with-dynamic-pair name x y . body) (let ((var (gensym))) `(let ((,name (pair/cons ,x ,y))) (let ((,var (begin ,@body))) (pair/free ,name) ,var)))) (define pair/malloc) (define pair/free) (let ((free-list '())) (set! pair/malloc (lambda (x y) (if (null? free-list) (cons x y) (let ((pair (car free-list))) (set! free-list (cdr free-list)) (set-car! pair x) (set-cdr! pair y) pair)))) (set! pair/free (lambda (pair) (if (not (pair? pair)) (error "pair/free: Not a pair" pair) (begin (set-cdr! pair free-list) (set-car! pair #f) (set! free-list pair)))))) Note that if weak pairs are used to hold the free list, then this method mixes well with garbage collection.