Review request for 5049299

[Martin Buchholz]

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:
> 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.
>