JDK-8227414 : gc/arguments test subprocesses sometimes take a long time to complete
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2019-07-08
  • Updated: 2022-01-03
  • Resolved: 2022-01-03
Related Reports
Relates :  
Relates :  
Description
As discussed in JDK-8217170, sometimes the subprocesses used by the various tests in gc/arguments take a long time to complete.  (There might be other tests with similar behavior.)

In these cases, the main test process launches a series of subprocesses, many of the form 'java <options-being-tested> -version'.  Usually each of those subprocesses completes within 10's to small 100's of milliseconds.  But occasionally a test will consistently see times in the 3-5 second range (or sometimes 20+ seconds with CMS).  These slow times are mostly associated with Windows, and more often with certain machines (though not limited to those machines, just worse on them).

The main test reports that the waitFor() for a child to exit takes a long time. It is not yet known what the child process is doing that would take it so long. That needs to be investigated and fixed if it is a product issue, and not just an artifact of testing or debug builds.

Comments
RT Triage: We do not see recent test failures. If we do, we could reopen this issue.
03-01-2022

Passing this over to runtime. While the test is a GC test, the underlying problem doesn't seem to be GC-related (other than CMS being far worse for some reason, but we're removing CMS so don't care about that).
09-11-2019

[~mgronlun] wrote a hackish patch to investigate this: see windows_process_abort.patch. He did some initial experiments with TestUseCompressedOopsErgo: ... -Dtest.processtools.timeout=2500 \ -Dtest.processtools.timeoutUnit=ms \ -Dtest.processtools.abortOnTimeout=true \ -XX:+ShowMessageBoxOnError \ com.sun.javatest.regtest.agent.MainWrapper 'D:\utilities\jtreg\runtime_artifacts\work\gc\arguments\TestUseCompressedOopsErgo_id3.d\main.1.jta' -XX:+UseConcMarkSweepGC TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Child process aborted after timeout : 2500 MILLISECONDS He saw three state categories (in a small number of test runs): 1. DestroyVM is waiting for the VMThread to exit, but the VMThread is busy getting threads to a safepoint 2. JIT compilations running 3. DestroyVM is destroying PerfMemory (counters?)
05-11-2019