Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!samsung!ginosko!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.emacs Subject: Re: why does GNU Emacs not release memory Summary: GNU emacs does not really release memory... Message-ID: Date: 28 Oct 89 10:22:50 GMT References: <1989Oct26.043743.15022@rpi.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 39 In article <1989Oct26.043743.15022@rpi.edu> tale@pawl.rpi.edu (David C Lawrence) writes: 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. It so happens that I did post a shrinking, fully tested malloc in alt.sources that does release memory; it takes great pains to do this in every possible situation where this may be done (it does refrain from this if there is evidence that the user bypassed malloc and called sbrk itself). Well, GNU Emacs *does not* shrink. Micrognu does, spectacularly. The problem, I suspect, is that GNU Emacs does not allocate memory in a stack like fashion. What I mean is: after fetching a file into a buffer, deleting that buffer should release all the memory that was allocated to it, and allow the break to be shrunk appropriately. Unfortunately, I think that GNU Emacs does an allocation before freeing the buffer and its contents, so that there is allocated storage *above* the newly free large chunk of memory, and the break cannot be taken back. Too bad... Also, GNU Emacs has, and this is far worse, *extremely* poor locality of reference. Now, if RMS were to rewrite the garbage collector so that it used breadth first compaction... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk