Review request for 5049299 (original) (raw)
Martin Buchholz martinrb at google.com
Wed Jul 1 23:28:25 UTC 2009
- Previous message: Review request for 5049299
- Next message: Review request for 5049299
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I chatted with Tim Bell, and we have go-ahead to put changes into tl after July 13.
I intend to do some more work on clone-exec, putting changes into my mq and keeping webrevs at http://cr.openjdk.java.net/~martin/
Here's a small paranoia increase change I am making to vfork-exec:
- suggest that gcc not inline startChild
- suggest that the compiler not keep resultPid in a register
- use CLONE_VFORK with clone, as suggested by a colleague. The parent has to wait for the child to proceed anyways, and this should be more robust.
diff --git a/src/solaris/native/java/lang/UNIXProcess_md.c b/src/solaris/native/java/lang/UNIXProcess_md.c --- a/src/solaris/native/java/lang/UNIXProcess_md.c +++ b/src/solaris/native/java/lang/UNIXProcess_md.c @@ -718,7 +718,12 @@ /**
- Start a child process running function childProcess.
- This function only returns in the parent.
- We are unusually paranoid; use of clone/vfork is
- especially likely to tickle gcc/glibc bugs. / +#ifdef attribute_noinline / See: sys/cdefs.h */ +attribute_noinline +#endif static pid_t startChild(ChildStuff *c) {
#if START_CHILD_USE_CLONE @@ -733,8 +738,7 @@ return -1; return clone(childProcess, c->clone_stack + START_CHILD_CLONE_STACK_SIZE,
/* CLONE_VFORK | // works, but unnecessary */CLONE_VM | SIGCHLD, c);
CLONE_VFORK | CLONE_VM | SIGCHLD, c);
#else #if START_CHILD_USE_VFORK /* @@ -743,7 +747,7 @@ * as suggested by the scary gcc warning: * warning: variable 'foo' might be clobbered by 'longjmp' or 'vfork' */
- pid_t resultPid = vfork();
- volatile pid_t resultPid = vfork();
#else /* * From Solaris fork(2): In Solaris 10, a call to fork() is
Martin
On Wed, Jul 1, 2009 at 05:55, Michael McMahon<Michael.McMahon at sun.com> wrote:
Can we decide on a plan for this issue? I'd like to have it resolved in good time for M5.
Architecturally, the solution for Solaris is clear I think: posixspawn() of helper program which exec()'s the final target. So, can we recap on what the situation is for Linux? Is it vfork() plus exec()? But ,if (as the man page suggests) vfork() is just a special case of clone(), then are we sure there still isn't too much "stuff happening" between clone()/vfork() and exec() ? Maybe, if this question isn't resolved (or resolvable) soon then should we go ahead with a Solaris only fix? - Michael.
- Previous message: Review request for 5049299
- Next message: Review request for 5049299
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]