RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing

[Mattias Tobiasson]

Hi,
I have updated the patch to include all failing tests for this bug.

The tests currently fail because their GC options collide with GC options from the test framework.
The fix will launch the tests in a separate JVM with controlled GC options.

webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.02
bug: https://bugs.openjdk.java.net/browse/JDK-8030628

Mattias

 
----- Original Message -----
From: mattias.tobiasson at oracle.com
To: mandy.chung at oracle.com
Cc: serviceability-dev at openjdk.java.net, leonid.mesnik at oracle.com, jonathan.gibbons at oracle.com
Sent: Wednesday, March 12, 2014 10:19:08 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing

Hi Mandy,
I have talked to Leonid Mesnik, and he says there are plans for a jtreg flag that would solve this problem in a general way (maybe @requires). I do not know the time plan for that jtreg feature. The test currently fails in nightlies, so we need a temporary fix.

I don't know when/if all different GC configurations are used in nightly tests. But for these tests that depend on the GC, I think it's good to always run with different GC configurations. The test is fast so all 4 runs take about a second.

I did not notice that there are more tests in the same dir. I will change them too.

Mattias

----- Original Message -----
From: mandy.chung at oracle.com
To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net, jonathan.gibbons at oracle.com
Sent: Tuesday, March 11, 2014 8:48:04 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing

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
>