JDK-8144836 : [TESTBUG] FJExceptionTableLeak and RemoveLeak fail with -XX:+UseParallelGC -XX:+AggressiveOpts
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-12-07
  • Updated: 2016-08-22
  • Resolved: 2016-08-15
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 9
9 b132Fixed
Related Reports
Duplicate :  
Relates :  
Description
When turned on UseParallelGC options both tests fail with such messages
----------messages:(3/135)----------
command: main -Xmx2200k RemoveLeak
reason: User specified action: run main/othervm -Xmx2200k RemoveLeak 
elapsed time (seconds): 0.155
----------System.out:(2/137)----------
Error occurred during initialization of VM
GC triggered before VM initialization completed. Try increasing NewSize, current value 1536K.


Comments
java/util/concurrent/forkjoin/FJExceptionTableLeak.java" Exception java.lang.OutOfMemoryError: Java heap space https://bugs.openjdk.java.net/browse/JDK-8144990
10-12-2015

The test could be modified to be skipped when this option is set: * @requires (vm.opt.AggressiveOpts == null) | (vm.opt.AggressiveOpts == false) but I think that is a bad precedent and the whole testing with AggressiveOpts needs to be re-thought.
08-12-2015

See also JDK-8020445 (though I see nothing that indicates this experimental flag is deprecated!) and JDK-8020446. I don't see why we should be testing with -XX:+AggressiveOpts and expect all tests to pass. The actual affect of using AggressiveOpts seems to be the size of the AutoBoxCache.
08-12-2015

Test folks: preventing test failures is not a goal in itself. Using -Xmx2200k is of course pushing the limits, but tests are supposed to do that! Either fix -XX:+AggressiveOpts to not fail with a small heap size or point me to an authoritative source that -Xmx2200k is unreasonably small.
08-12-2015

Yes, the problem is not in the test code, of course. The problem is in extremely small heap size. Is it really necessary to limit the heap by 2200K? Can we use 4097K instead (or any greater number)?
08-12-2015

/java/re/jdk/9/latest/binaries/linux-x64/bin/java -Xmx3000K -XX:+UseParallelGC -XX:+UnlockExperimentalVMOptions -XX:+AggressiveOpts -version Error occurred during initialization of VM GC triggered before VM initialization completed. Try increasing NewSize, current value 1536K. AggressiveOpts seems to break things.
08-12-2015

Further this failure indicates a problem during VM initialization so the actual test is somewhat irrelevant - it is only the VM startup options that affect this.
08-12-2015

I tried this on my Linux x64 machine. The test still passes with -XX:+UseParallelGC It's only when you add -XX:+UnlockExperimentalVMOptions -XX:+UseParallelGC -XX:+AggressiveOpts that it starts failing. I believe supporting -XX:+AggressiveOpts is a non-goal for jtreg tests. It's an extreme flag that is useful for experiments and benchmarks, but is expected to break some programs. So I'm inclined to not fix this, unless you can point to a policy about which GC flags should be supported. -XX:+DisableExplicitGC is another flag known to cause some tests to fail (and that's OK!)
07-12-2015

on Linux 64 with options: "-server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:+UseParallelGC" both tests passed with "@run main/othervm -Xmx4097k" and failed with less value, 4096k and less
07-12-2015

I can reproduce this bug on my computer (x86_64 GNU/Linux) with this command rm -rf JT* ; JT_JAVA=/home/tpivovar/workspace/java_stable/jdk1.8.0_51 /home/tpivovar/workspace/jtreg/bin/jtreg -verbose:summary -testjdk:/home/tpivovar/workspace/jdk9/build/linux-x86_64-normal-server-release/images/jdk-server -vmoptions:"-server -Xmixed -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:+UseParallelGC" -dir:/home/tpivovar/workspace/jdk9/jdk/test java/util/concurrent/forkjoin/FJExceptionTableLeak.java These test fails on Linux, Solaris, Solaris-sparc, Windows with bitness 64
07-12-2015

Also, please try increasing the Xmx value in the test and report at what value it starts passing.
07-12-2015

Please provide a jtreg command line that can trigger this, plus the platform where this was observed.
07-12-2015

I think it relates to changes in http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2103ed2d51f5 @@ -36,17 +36,17 @@ * @author Doug Lea * @bug 8004138 * @summary Check if ForkJoinPool table leaks thrown exceptions. - * @run main/othervm/timeout=1200 -Xmx32m FJExceptionTableLeak + * @run main/othervm -Xmx2200k FJExceptionTableLeak */ Tests set too little memory
07-12-2015