Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!talos!kjones From: kjones@talos.uu.net (Kyle Jones) Newsgroups: comp.lang.c Subject: Re: GNU Emacs, memory usage, releasing Keywords: GNU emacs malloc memory working set gap editor Message-ID: <1990Jan2.151615.19098@talos.uu.net> Date: 2 Jan 90 15:16:15 GMT References: <1558@aber-cs.UUCP> <32534@news.Think.COM> Reply-To: kjones@talos.uu.net Lines: 19 Robert Krawitz writes: > 2) Emacs dies very quickly after its virtual size exceeds 16 Mbytes, > due to the 24 bit pointers used (the top 8 bits are used as tag bits for > the Lisp interpreter). Peter da Silva writes: > Come *ON*, why is this accepted? I remember not so very long ago > people were flaming Microsoft for doing this on the Macintosh, which > led to Microsoft applications not working on >1MB machines after the > extra bits started getting decoded... It's not really accepted as much as it's tolerated, simply because the vast majority of Emacs users are not inconvenienced by the 16Mbyte limit. (Leonard Zubkoff pointed out only 5 type bits are actually needed currently, so Emacs can be compiled to handle 64 Mbytes of memory before it dies.) If I had been in on the early development of GNU Emacs I would have indeed screeched and howled about the pointer munging. But as it stands now, the inconvenience of the memory limitation is far outweighed by the work necessary to fix the problem.