JDK-8212828 : (process) Provide a way for Runtime.exec to use posix_spawn on linux
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 12
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-23
  • Updated: 2020-08-12
  • Resolved: 2018-11-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
Related Reports
Blocks :  
CSR :  
Duplicate :  
Relates :  
Relates :  
Sub Tasks
JDK-8214454 :  
Currently, on Linux, Runtime.exec() uses fork() or vfork(), with vfork() being the default. This is controlled by -Djdk.lang.Process.launchMechanism, with allowed values of "FORK" and "VFORK" on linux.

Enable the use of posix_spawn() on Linux as it is used already on Solaris, BSD and AIX. But do not change the default. 

Purpose of this patch is to be able to test posix_spawn() on Linux, with the expressed wish to change the default to posix_spawn() later.

See also discussion thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056122.html
Additional information on this Fix Request: The established (since decades) method of forking off on Linux JDKs has been to use vfork(3). Using vfork is risky. There are chances of crashing the parent process. The risk of this happening is very low, but not zero. Since analyzing those crashes and attributing them to vfork(3) is very difficult, there may be a number of unreported cases not associated with vfork(3) but in fact caused by it. The patch adds a second, safer way to fork off childs, using posix_spawn(3). This one has been the default on other platforms for quite some while. The patch does not change the default fork mode - which remains vfork(3). So installations would not be affected unless they explicitly choose to use vfork(3). Having this possibility would allow us to use posix_spawn(3) in situations where we are analyzing crashes and want to exclude vfork(3) as a cause. It also would enable us to use posix_spawn(3) as a safe alternative by default if we choose to do so.

Fix Request: I'd like to put this fix request for reconsideration. It had already been approved for jdk11u. The approval was later withdrawn because issues with the CSR backport process had to be sorted out. As for the fix, I think it is really something that shall be brought into jdk11u. It will add the posibility to use an additional spawn mechanism which uses posix_spawn. posix_spawn should provide improved stability and is considered the more "more modern" api compared to vfork. The latter api that is being deprecated. The risk of the fix is very low, as the default pathes will not be changed. It just adds an additional option which might be appealing for some users. The backport CSR for this issue (JDK-8220362) is currently under review. In case this backport is being accepted, the jdk11u maintainer should probably add his review there.

Per the guidance given in https://mail.openjdk.java.net/pipermail/csr-discuss/2018-December/000078.html procedurally, please * Manually create a backport for the 11u change; this can be targeted at "11-pool" * Create a CSR from that backport. This can largely be cut-and-pasted from the existing request. I will than review the request.

Hi Robert, I'm so confused :) The "master" CSR for 12 was this: https://bugs.openjdk.java.net/browse/JDK-8214511 and I made a fix request for 11u in that issue. It got approved, but then the labels disappeared again. So, should make a verbatim copy of this CSR for 11u? Or how does this work? I believe there was a documentation somewhere for outsiders but I cannot find it anymore.

Hi Thomas, can you file a CSR request for JDK11u please?

Removing fix-yes - I see the CSR hasn't actually been approved for 11. Leave this with me.

Fix Request: This patch would be nice to have in 11 since it would allow us to roll out posix_spawn() as a default option with jdk13 more confidently: we would get more users to test it. The patch adds a new, third, non-default jdk.lang.Process.launchMechanism to Runtime.exec, which uses posix_spawn(). In discussions it was found to be, in theory, to be safer than the current default launch technique, which uses vfork(). The consent was that we did not want to change the default just yet, not in jdk12. But to add the jdk.lang.Process.launchMechanism=POSIX_SPAWN option as a non-default, for early adaptors to play around with. Then, with jdk13, we would switch to POSIX_SPAWN as a default (see also JDK-8213192). I would like to see this option downported, as non-default, to 11u. Since that would give us way more testers. The risk is smallish. Adaptors may use this feature, which is clearly still experimental, and run into errors. But since the default is unchanged, the majority of folks should not care. The patch applies to jdk11u cleanly.