Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: Marvellous Memory Munching Make Message-ID: <1992Sep29.100339.2773@cs.few.eur.nl> Keywords: where does it go? what does it do? Sender: news@cs.few.eur.nl Reply-To: pk@cs.few.eur.nl Organization: Erasmus University Rotterdam References: <1992Sep25.020038.28923@citec.oz.au> <1992Sep25.174613.19954@fcom.cc.utah.edu> <1992Sep28.101928.8607@cs.few.eur.nl> <1992Sep28.165610.22836@fcom.cc.utah.edu> Date: Tue, 29 Sep 1992 10:03:39 GMT Lines: 28 In <1992Sep28.165610.22836@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: [...] >Which "new VM system" is this? If you mean the one in 0.1, I submit the >following from Chris Torek, which I hope he doesn't mind me quoting: >]> The BSD make has at least one leak: it calls vfork, then malloc, >]> then exec. This malloc affects the parent as well. It is fixable, >]> but not very cleanly (well, you could change the vfork to fork, I >]> suppose...). >He also went on to say that BSD uses large amounts of memory and that the >current memory management wasn't very efficient, and that a rewrite was on >a project list (not his). I mean the VM system as it appeared in the NET-2 release and which is also in 386bsd. The code therein which sets up the address space for a newly born process pays no attention as to whether it was invoked by the vfork() or fork() system call. I guess vfork() is retained for compatibility reasons only and it isn't even compatible anymore as far as sharing address spaces is concerned. Also, I do not think the memory leak in my copy of make is explained by your description above. Are you sure we are talking about the same version of the sources here? -pk