Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!spool.mu.edu!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Marvellous Memory Munching Make
Message-ID: <1992Sep28.165610.22836@fcom.cc.utah.edu>
Keywords: where does it go? what does it do?
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Sep25.020038.28923@citec.oz.au> <1992Sep25.174613.19954@fcom.cc.utah.edu> <1992Sep28.101928.8607@cs.few.eur.nl>
Date: Mon, 28 Sep 92 16:56:10 GMT
Lines: 46
In article <1992Sep28.101928.8607@cs.few.eur.nl> pk@cs.few.eur.nl writes:
>In <1992Sep25.174613.19954@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>In article <1992Sep25.020038.28923@citec.oz.au> sgccseh@citec.oz.au (Steve Hocking) writes:
>>>
>>> I've noticed that make seems to eat memory like there's no tomorrow.
>>>Often I have to stop & restart a make because gcc et al complains about
>>>being out of memory. I know that if I reinstall with something other than
>>>the default swap size, then the problem will be hidden, but it seems like
>>>this is not the optimal solution. BTW the leak only seems to happen when
>>>make actually kicks off another program.
>
>>This is because of the malloc before the exec. Change the "vfork" used to
>>start the child process to a "fork" and the memory leak will go away. This
>>will make make somewhat slower, but since the malloc occures into the parents
>>heap, this is the culprit. The problem gets worse on larger environments
>>set up by the user.
>
>In the new VM system, the only difference between fork() and vfork() is in
>scheduling: the parent waits until its child either exits or execs. Sharing
>of address spaces on longer occurs.
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).
Terry Lambert
terry_lambert@npd.novell.com
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------