vfork instead of fork for fork+exec?

[Martin Buchholz]

On Sat, May 16, 2009 at 09:03, Christos Zoulas <christos at zoulas.com> wrote:
> On May 16,  5:12pm, dms at samersoff.net (Dmitry Samersoff) wrote:
> -- Subject: Re: vfork instead of fork for fork+exec?
>
> | Charles,
> |
> | On BSD vfork() stops parent process until child exited or call exec.
> | It's not acceptable in multithreaded environment.
>
> Yes, this could be a problem if the program does not run exec
> immediately after vfork(), but in practice most programs run exec,
> a couple of dups, and vfork because there is not much else you can
> legally do without trashing the state of your parent.

The JDK needs to do the following after (v)fork():
- close file descriptors
- maybe chdir
- maybe replace environ
- communicate success/failure to parent

       The vfork() function has the same effect
       as fork(2), except that the behavior is undefined if the  process  cre-
       ated  by vfork() either modifies any data other than a variable of type
       pid_t used to store the return value from vfork(), or returns from  the
       function  in  which  vfork()  was  called,  or calls any other function
       before successfully calling _exit(2) or one of the  exec(3)  family  of
       functions.

Martin

> | Also real performance difference between fork() and vfork() is not huge
> |   because all modern kernels use copy-on-write and copy only in-kernel
> | page table, not pages it self.
>
> This is not true, because the child process still needs to do a
> lot of VM work to setup/copy the page table entries. The larger
> the process is the bigger the penalty, and java processes at least
> where I work are very large. 4.4BSD removed vfork on that assumption,
> and then we did some performance testing on NetBSD and we ended up
> putting it back, and making the shell use it for significant
> performance improvements.
>
> Yes vfork is a weird syscall, annoying and difficult to use, but please
> don't make performance claims without actually doing any tests.
>
> I can try to dig up our performance numbers if you like.
>
> christos
>
>