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

Fri Apr 4 12:12:51 UTC 2014

Hi,
I have updated the patch with the following changes:
Util.java line 130 - Moved Pattern from function to "private static final" 
RunUtil.java line 64 - Use diamond operator.

webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04

I have created an enhancement for porting the other
shell scripts to java (https://bugs.openjdk.java.net/browse/JDK-8039257)

Mattias

----- Original Message -----
From: mandy.chung at oracle.com
To: mattias.tobiasson at oracle.com
Cc: serviceability-dev at openjdk.java.net
Sent: Wednesday, April 2, 2014 12:22:43 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 Mattias,

On 4/1/14 3:11 AM, Mattias Tobiasson wrote:
> Hi Mandy,
> I have moved the common code to a new utility class.

Thanks for the refactoring.  Looks much better.

Nit: RunUtil.java line 64 - you can use diamond operator.    No need to 
generate a new webrev.

>
> The shell script tests work as they are, they do not fail.
> The reason for this is that they only use the default options specified in ${TESTVMOPTS}, not in ${TESTJAVAOPTS}.
> Any default GC options will be in ${TESTJAVAOPTS}, so they are ignored by the shell script tests.

> We may want to move the shell scripts to java later, but I think we should wait until we get the "@requires" tag in jtreg.

Can you file a bug to replace the shell script tests with the new 
RunUtil class?   @requires could be done independent with the shell 
script test conversion.

thanks
Mandy

> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.03
> bug: https://bugs.openjdk.java.net/browse/JDK-8030628
>
> Mattias
>
> ----- Original Message -----
> From: mandy.chung at oracle.com
> To: mattias.tobiasson at oracle.com, serviceability-dev at openjdk.java.net
> Cc: leonid.mesnik at oracle.com
> Sent: Wednesday, March 19, 2014 6:45:27 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,
>
> On 3/14/2014 6:21 AM, Mattias Tobiasson wrote:
>> 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
> Thanks for updating other failing tests.  I think we are not sure when
> the proper configuration support is in place and this temporary solution
> to allow the tests to run is reasonable.
>
> It'd be better to refactor the common code to launch the test with all
> GC configurations shared by jdk/test/java/lang/management/MemoryMXBean
> tests.
>
> There are other shell tests that can be removed if the corresponding
> java tests are modified to use your utility class.   It's probably out
> of the scope of this fix.  Do you have cycles to clean them up as well?
> They probably fail in VM nightlies like the ones you fixed if it
> overrides with a different GC.
>
> LowMemoryTest2.sh
> MemoryManagementParallelGC.sh
> MemoryManagementConcMarkSweepGC.sh
> MemoryManagementSerialGC.sh
> PendingAllGC.sh
>
> Mandy
>
>> 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
>>>