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

Wed Apr 16 20:10:00 UTC 2014

Hi Mattias,

Sorry for the delay.   I just pushed the changeset.

Mandy

On 4/16/2014 6:17 AM, Mattias Tobiasson wrote:
> Hi Mandy,
> Could you please sponsor this attached patch.
> It has been updated with all review comments.
> jcheck is ok, except for missing reviewer.
>
> webrev: http://cr.openjdk.java.net/~ykantser/8030628/webrev.04
> bug: https://bugs.openjdk.java.net/browse/JDK-8030628
> repositry: http://hg.openjdk.java.net/jdk9/dev/jdk
>
> Mattias
>
> ----- Original Message -----
> From: mattias.tobiasson at oracle.com
> To: serviceability-dev at openjdk.java.net
> Sent: Friday, April 4, 2014 2:12:51 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,
> 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
>>>>