Review request for 5049299

[Martin Buchholz]

Although clone(CLONE_VFORK...) didn't work out,
using glibc's vfork instead did.  The glibc code to handle vfork
is quite different from the code for clone(CLONE_VM | CLONE_VFORK),
especially for saving/restoring pids.

This time, I tested on 32-bit and 64-bit Linux.

Michael, please review.

http://cr.openjdk.java.net/~martin/vfork-exec/

As always, we'll need a bug filed.
Synopsis: (process) Use vfork, not fork, on Linux to avoid swap exhaustion

And again, my changes are conflicting with Michael's changes for Solaris.
I will negotiate with Michael for who gets to commit first.
We will likely end up with 4 different strategies for "forking":
fork, clone, vfork, and helper process.

Note to integrators: the process changes continue to be high-risk.
Extra JPRT runs might be a good idea.

Martin


On Tue, Jun 23, 2009 at 07:51, Christos Zoulas <christos at zoulas.com> wrote:

> On Jun 23,  3:33pm, aph at redhat.com (Andrew Haley) wrote:
> -- Subject: Re: Review request for 5049299
>
> | I can debug this.
> |
> | Please try first syscall(SYS_clone ...) to bypass the libc gubbins.
> | That might be all you need.  If that doesn't help I'll have a look.
> |
> | Isn't there some point at which you have to say to a Linux user "Your
> | system is simply misconfigured.  Fix the overcommit parameter and this
> | problem will go away"  ?
>
> Another thing to try is to add CLONE_VFORK to suspend the parent.
>
> christos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090627/e3cc5511/attachment.html>