RFR: JDK-8274320: os::fork_and_exec() should be using posix_spawn

[Florian Weimer]

* Thomas Stüfe:

> The oldest glibc release we need is difficult to estimate, it depends
> on what individual downstream vendors want to do with the JVM. If we
> don't downport this patch I guess glibc 2.24 would be a safe bet. From
> what I can see this is when posix_spawn on Linux started using
> clone(). The only still supported commercial distro with an older
> glibc I am aware of is Ubuntu 16.04.

Red Hat Enterprise Linux 7 is based on glibc 2.17.  Its posix_spawn
implementation uses vfork, but it's doing so incorrectly because it does
not block signals (signals delivered to the new subprocess before execve
may corrupt the parent process because of the shared TCB).  I don't know
if this is a problem in practice.  In the end, it's trading one set of
potential issues for another (on el7, it's strictly an improvement on
el8 and later).

Adoptium builds still target el7 and include OpenJDK 17.  I don't know
if they plan to ship OpenJDK 18 builds.

> So IUUC we could deadlock today with fork() too, if we crash inside
> malloc. I'd say posix_spawn sounds good then, since according to
> Florian it's async-signal safe, and it works better under memory
> pressure. We still don't know what other libc's do.

There's one caveat: posix_spawn is not *guaranteed* to be
async-signal-safe, it's just how the current implementation behaves.
Maybe we could promise that it remains async-signal-safe as a glibc
extension, or even update POSIX accordingly.  Most of the work
posix_spawn does happens in the new subprocess by its nature, and with
the (very desirable) vfork optimization, the implementation on a
traditional kernel has to stick to a subset of the async-signal-safe
functions anyway.

Thanks,
Florian