Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!bu.edu!bu-cs!lectroid!cloud9!jjmhome!m2c!umvlsi!dime!dime.cs.umass.edu!moss From: moss@takahe.cs.umass.edu (Eliot &) Newsgroups: gnu.emacs Subject: Re: GNU Emacs, memory usage, releasing Message-ID: Date: 2 Jan 90 01:14:09 GMT References: <1558@aber-cs.UUCP> Sender: news@dime.cs.umass.edu Reply-To: Moss@cs.umass.edu Distribution: gnu Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst) Lines: 34 In-reply-to: tom@ssd.csd.harris.com's message of 31 Dec 89 15:14:33 GMT Some time ago, a bunch of hackers from MIT, who were Emacs enthusiasts, decided that the PC world could use quality editors and formatters. They formed a company called Mark of the Unicorn, which offered Mince ( = Mince is not complete Emacs) and Scribble (a stripped down Scribe). These were later improved, extended, integrated, ported to the (then new) IBM PC world, and offered as The FinalWord, and The FinalWord II. I still run these on my home computer. Anyway, they took an interesting approach to memory management. They used a disk file in a manner analogous to Unix swap space. This disk file contained the editor's "virtual memory" as a sequence of fixed size pages, and managed main memory as a cache for that larger virtual memory. Buffers were allocated as many pages as they needed, and the pages did not have to be contiguous. Now for some of the neater stuff. Insertion/deletion was handled by having a gap *in each page*, and by splitting the page into two pages if it overflowed. This affects three pages: the splitting page, the new page, and the page containing the buffer's page map. A second neat feature was that based on keyboard idle time (though number of updates could be a factor, too), dirty pages would be flushed to the "virtual memory" disk file. This allowed for crash recovery. It also allowed efficient restart with a bunch of things in your buffers. And the page orientation makes me think that it would be well suited to a virtual memory environment. We could dispense with the disk version of the virtual memory, and use Gnu Emacs's current back up scheme. But the memory management by splitting (and I presume, merging) sounds like a definite win and a clean way to do it. It clearly requires a total rework of all the low level stuff though! Cheers! Eliot -- J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206; Moss@cs.umass.edu