Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.lisp Subject: Re: Memory Management in Lisp? Message-ID: <4936@goanna.cs.rmit.oz.au> Date: 11 Mar 91 07:39:37 GMT References: Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 47 I note that T has "pools", and that if you have "weak references" it is easy to implement them in user code, and if you haven't, it's not _that_ hard to tell a garbage collector how to flush them. The basic idea of a pool (from memory, so the interface is _wrong_): (define my-pool (create-pool ALLOCATOR)) ;; ALLOCATOR is a function. my-pool is a "weak set" of objects. (pool-allocate my-pool) ;; if my-pool is not empty, remove and return any one of the ;; objects in it. if my-pool is empty, call (ALLOCATOR) and ;; return its result. (pool-release my-pool object) ;; adds the object to my-pool, so that pool-allocate may return it When a garbage collection happens, every pool is emptied, but an object in a pool will not be reclaimed if there are any "hard" references to it. By using pools, you can recycle objects faster than the garbage collector; the price is that you may accidentally free something that is still in use. I further note that Lisp Machines have had "areas" for a long time, so that providing some kind of control over locality is not entirely out of the question. I suppose the real question is whether anyone succeeded in getting useful speedups by using it. I note that the compilers on the Burroughs B6700 made it easy for a programmer to control which Algol procedures, Fortran program units, or COBOL paragraphs were placed together in what segments, but I never knew anyone bother much, even though the concept of grouping was clear and the means simple and clearly documented; it was rare for people to know which program units belonged together. Should good programmers spend a lot of time thinking about storage allocation and placement, or should they spend their time thinking about how to reduce the amount of storage they need so that memory management ceases to be a bottle-neck? > I really don't see why so many people would die tomorrow for reducing by > 10% the time complexity of their code, but are indifferent to reducing > the space or IO complexity by an order of magnitude. My attitude is that reducing the amount of space used *IS* how I make my programs run faster, but that the way to do that is not to give myself more scope for mistakes by explicitly managing the intermediate objects, but instead by designing my algorithms so that they create as few intermediate objects as possible in the first place. -- The purpose of advertising is to destroy the freedom of the market.