JDK-8144578 : TestOptionsWithRanges test only ever uses the default collector
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-12-03
  • Updated: 2016-03-10
  • Resolved: 2016-02-17
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 b109Fixed
Related Reports
Relates :  
JDK-8144573 - TLABWasteIncrement=max_jint fires an assert on SPARC for non-G1 GC mode
Relates :  
JDK-8145204 - JVM can hang when ParGCArrayScanChunk=4294967296 and ParallelGC is used
Relates :  
JDK-8145192 - 'count' variable can overflow in PSMarkSweep::invoke on 64 bit JVM
Relates :  
JDK-8145190 - MinTLABSize can cause overflow problem with CMS GC
Description
The test in runtime/CommandLine/OptionsValidation/TestOptionsWithRanges checks ranges of command line options. It ever only does so with the default collector, ignoring any collectors set on the command line.

This is problematic, because this means that functionality that is only implemented for collectors other than the default collector is never even tested. Bugs like JDK-8144573 that are only found by accident with the current scheme, and show that this leads to a highly reduced test coverage.
Comments
I think that test can determine GC type and use it for testing. Currently I see two methods how this can be done: 1) Parsing ManagementFactory.getGarbageCollectorMXBeans() 2) Filtering "Use*GC" options from passed options by jdk.test.lib.getFilteredTestJavaOpts and use these options to specify GC. 2 method is more flexible from my point of view, but it still relied on passed options.
08-12-2015
If the options themselves have ranges that are affected by GC ergonomics then the test needs to be run with all the different GCs we want to test. The normal way to do this would be to not use "driver" mode and simply pass through the options set by the framework as part of the test run. Otherwise use driver mode and launch tests with all the desired GC options and configurations. But the latter is more complex and doesn't reflect what combinations we have chosen to test.
08-12-2015
These are command line tests, they should not pass on external options. If the flags needs to be run with different GC's, this should be done by the framework itself.
07-12-2015
There 2 reasons why test not pass supplied options: Test not uses supplied options because test runs really long in "-Xcomp" mode and there are was a blocker for that which now resolved(IgnoreUnrecognizedVMOptions hides out-of-range values). But it really good to have all GC covered. I think that test can get supplied options, but always run in "-Xmixed" mode. I will work on that.
04-12-2015
The test is actually run in nightlies with different collectors (passing e.g. -XX:+UseParallelGC to it). However it simply ignores that, running the actual tests with the default collector again. This is a waste of time, and as mentioned it seems very important to have basic flag bounds checking for all collectors.
04-12-2015