Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!think!think.com From: rlk@think.com (Robert Krawitz) Newsgroups: comp.emacs Subject: Re: why does GNU Emacs not release memory Message-ID: <31052@news.Think.COM> Date: 25 Oct 89 19:48:45 GMT References: Sender: news@Think.COM Reply-To: rlk@think.com (Robert Krawitz) Distribution: comp.emacs Organization: Thinking Machines Corp., Cambridge MA Lines: 34 In-reply-to: lynn@rave.phx.mcd.mot.com (Lynn D. Newton) In article , lynn@rave (Lynn D. Newton) writes: ]Apparently it is known and possibly even according to design that ]GNU Emacs continues to grow and never releases memory when ]buffers are closed or at any other appropriate times, so that it ]eventually grows into a monster. It is not uncommon for me to see ]processes that grow to 700-800 4K pages of memory, and I have ]seen as high as 1200. This is a problem with all Unix programs that I know, or more generally with all non-GC'ing memory management systems (emacs does have a GC for lisp, but the underlying malloc doesn't garbage collect, so it never releases any memory). In principle, it would be possible to free memory down to the highest point at which memory is allocated (the top of the heap), but in practice I haven't seen a version of malloc that does this. Malloc can't do compaction (i. e. lowering the top of the heap by rearranging memory) because it has no way of tracking down all pointers to a given area of memory. This is to some extent a limitation of the C language, in that pointers are not distinguished in any way in the run-time code. In Lisp and other garbage collecting languages, where a run-time system manages all memory, it is possible to use tag bits to distinguish pointers, and to otherwise keep track of all outstanding pointers. However, the Lisp GC combined with free(1) to free memory allocated with malloc will give you a savings: emacs will preferentially allocate itself memory that it already owns rather than ask the system for more. BTW, a 5 Mbyte emacs image isn't overly big. My emacs is now 10 Mbytes, and it's only been around for 2 days. It's been known to grow to 20M. Granted, this is only practical on big machines and personal workstations, but it's a normal part of emacs use. -- ames >>>>>>>>> | Robert Krawitz 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111