The issue with this test, and the test of JDK-8322324, seems to be that the forked processes write to stderr/stdout, without this output being read before the process terminates. The buffer might fill up if the output is not being read, which means that the process will stall when writing (see stack trace in JBS issue).
`OutputAnalyzer` has ways to prevent this by continuously reading from the output streams in separate threads, but because the current code calls `Process::waitFor` before creating the `OutputAnalyzer`, we never actually read the written output of the fork, which occasionally results in a stall and subsequent timeout. The fix proposed by this patch is to use `ProcessTools::startProcess`, instead of `ProcessBuilder::start`, which will also start the necessary reader threads, preventing a stall. Incidentally, `startProcess` also has built-in timeout handling which we can use. Testing: - 500 runs of both java/foreign/TestStubAllocFailure.java and java/foreign/critical/TestCriticalUpcall on various Windows x64 hosts (100 iterations was enough to observe the failure twice). - `jdk_foreign` suite. ------------- Commit messages: - use ProcessTools.startProcess to avoid stderr getting stuck Changes: https://git.openjdk.org/jdk/pull/17324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322324 Stats: 15 lines in 1 file changed: 3 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/17324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17324/head:pull/17324 PR: https://git.openjdk.org/jdk/pull/17324
