RFR(s): 8212828: (process) Change the Process launch mechanism default on Linux to be posix_spawn

[Roger Riggs]

Hi Thomas,

On 02/06/2019 04:29 AM, Thomas Stüfe wrote:
> Hi all
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213192
> webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8213192--(process)-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8213192--%28process%29-change-the-process-launch-mechanism-default-on-linux-to-be-posix_spawn/webrev.00/webrev/index.html>
>
> (@Roger: I hope you do not mind? The bug is assigned to you but since 
> I happened to play around with posix_spawn I prepared this webrev. If 
> you rather do this change, that is fine and I will leave it to you.)
no problem, I hadn't gotten to it.  Thanks for proposing it.
>
> When we added the possibility to use posix_spawn as underlying 
> implementation for Runtime.exec() on Linux with 
> https://bugs.openjdk.java.net/browse/JDK-8212828, we agreed to keep 
> VFORK as default until work on 13 starts. So now would be a good time 
> to switch the default to posix_spawn to get a good testing window. 
> Note that at SAP we run our VMs internally with posix_spawn as default 
> since some months and have not seen problems.
>
> As for the fix, I added a test which tests that the default is indeed 
> posix_spawn - not sure whether this is overdoing it though. Also, I 
> use strace for the test, and /bin/true, and while strace is usually 
> available and reachable by path resolution, I am afraid on some test 
> machines it may not. What do you think, should I leave the test out?
The test is a bit quirky but should work ok.
I'd leave it in until it fails and re-evaluate then.

If it fails on some systems, we can either configure them out or
just skip the test if the process launch of strace fails.  (Throw 
SkippedException).
>
> The fix ran through all java/lang/ProcessBuilder jtreg tests ok.
I'll run the patch through the usual CI build here too.

Thanks, Roger

>
> Thanks, Thomas
>