Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!hplabs!hpda!hpcupt1!renglish
From: renglish@hpcupt1.HP.COM (Robert English)
Newsgroups: comp.arch
Subject: Re: Re: Paging page tables & SUN4s
Message-ID: <3830012@hpcupt1.HP.COM>
Date: 6 Jul 90 22:25:38 GMT
References: <1122@sirius.ucs.adelaide.edu.au>
Organization: Hewlett Packard, Cupertino
Lines: 40

> / lkaplan@bbn.com (Larry Kaplan) /  6:49 am  Jul  6, 1990 /

> The idea behind 
> copy-on-write is that a proper fork() requires NO EXTRA physical memory for 
> the child process (except that required for kernel data structures and page 
> tables).  You probably end up needing one stack page pretty soon.  Virtual 
> memory is VIRTUAL.  Who cares if you were running out in one process?  You get
> an entire new address space in the next.  This implementation of fork() is
> what fork() was always intended to be, as far as I can tell.  By doing fork()
> correctly, the need for a separate vfork() disappears (as stated in the BSD
> man pages).

Ain't necessarily so, for a couple of reasons.

First, while vfork() was a hack intended to get around the absence of a
copy-on-write scheme, it has different semantics from a regular fork(),
and those semantics can sometimes be useful.  /bin/csh, for example,
takes advantage of them.  Such use may not be wise, but it does exist,
and if you just get rid of vfork(), there will be programs that break.
Not many, but some.

Second, and more important from an architectural point of view,
vfork-exec is usually faster than fork-exec, even when copy-on-write
is implemented.  Whenever you fork a process, you have to copy its data
structures.  For a large process, the work of setting up an entire
virtual memory structure for a process and then immediately tearing it
down can be significant, even when the process's data is not actually
copied.  While one could design a VM system so that even that work was
done lazily, that would entail a lot of complexity just to avoid
implementing vfork().  It doesn't quite sound worth it to me, but
perhaps that's just prejudice.

Finally, all of this discussion misses the point that the normal
performance-critical sequence is a fork followed by some kernel data
structure manipulations and an exec, and that both performance and
purity could be achieved by providing a single system call that performs
the whole sequence.

--bob--
renglish@hpda