jhallen@wpi.wpi.edu (Joseph H Allen) (11/16/89)
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. Joe
jhallen @wpi.wpi.EDU (Joseph H Allen) (11/16/89)
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. Joe
meissner@dg-rtp.dg.com (Michael Meissner) (11/29/89)
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