mrd@sun.soe.clarkson.edu (Michael DeCorte) (02/14/89)
I have a question about the garbage collection routines in Gnu Emacs. When a garbage collection occurs exactly what part of the lisp data are searched. To be more specific; as you can't tell the difference between code and data in lisp I would like to know if everything is searched. Eg. If I load up Gnus to read my news and exit gnus. After a few hours I have not entered gnus but I have had several garbage collections. Was the memory occupied by 1) gnus lisp code 2) gnus data code searched during all of the garbage collections, some of them (which ones), none of them? The reason I ask is because as we all know Emacs is a bit well... memory hungry. Now this isn't so bad if most of the memory is paged out to disk and just sits there until actually used, (eg. if I am using mh-e there isn't any reason that gnus has to be in my real memory) but I am finding that after running emacs for a long time it grows a lot (expected) and the amount of paging on my poor little 3/50's seems to increase (even though it shouldn't). So, is my worst nightmare true? Emacs searches though every little grubby bit of lisp anything everytime it has to do a garbage collection and thereby is distroying my poor little 50's? -- Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676 Internet: mrd@sun.soe.clarkson.edu // Bitnet: mrd@clutx.bitnet --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
moore%cdr.utah.edu@wasatch.UUCP (Tim Moore) (02/15/89)
In article <MRD.89Feb13232448@sun.soe.clarkson.edu> mrd@sun.soe.clarkson.edu (Michael DeCorte) writes: >Eg. If I load up Gnus to read my news and exit gnus. After a few hours >I have not entered gnus but I have had several garbage collections. Was >the memory occupied by >1) gnus lisp code >2) gnus data code >searched during all of the garbage collections, some of them (which ones), >none of them? Yes. Emacs has a mark-sweep collector which implies that all accessible structures are marked and ALL accessible memory is sweeped (well, not all; see below). >So, is my worst nightmare true? Emacs searches though every little >grubby bit of lisp anything everytime it has to do a garbage >collection and thereby is distroying my poor little 50's? The Emacs garbage collector doesn't mark (or sweep) pure memory, which is memory that is already allocated at the time that emacs is undumped. You could try putting (load "gnus") in your site-init.el; increase the PURESIZE in config.h and remake emacs. This puts the code for gnus in the text segment of Emacs (which means its sharable, not a big deal for you). No guarantee that this will solve your problem, though. -Tim Moore 4560 M.E.B. internet:moore@cs.utah.edu University of Utah ABUSENET:{ut-sally,hplabs}!utah-cs!moore Salt Lake City, UT 84112
montnaro@sprite.steinmetz.ge.com (Skip Montanaro) (02/15/89)
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?) -- Skip Montanaro (montanaro@sprite.steinmetz.ge.com, montanaro@ge-crd.arpa)
jr@bbn.com (John Robinson) (02/16/89)
In article <MONTNARO.89Feb15011650@sprite.steinmetz.ge.com>, montnaro@sprite (Skip Montanaro) writes: > 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). > ... > Is this a bug in Emacs or a feature of >the malloc/free system (or something else that isn't obvious to me?) 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... One thing you might try to train yourself to do is to start a fresh emacs when you are editing one of the big files. Of course this is no help if you need to cut and paste stuff from some other buffer, but if you do this you can exit the big emacs when done with the large file and the prior one will still be small (for large values of small). -- /jr jr@bbn.com or bbn!jr
mike@thor.stolaf.edu (Mike Haertel) (02/17/89)
In article <MONTNARO.89Feb15011650@sprite.steinmetz.ge.com> <montanaro@sprite.steinmetz.ge.com> (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.)
cwitty@csli.Stanford.EDU (Carl Witty) (02/17/89)
In article <36070@bbn.COM>, jr@bbn (John Robinson) writes: >In article <MONTNARO.89Feb15011650@sprite.steinmetz.ge.com>, 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