Mandy, Mattias
See my comments inline. Please note that I am not Reviewer and not SVC
team member.
On 03/11/2014 11:49 PM, Mandy Chung wrote:
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.
I proposed such approach. The @requires tag is good when we have test
which require some specific functionality. For example if we have G1
specific test then @require G1GC should work well.
However I suppose that if we want to have more advanced logic we need to
use @driver and execute new VMs in driver code. This fix could be later
easily adopted to such approach.
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.
If JMX team is ok with using only flags given externall by jtreg then I
think it would be better just to remove all GCs from @run's. All
supported GC combinations are covered in VM SQE Nightly/PIT/Promotion
testing.
Mattias
What do you think about removal all @run tags with specific GC's?
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).
I don't know when @require/@driver tags are doing to be implemented.
Probably we might want to wait them in jtreg. After this we should fix
all HS/JDK regression tests to get rid of "incompatible flags" issue.
Leonid
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
--
Leonid Mesnik
JVM SQE
