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.mcma...@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: > posix_spawn() 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. >
