Runtime.exec : vfork() concerns and a fix proposal

[Martin Buchholz]

I agree that your proposal makes the implementation more robust, so if
you are willing to implement it and it doesn't cost too much, then I
would support it.  The current implementation doesn't seem to cause
trouble in practice, or at least we don't see any bug reports.

When you benchmark with open file descriptors, try with and without
FD_CLOEXEC flag set.  Almost all fds should be created with the
FD_CLOEXEC flag set - openjdk is moving in that direction.  When there
are many open files, your implementation may be a weird sort of
optimization.

On Tue, Sep 11, 2018 at 10:51 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:

> The point of this technique is that we minimize the window in the
> child between vfork and the first exec. In fact, we are now fully
> POSIX compliant.

2004-POSIX compliant ... but in the mean time they removed vfork().
But vfork is critical for Google (and probably others)  due to the
momentary overcommit problem on Linux.  Or has that changed somehow?