2007-11-13
Why vfork() got created (part 2)
Although fork() theoretically copies the address space of the parent
process to create the child's address space, Unix normally does not
actually make a real copy. Instead it marks everything as copy on
write and then waits for
either the parent or the child to dirty a page, whereupon it does copies
only as much as it has to. This makes forks much faster, which is very
important since things in Unix fork a lot.
(Disclaimer: this is the traditional implementation for paged virtual memory. I don't know what V7 did, since it only had swapping.)
At least that is the theory and the ideal, but not in this case the practical.
The second and probably real reason that vfork()
exists is that when UC Berkeley was adding paged virtual memory to
Unix, they couldn't get copy on write working on their cheap Vax 11/750s (although it did work on the
higher end 11/780s). To avoid a fairly bad performance hit on what were
already low end machines, they added vfork() (which doesn't require
copy on write to run fast) and modified sh and csh to use it.
The specific problem was apparently bugs in the 750 microcode that caused writes to read only pages in the stack to not fault correctly. One of the reasons that the 750 was cheaper than the 780 was that it did a number of things in microcode that the 780 did in hardware, which explains why 780s didn't have this problem.
(My source for the details is a message from John Levine here.)