Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!nic.MR.NET!thor!mike From: mike@thor.stolaf.edu (Mike Haertel) Newsgroups: gnu.emacs Subject: Re: garbage collection Message-ID: <1197@thor.stolaf.edu> Date: 17 Feb 89 02:43:11 GMT References: Reply-To: mike@stolaf.edu Organization: St. Olaf College; Northfield, MN Lines: 26 In article (Skip Montanaro) writes: >Michel DeCorte asked some garbage collection questions. I don't have any >answers, but I have what I think is a related question. I keep Emacs running >in a window on my Sun for long periods. Normally, I'm just doing the usual >text editing sort of things. Occasionally I have to edit a really huge file >-- many megabytes -- and Emacs gladly mallocs virtual memory to get space >for the file. Unfortunately, when I'm finished editing such a file and have >deleted its buffer, Emacs seems to not give the space back to the operating >system (no matter how many times I garbage collect). I'm often left with so >little free virtual memory that I can't run other jobs. I must kill the >Emacs session to free up the space. Is this a bug in Emacs or a feature of >the malloc/free system (or something else that isn't obvious to me?) I have never *ever* seen a Unix process exhibit anything but nondecreasing behavior in memory use (i.e., some don't grow, others do, none shrink). The capability is certainly supposed to exist (sbrk(-n)). The new malloc I am writing for GNU will be able to return stuff to the OS in this way, but it won't help much. Why not? Because free space takes the form of lots of little holes in the middle of the heap. You can't arbitrarily move objects around on hardware that doesn't have forwarding pointers, so there is no way to put all this free space at the top of user memory to be unsbrk()ed. You could have a system call to return arbitrary chunks of memory to the system, but the effect is that another layer of something very like malloc would have to be implemented in the kernel where, unlike malloc, the user would be unable to change its policy. (You can always write your own malloc.)