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

Thomas Stuefe 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

Hi David,

fork() is not async-signal safe either. Since fork() can cause the execution of at-fork handlers.

https://man7.org/linux/man-pages/man7/signal-safety.7.html


       *  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.

Cheers, Thomas

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

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


More information about the hotspot-runtime-dev mailing list