darwin: Use posix_spawn to spawn subprocesses in macOS

[jpcanepa]

Issue

This PR tackles #3050.

Overview

With Big Sur (macOS 11), apple introduced a significant performance degradation when trying to fork()/exec a new child process when the parent has many pages mmaped with MAP_JIT (like, say, a javascript interpreter). At the same time, on macOS spawning a subprocess with posix_spawn (as chromium does) does not incur on the overhead.

This bug impacts electron apps that spawn subprocess, like for example, VSCode. There is an issue filed against electron itself as a consequence.

Using the repro app from the issue, I implemented the forking logic specific to macOS using posix_spawn, as far as I know, doing everything that the normal fork path does, with the extra advantage of having the macOS extension to posix_spawn POSIX_SPAWN_CLOEXEC_DEFAULT that treats all descriptors, regardless if opened or not with O_CLOEXEC, as if they had; that way we can guarantee no descriptors leak into the child process.

[pdesantis]

I verified that spawn times are just as fast with & without JIT using the repro project (https://github.com/deepak1556/libuv-spawn)!

Results taken using a codesigned build, 2016 MacBook Pro, macOS 11.0.1

posix_spawn

Without MAP_JIT

bash-3.2$ ./out/Default/uv_spawn
ls process launched with ID : 79108 and in : 1.23733 ms
ls process exited with status : 0 and in : 5.55769 ms

ls process launched with ID : 79113 and in : 1.41789 ms
ls process exited with status : 0 and in : 5.66987 ms

ls process launched with ID : 79118 and in : 0.89105 ms
ls process exited with status : 0 and in : 4.87111 ms

ls process launched with ID : 79123 and in : 0.794623 ms
ls process exited with status : 0 and in : 4.54644 ms

ls process launched with ID : 79128 and in : 0.868151 ms
ls process exited with status : 0 and in : 4.66897 ms

ls process launched with ID : 79133 and in : 0.998443 ms
ls process exited with status : 0 and in : 5.41041 ms

ls process launched with ID : 79138 and in : 1.06477 ms
ls process exited with status : 0 and in : 5.14938 ms

ls process launched with ID : 79143 and in : 0.964673 ms
ls process exited with status : 0 and in : 5.09582 ms

ls process launched with ID : 79148 and in : 0.887238 ms
ls process exited with status : 0 and in : 4.8716 ms

ls process launched with ID : 79153 and in : 0.932572 ms
ls process exited with status : 0 and in : 4.58974 ms

With MAP_JIT

bash-3.2$ ./out/Default/uv_spawn --use-jit
ls process launched with ID : 79160 and in : 0.98975 ms
ls process exited with status : 0 and in : 4.46968 ms

ls process launched with ID : 79165 and in : 0.763886 ms
ls process exited with status : 0 and in : 3.7277 ms

ls process launched with ID : 79170 and in : 1.10253 ms
ls process exited with status : 0 and in : 4.79186 ms

ls process launched with ID : 79175 and in : 0.923323 ms
ls process exited with status : 0 and in : 5.28865 ms

ls process launched with ID : 79180 and in : 1.03655 ms
ls process exited with status : 0 and in : 5.19892 ms

ls process launched with ID : 79185 and in : 0.891606 ms
ls process exited with status : 0 and in : 5.07491 ms

ls process launched with ID : 79190 and in : 1.13192 ms
ls process exited with status : 0 and in : 6.28628 ms

ls process launched with ID : 79195 and in : 1.1995 ms
ls process exited with status : 0 and in : 5.56335 ms

ls process launched with ID : 79200 and in : 0.999381 ms
ls process exited with status : 0 and in : 5.27073 ms

ls process launched with ID : 79205 and in : 1.11228 ms
ls process exited with status : 0 and in : 5.3832 ms

fork

Compare the results above against the head of the v1.x branch below:

Without MAP_JIT

bash-3.2$ ./out/Default/uv_spawn
ls process launched with ID : 84481 and in : 1.34959 ms
ls process exited with status : 0 and in : 5.45108 ms

ls process launched with ID : 84482 and in : 1.1263 ms
ls process exited with status : 0 and in : 5.045 ms

ls process launched with ID : 84483 and in : 1.02336 ms
ls process exited with status : 0 and in : 5.0336 ms

ls process launched with ID : 84484 and in : 1.09634 ms
ls process exited with status : 0 and in : 4.89075 ms

ls process launched with ID : 84485 and in : 1.00101 ms
ls process exited with status : 0 and in : 4.84648 ms

ls process launched with ID : 84486 and in : 1.80779 ms
ls process exited with status : 0 and in : 6.67846 ms

ls process launched with ID : 84487 and in : 1.26541 ms
ls process exited with status : 0 and in : 5.44206 ms

ls process launched with ID : 84488 and in : 1.02727 ms
ls process exited with status : 0 and in : 4.8705 ms

ls process launched with ID : 84489 and in : 1.07131 ms
ls process exited with status : 0 and in : 5.43011 ms

ls process launched with ID : 84490 and in : 1.07475 ms
ls process exited with status : 0 and in : 4.72903 ms

With MAP_JIT

bash-3.2$ ./out/Default/uv_spawn --use-jit
ls process launched with ID : 84494 and in : 53.6429 ms
ls process exited with status : 0 and in : 57.4913 ms

ls process launched with ID : 84495 and in : 45.3467 ms
ls process exited with status : 0 and in : 48.786 ms

ls process launched with ID : 84496 and in : 44.0292 ms
ls process exited with status : 0 and in : 47.2501 ms

ls process launched with ID : 84497 and in : 45.9806 ms
ls process exited with status : 0 and in : 49.2605 ms

ls process launched with ID : 84498 and in : 46.071 ms
ls process exited with status : 0 and in : 49.3887 ms

ls process launched with ID : 84499 and in : 43.6015 ms
ls process exited with status : 0 and in : 47.0534 ms

ls process launched with ID : 84500 and in : 47.0892 ms
ls process exited with status : 0 and in : 50.5227 ms

ls process launched with ID : 84501 and in : 55.4421 ms
ls process exited with status : 0 and in : 59.0695 ms

ls process launched with ID : 84502 and in : 45.3965 ms
ls process exited with status : 0 and in : 48.9634 ms

ls process launched with ID : 84503 and in : 49.845 ms
ls process exited with status : 0 and in : 53.2581 ms

[jpcanepa]

Switched to a proper PR. Updated the description to include all the information I have about the successful/failed builds and their respective command lines emited by the build systems.

[jpcanepa]

Ok, with the help of @marcello3d the build is now back up, and so I could run the unit tests and fix all but one. I've rewritten the PR description to reflect the current state of affairs.

[bnoordhuis]

I did a very light review, mostly on style issues.

I feel the big #ifdef __APPLE__ block in the middle of an already large function is not so nice, it makes things hard to follow.

It should probably be broken out into a separate function, possibly in a different file like src/unix/darwin.c.

[jpcanepa]

Moved the process spawn and initialization logic to a separate function which in turn delegates to a purpose specific one (posix_spawn or fork+exec). Also, corrected all formatting and convenction issues.

[jpcanepa]

Uh oh. Apparently CI did not like the changes to the stubs. Berp, no, I'm an idiot. I exposed the innards of the function now to every build.

[jpcanepa]

Thanks @bnoordhuis for the review! I've addressed all comments.

[bnoordhuis]

I don't expect to have much time in the coming weeks so it would be good if other maintainers can also help review.

[jpcanepa]

Resolved all pointed out issues. I refactored the initialization of the posix_spawnattr and posix_spawn_file_actions to separate functions that either return a properly initialized object on success, or an already-destroyed one on failure, making the cleanup in the top level more simple and also the main happy path more readable.

[jpcanepa]

Seemed to me that the failure of either of these functions was not a reason to signal failure to the caller.

[vtjnash]

optional: I'd perhaps suggest making them call abort instead?

[jpcanepa]

Your call, @vtjnash. If you think that failure of these calls warrants termination, let's do that.

[vtjnash]

Is there any documentation on this? The best I could find is the source code, which indicates that NULL is invalid:

https://github.com/Hardercoder/opensourceapple-tarballs/blob/235bdeaf60d803fb88de0da8d5a53d67e7eaafd0/xnu-6153.11.26/libsyscall/wrappers/spawn/posix_spawn.c#L2193

[jpcanepa]

None that I could find, hence the caveat in the description. I used the source for reference too, but failed to check that restriction. The ngroups set to zero means that that var will never be read (besides the if call, of course), so I think we can just pass in a pointer to a gid_t and that should be enough...