6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux

[Florian Weimer]

* Thomas Stüfe:

> So far I have not read a single technical reason in this thread why
> vfork needs to be abandoned now - apart from it being obsolete. If you
> read my initial thread from September, you know that I think we have
> understood vfork's shortcomings very well, and that our (SAPs)
> proposed patch shows that they can be dealt with. In our port, our
> vfork+exec*2 is solid since many years, without any issues.

The main problem for vfork in application code is that you need to *all*
disable signals, even signals used by the implementation.  If a signal
handler runs by accident while the vfork is active, memory corruption is
practically guaranteed.  The only way to disable the signals is with a
direct system call; sigprocmask/pthread_sigmask do not work.

Does your implementation do this?

> 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?

It uses fork by default.  It can be told to use vfork, via
POSIX_SPAWN_USEVFORK, but then it is buggy.  For generic JDK code, this
seems hardly appropriate.

> My Ubuntu 16.04 box runs glibc 2.23. Arguably, Ubuntu 16.04 is quite a
> common distro. I have to check our machines at work, but I am very
> sure that our zoo of SLES and RHEL servers do not all run glibc>=2.24,
> especially on the more exotic architectures.

In glibc, the vfork-based performance does not bring in any new ABIs, so
it is in theory backportable.  The main risk is that the vfork
optimization landed in glibc 2.24, and the PID cache was removed in
glibc 2.25.  vfork with the PID cache was really iffy, but I would not
recommend to backport the PID cache removal.  But Debian 9/stretch uses
glibc 2.24, and I think that shows that the vfork optimization with the
PID cache should be safe enough.  (Of course you need to remove the
assert that fires if the vfork does not actually stop the parent process
and is implemented as a fork; the glibc implementation still works, but
with somewhat degraded error checking.)

How far back would you want to see this changed?  Debian jessie and Red
Hat Enterprise Linux 6 would be rather unlikely.  If you want to target
those, your only chance is to essentially duplicate the glibc
implementation in OpenJDK.

Thanks,
Florian