RFR: JDK-8274320: os::fork_and_exec() should be using posix_spawn
stuefe at openjdk.java.net
Wed Oct 6 06:52:13 UTC 2021
On Wed, 29 Sep 2021 06:11:27 GMT, David Holmes <dholmes at openjdk.org> wrote:
> Hi Thomas,
> There is a crucial difference between the requirements of os::fork_and_exec versus the Java Runtime.exec call - in the VM we need to use an async-signal-safe function where possible. fork() is async-signal-safe but posix_spawn is not.
> Cheers, David
fork() is not async-signal safe either. Since fork() can cause the execution of at-fork handlers.
* POSIX.1-2001 TC1 clarified that if an application calls
fork(2) from a signal handler and any of the fork handlers
registered by pthread_atfork(3) calls a function that is not
async-signal-safe, the behavior is undefined. A future
revision of the standard is likely to remove fork(2) from the
list of async-signal-safe functions.
Therefore I think we don't lose anything by moving to posix_spawn(). But we gain reliability in high-footprint scenarios.
For me, this is an important point. Analysis options such as OnError should be very reliable. They are often used in support situations where time is short and customer patience is limited. Failing analysis causes more iterations or may make analysis even impossible.
More information about the hotspot-runtime-dev