Hi Mattias,
Have you discussed with Jon Gibbons about the jtreg @requires support?
I thought it was partly motivated by the requirement to specify a test
to run in different collector.
The reason why these regression tests explicitly specifies different GC
flags was to increase the coverage and ensure to catch regression early
during development cycle. At that time, the VM nightly testing rotates
the test execution with different GC configuration that delayed to catch
a regression that occurs in one collector while the nightly testing is
testing another collector. For integration, I don't recall if different
collectors are tested rather than default. It may be time to revisit
the test execution with different collectors. If the verification of
different collectors is well covered in nightly, perhaps these tests no
longer need one @run per each collector.
There are other regression tests that specifies the -XX:+UseXXGC flag in
the @run tag. It makes sense to modify them in the same patch (perhaps
at least tests under test/java/lang/management).
Mandy
On 3/11/14 6:15 AM, Mattias Tobiasson wrote:
Hi,
Could you please review this test fix.
The test fails because it specifies its own GC command line options, for
example:
@run main/othervm/timeout=300 -XX:+PrintGCDetails -XX:+UseSerialGC
CollectionUsageThreshold
When the framework also specifies GC version, then the test will fail with this
log:
"Conflicting collector combinations in option list; Error: Could not create the Java
Virtual Machine."
The solution is to run the test in a separate JVM with controlled GC options.
The test will be run multiple times.
First with the command line specified from the framework, without test specific
GC options.
Then once for each GC version specified in the test. When the test specifies
the GC, any GC options from the framework are removed.
webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.01
bug: https://bugs.openjdk.java.net/browse/JDK-8030628
Mattias
