Review request for 5049299 (original) (raw)

Martin Buchholz martinrb at google.com
Sat Jun 27 17:21:58 UTC 2009

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(SYSclone ...) 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 CLONEVFORK 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>

More information about the core-libs-dev mailing list