Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!xanth!mcnc!rti!xyzzy!meissner From: meissner@dg-rtp.dg.com (Michael Meissner) Newsgroups: comp.emacs Subject: Re: Software virtual memory for GNU? Message-ID: Date: 29 Nov 89 00:06:34 GMT References: <5627@wpi.wpi.edu> Sender: usenet@xyzzy.UUCP Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 23 In-reply-to: jhallen@wpi.wpi.edu's message of 15 Nov 89 21:03:47 GMT In article <5627@wpi.wpi.edu> jhallen@wpi.wpi.edu (Joseph H Allen) writes: | This is kind of along the lines with the earlier discussion about memory | allocation in GNU Emacs: Is there any plans to replace the 'hole' method of | buffer management with a page-based software virtual memory system? This | would eliminate the file size limits caused by UNIX process size limits and | would make editing large files less painful (no hole movement delays). It | would also allow limits to be placed on the amount of memory emacs uses | without limiting the maximum editable file size. I would certainly prefer | this to any kind of heap compaction- after all, what we don't need is longer | "Garbage collection...Done." delays. I don't know about the FSF and the long awaited version 19 rewrite of GNU emacs. However, given that gnu emacs restricts all pointers to 24 bits on normal 32 bit machines, I would think this would have to be overcome before worrying about file size limits and process limits. Only if your process or file limits are real small (less than 16 megabytes) would these limits affect you. -- Michael Meissner, Data General. Until 12/15: meissner@dg-rtp.DG.COM After 12/15: meissner@osf.org Brought to you by Super Global Mega Corp .com