*BSD News Article 6030


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