Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!rpi!tale From: tale@pawl.rpi.edu (David C Lawrence) Newsgroups: comp.emacs Subject: Re: why does GNU Emacs not release memory Message-ID: <1989Oct26.043743.15022@rpi.edu> Date: 26 Oct 89 04:37:43 GMT References: Distribution: comp.emacs Organization: Rensselaer Polytechnic Institute, Troy NY Lines: 74 In lynn@rave.phx.mcd.mot.com (Lynn D. Newton) writes: Lynn> I'm planning on cross-posting to 3 groups, so please excuse the Lynn> duplication. [Aside: duplication is more easily overlooked if you did all the cross-posting in one article, by specifying a comma-seperated list for the Newsgroups: line.] Lynn> Apparently it is known and possibly even according to design that Lynn> GNU Emacs continues to grow and never releases memory when Lynn> buffers are closed or at any other appropriate times, so that it Lynn> eventually grows into a monster. It is not uncommon for me to see Lynn> processes that grow to 700-800 4K pages of memory, and I have Lynn> seen as high as 1200. In <31052@news.Think.COM> rlk@think.com (Robert Krawitz) explains why this happens. I'd like to expand on what he's said, to hopefully further clarify it. Robert> This is a problem with all Unix programs that I know, or more Robert> generally with all non-GC'ing memory management systems (emacs Robert> does have a GC for lisp, but the underlying malloc doesn't Robert> garbage collect, so it never releases any memory). Quite true. C programmes (by far the most common type on Unix systems) have the *alloc(), free(), brk() and sbrk() functions available for memory management. The basics of it all is that most programmes are written using simply malloc() and free() for memory management. malloc() will apportion memory as is available on the heap; free() returns previously allocated memory back to the heap. The non-decreasing behaviour shows up because malloc() will sbrk() memory from the system when it needs more, but free() will not brk() memory back to the system. (This all assumes a "standard" malloc library.) Robert> In principle, it would be possible to free memory down to the Robert> highest point at which memory is allocated (the top of the Robert> heap), but in practice I haven't seen a version of malloc that Robert> does this. Malloc can't do compaction (i. e. lowering the top Robert> of the heap by rearranging memory) because it has no way of Robert> tracking down all pointers to a given area of memory. There is now a new malloc library in alpha/beta test. It uses brk() when appropriate, which has been observed to actually shrink the size of a running Emacs. (*Gasp*) If all goes well through the testing stages it is likely that it will be shipped with v19. Robert> BTW, a 5 Mbyte emacs image isn't overly big. My emacs is now Robert> 10 Mbytes, and it's only been around for 2 days. It's been Robert> known to grow to 20M. Sure it's overly big, and 20M is obscene. I am, as the programmer of the new malloc package describes, "an Emacs weenie." This means that I'll keep a single Emacs process around for days, even weeks, on end. I do just about everything through Emacs from mail to news reading to compiling to interactive conferencing. Oh yeah, and editing. Generally all that should grow an Emacs image to that size is editing of several _huge_ files. In "normal" usage, it shouldn't even get as big as five meg. Features loaded in this Emacs: (sort tags irc gnuspost rnews gnus-user-tale gnus-etc nntp gnus connect sup-misc supercite baw-alist mail-utils sendmail gin-mode mh-e x-mouse ehelp electric electric-minibuffer uniquify scroll backquote header crypt) Process information (ps v): PID TT STAT TIME SL RE PAGEIN SIZE RSS LIM %CPU %MEM COMMAND 27143 p3 S 7:19 0 99 399 3784 1616 xx 0.0 10.4 emacs It was below two meg until I read in a 1.9 meg binary image to purposefully grow the image for the sake of this posting. Dave -- (setq mail '("tale@pawl.rpi.edu" "tale@itsgw.rpi.edu" "tale@rpitsmts.bitnet"))