-
Bug
-
Resolution: Fixed
-
P2
-
None
-
b09
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8231420 | 11.0.6-oracle | Ioi Lam | P2 | Resolved | Fixed | b01 |
JDK-8213520 | 11.0.3 | Ioi Lam | P2 | Resolved | Fixed | master |
In our continuous testing environment, runtime/CommandLine/OptionsValidation/TestOptionsWithRanges takes a very long time to execute, often taking up to an hour of wall clock time.
The test executes about 1625 child JVM processes in fastdebug builds. Each process tries to trigger GC:
createWeakRef();
do {
garbage = new byte[8192];
i++;
/* Initiate GC after 5 iterations */
if (i > 5) {
System.gc();
}
} while(weakRef.get() != null);
The main problem is the execution time of each child process is highly dependent on the heap size, which by default scales according to the physical RAM size of the test host.
On my machine with 64GB ram, the test runs extremely slowly and times out after an hour.
The fix is to specify a small heap size when spawning the child JVM processes. With -Xmx1024m, the total run time of fastproduct is reduced to about 7 minutes on my machine.
Also, -XX:-ZapUnusedHeapArea should be specified for fastdebug VMs. Otherwise some GCs such as CMS will spend lots of time filling the heap with junk (which might be useful for some GC tests, but it's really unnecessary for this test).
The test executes about 1625 child JVM processes in fastdebug builds. Each process tries to trigger GC:
createWeakRef();
do {
garbage = new byte[8192];
i++;
/* Initiate GC after 5 iterations */
if (i > 5) {
System.gc();
}
} while(weakRef.get() != null);
The main problem is the execution time of each child process is highly dependent on the heap size, which by default scales according to the physical RAM size of the test host.
On my machine with 64GB ram, the test runs extremely slowly and times out after an hour.
The fix is to specify a small heap size when spawning the child JVM processes. With -Xmx1024m, the total run time of fastproduct is reduced to about 7 minutes on my machine.
Also, -XX:-ZapUnusedHeapArea should be specified for fastdebug VMs. Otherwise some GCs such as CMS will spend lots of time filling the heap with junk (which might be useful for some GC tests, but it's really unnecessary for this test).
- backported by
-
JDK-8213520 [TESTBUG] TestOptionsWithRanges is very slow
-
- Resolved
-
-
JDK-8231420 [TESTBUG] TestOptionsWithRanges is very slow
-
- Resolved
-
- is blocked by
-
JDK-8210043 Invalid assert(HeapBaseMinAddress > 0) in ReservedHeapSpace::initialize_compressed_heap
-
- Resolved
-
- relates to
-
JDK-8217170 gc/arguments/TestUseCompressedOopsErgo.java timed out
-
- Resolved
-