6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux

[David Lloyd]

On Mon, Oct 22, 2018 at 1:23 PM Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> Hi all,
[...]
> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now

Note that my patch does not abandon vfork.  It does not even change
the default exec strategy away from vfork, nor does it cause any
obstacle to your proposed change.  It only adds the ability for users
to opt in to the existing posix_spawn implementation on Linux.  It's
just a first step, in whatever direction we might be going, which is
far from decided.  As you and Martin have both implied, it's a good
idea to be very cautious in this area.

> The current posix_spawn() implementation was added to glibc with glibc 2.24. So, what was the state of posix_spawn() before that version? Is it safe to use, does it do the right thing, or will we encounter regressions?

I certainly have not suggested making posix_spawn be the default on
Linux at this time.  But if we don't make it at least a possible
option, it cannot be tested *at all*, by anyone, unless they're
adventurous enough to hack OpenJDK themselves.  The questions you ask
can not be answered without at least making it a choice.

There are many reasonable paths that can be taken after this patch is
merged (if it is):

• It could stop here and keep the status quo; users who have trouble
with the current implementation can try out posix_spawn
• The Linux port could be modified similarly to your proposal to use
the existing jspawnhelper infrastructure with vfork on Linux, while
still allowing posix_spawn to be manually selected
• The Linux port could be modified to use posix_spawn if
gnu_get_libc_version(3) and/or other run-time probes return an
acceptable value, using vfork (either the original or your modified
approach) otherwise, still allowing posix_spawn to be manually
selected

Other possibilities exist as well.  Nothing in this email thread
(AFAICT) invalidates your basic proposal, other than perhaps the
observation that your proposal has similarities to the existing
jspawnhelper path, so that could possibly be utilized.  This patch
only *increases* our possible future choices; it does not impose any
restrictions.

-- 
- DML