RFR: JDK-8274320: os::fork_and_exec() should be using posix_spawn
stuefe at openjdk.java.net
Sat Oct 30 06:25:10 UTC 2021
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.
> - 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?
More information about the hotspot-runtime-dev