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 <chris...@zoulas.com> wrote: > On Jun 23, 3:33pm, a...@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 >
