Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!wupost!spool.mu.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek From: torek@horse.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.bsd Subject: Re: Marvellous Memory Munching Make Date: 4 Oct 1992 21:52:45 GMT Organization: Lawrence Berkeley Laboratory, Berkeley Lines: 25 Message-ID: <26631@dog.ee.lbl.gov> 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> <1992Sep29.100339.2773@cs.few.eur.nl> Reply-To: torek@horse.ee.lbl.gov (Chris Torek) NNTP-Posting-Host: 128.3.112.15 Keywords: where does it go? what does it do? In <1992Sep28.165610.22836@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) quotes me: > 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...). I did say this, and it is wrong. This used to happen under the old VAX/Tahoe/HP300/old-386 VM. The new VM system does not (currently) share modifications to the address space under vfork. >He also went on to say that BSD [make] 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). In fact, rewrites of both `make' and (at least parts of) the VM system are `on the list' (separately). A few years ago, I profiled the new make and found that it spends gobs of time doing variable lookup. The reason is that there may be more than one copy of any given variable (and in fact for variables like $@, there is one copy per rule), but they are all on a single list, so the lookup code has to find them all and decide which is the `right' one. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov