Xref: utzoo comp.editors:1203 comp.lang.c:24800 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!texbell!sugar!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.editors,comp.lang.c Subject: Re: GNU Emacs, memory usage, releasing Keywords: GNU emacs malloc memory working set gap editor Message-ID: Date: 1 Jan 90 00:01:43 GMT References: <1558@aber-cs.UUCP> <32534@news.Think.COM> Reply-To: peter@sugar.lonestar.org (Peter da Silva) Followup-To: comp.lang.c Organization: Xenix Support, FICC Lines: 18 In article <32534@news.Think.COM> rlk@think.com (Robert Krawitz) writes: > 2) Emacs dies very quickly after its virtual size exceeds 16 Mbytes, This is a scary thought all by itself, but... > due to the 24 bit pointers used (the top 8 bits are used as tag bits for > the Lisp interpreter). 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... Not to mention that making assumptions about pointer formats is dangerous in and of itself. Certainly you can't *use* such pointers without stripping them, which adds overhead to every memory reference. And (per recent discussions in comp.std.c) there are architectures out there that won't even let you load them into an address register. -- `-_-' Peter da Silva. +1 713 274 5180. . 'U` Also or . "It was just dumb luck that Unix managed to break through the Stupidity Barrier and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com