6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux (original) (raw)

Thomas Stüfe thomas.stuefe at gmail.com
Fri Oct 19 06:55:50 UTC 2018

Hi David,

(for convenience, here the old thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html)

I would rather not expose a third way to spawn to the end user. As a test switch for developers, this seems fine.

AFAIK (and someone please correct me if I am wrong) posix_spawn is not the magical third way beside fork and vfork, it is just a wrapper around fork/vfork and exec. Especially posix_spawn(), if using fork(), will still have the same pitfalls raw fork() has - quasi-random ENOMEM if we hit the overcommit heuristic, and inferior performance compared to vfork. So you have nothing gained, you have just relegated the fork/vfork decision down to a different layer, one which you have little control over. And since that fork/vfork decision is kind of important, you need that contol.

Note that glibc has a flag to force always vfork behavior: POSIX_SPAWN_USEVFORK. The question is, how tight do we bind us to GNU-only features, since we may run on linux with a different libc, e.g. on Alpine we use muslc.

My proposal, vfork() + the exec-twice-trick, is IMHO the best way to go. That exec-twice trick takes the sting away from vfork. After Martin made supportive noises in the other mail thread, I have planned in some time later this year to produce a patch for this.

--

However: I just realized that my proposal (vfork() + exec-twice-trick) is very close, implementation wise, to the (posix_spawn() + POSIX_SPAWN_USEVFORK + jspawnhelper). The jspawnhelper already implements the exec-twice trick, if only for different reasons than to get away from vfork dangers. Advantage of this implementation would be that very little code would have to change. Disadvantage, in my eyes, is that we bind us to glibc, and an aesthetic side: calling an OS API but needing it to work in one specific way feels like programming with mechanical gloves...

Thanks & Best Regards, Thomas

(Copying Martin, I'm curious what he thinks)

--

On Thu, Oct 18, 2018 at 11:43 PM David Lloyd <david.lloyd at redhat.com> wrote:

The issue 6850720 isn't exactly to use POSIXSPAWN for process launching on Linux, but it's the closest I could find out of what are really a surprisingly large number of issues that refer to posixspawn in one way or another relating to ProcessImpl. There's a different issue to move from vfork to posixspawn on Solaris, but I wasn't sure if that one was quite right to hang this off of. Maybe it should be yet another issue of its own. Anyway: this is a follow-up to the email thread entitled "Runtime.exec : vfork() concerns and a fix proposal", where it was casually mentioned that maybe posixspawn could become an option on Linux, whereafter it could be thoroughly tested by brave individuals and eventually maybe become the default on that platform, obsoleting the vfork support for good. The following patch does just that. I've tested it launching a multi-process WildFly instance a bunch of times, in conjunction with the conveniently existent "jdk.lang.Process.launchMechanism" property, and nothing exploded so here it is. The usual deal with git patches: apply directly through "patch -p1". commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 Author: David M. Lloyd <david.lloyd at redhat.com> Date: Thu Oct 18 15:56:37 2018 -0500 [JDK-6850720] Enable POSIXSPAWN as an option for child process creation on Linux diff --git a/make/launcher/Launcher-java.base.gmk b/make/launcher/Launcher-java.base.gmk index 0ce0287d2be..c28fe42d102 100644 --- a/make/launcher/Launcher-java.base.gmk +++ b/make/launcher/Launcher-java.base.gmk @@ -84,7 +84,7 @@ endif ################################################################################ -ifneq ($(findstring $(OPENJDKTARGETOS), macosx solaris aix), ) +ifneq ($(findstring $(OPENJDKTARGETOS), macosx solaris aix linux), ) _$(eval $(call SetupJdkExecutable, BUILDJSPAWNHELPER, _ _NAME := jspawnhelper, _ _SRC := (TOPDIR)/src/(TOPDIR)/src/(TOPDIR)/src/(MODULE)/unix/native/jspawnhelper, _ diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java b/src/java.base/unix/classes/java/lang/ProcessImpl.java index 368a4f7380b..959e50dfecd 100644 --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { private static enum Platform { - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIXSPAWN, LaunchMechanism.FORK), BSD(LaunchMechanism.POSIXSPAWN, LaunchMechanism.FORK), diff --git a/src/java.base/unix/native/libjava/ProcessImplmd.c b/src/java.base/unix/native/libjava/ProcessImplmd.c index 533584fdb7a..6869a64f2cc 100644 --- a/src/java.base/unix/native/libjava/ProcessImplmd.c +++ b/src/java.base/unix/native/libjava/ProcessImplmd.c @@ -44,7 +44,7 @@ #include <signal.h> #include <string.h> -#if defined(solaris) || defined(ALLBSDSOURCE) || defined(AIX) +#if defined(solaris) || defined(ALLBSDSOURCE) || defined(AIX) || defined(linux) #include <spawn.h> #endif @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { return resultPid; } -#if defined(solaris) || defined(ALLBSDSOURCE) || defined(AIX) +#if defined(solaris) || defined(ALLBSDSOURCE) || defined(AIX) || defined(linux) static pidt spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) { pidt resultPid; @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) #endif case MODEFORK: return forkChild(c); -#if defined(solaris) || defined(ALLBSDSOURCE) || defined(AIX) +#if defined(solaris) || defined(ALLBSDSOURCE) || defined(AIX) || defined(linux) case MODEPOSIXSPAWN: return spawnChild(env, process, c, helperpath); #endif

More information about the core-libs-dev mailing list