Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!labrea!csli!cwitty From: cwitty@csli.Stanford.EDU (Carl Witty) Newsgroups: gnu.emacs Subject: Re: garbage collection Message-ID: <7616@csli.STANFORD.EDU> Date: 17 Feb 89 04:23:13 GMT References: <36070@bbn.COM> Sender: cwitty@csli.STANFORD.EDU Reply-To: cwitty@csli.Stanford.EDU (Carl Witty) Organization: Center for the Study of Language and Information, Stanford U. Lines: 20 In-reply-to: jr@bbn.com (John Robinson) In article <36070@bbn.COM>, jr@bbn (John Robinson) writes: >In article , montnaro@sprite (Skip Montanaro) writes: [if a large file is edited, and then the buffer is killed, the memory is not returned to the operating system.] >The memory that emacs' garbage collector frees is put onto its free >list, but is not returned to the system. At least the garbage >collector shouldn't be triggered again for a long time... ... This assumes that the garbage collector is triggered when emacs runs out of free space, which is actually incorrect. The garbage collector is called whenever "you cons more than gc-cons-threshold bytes of Lisp data since previous garbage collection." (From the documentation of garbage-collect.) When emacs runs out of free space, it does not call for a garbage collection, but rather just asks for more memory from the operating system. Carl Witty cwitty@csli.Stanford.EDU