(original) (raw)
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 Jun 23, �3:33pm, aph@redhat.com (Andrew Haley) wrote:
\-- Subject: Re: Review request for 5049299
| I can debug this.Another thing to try is to add CLONE\_VFORK to suspend the parent.
|
| 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" �?
christos