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

[Thomas Stuefe]

On Sat, 25 Sep 2021 16:16:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi, may I have reviews for this small patch please?
> 
> `os::fork_and_exec()`, used in the hotspot to spawn child programs (scripts etc) in error situations, should be using `posix_spawn()`. 
> 
> ATM it uses either `fork()` or `vfork()`. `vfork()` got deprecated on MacOS and we get build errors (JDK-8274293) - even though in this case it would be completely fine to use. This leaves us with `fork()` for MacOS, which has the known problems with large-footprint-parents. This matters here especially since we also use os::fork_and_exec to implement `-XX:OnError` for OOM situations.
> 
> We already use posix_spawn() as default for Runtime.exec() since JDK 15, and it is available on all our Unices. We also should use it here.
> 
> I kept the name of the function (fork_and_exec) since people know it, even though it's more incorrect now than before.
> 
> Tests:
> - manual tests using -XX:OnError with various scripts, including checking that env variables are passed correctly
> - manually ran runtime/ErrorHandling tests
> - GHAs

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> Hi Thomas,
> 
> On 29/10/2021 8:47 pm, Thomas Stuefe wrote:
> 
> > On Fri, 29 Oct 2021 10:29:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
> > > Change looks technically good to me, but I can not judge if we can rely on async-signal-safety of posix_spawn. I guess we have to wait until glibc folks have discussed that.
> > 
> > 
> > Thank you Martin.
> > @dholmes-ora : do you have an idea how we could resolve this deadlock? Even with input from the glibc folks, a number of questions will remain unanswered (eg what about the other libcs).
> 
> I've withdrawn my objection to this patch (see response to Florian). Given the advantage of posix_spawn in terms of memory management, and the fact no solution is guaranteed async-signal-safe, you may as well give this a go.
> 
> Cheers, David

Thank you David! Would you then approve it or should I look for a second Reviewer?

-------------

PR: https://git.openjdk.java.net/jdk/pull/5698