[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: RFR 8030628: MemoryMXBean/CollectionUsageThreshold.java is not applicable for VM SQE testing
From: Mandy Chung <mandy.chung () oracle ! com>
Date: 2014-04-16 20:10:00
Message-ID: 534EE398.3000903 () oracle ! com
[Download RAW message or body]
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@oracle.com
> To: serviceability-dev@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@oracle.com
> To: mattias.tobiasson@oracle.com
> Cc: serviceability-dev@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@oracle.com
> > To: mattias.tobiasson@oracle.com, serviceability-dev@openjdk.java.net
> > Cc: leonid.mesnik@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@oracle.com
> > > To: mandy.chung@oracle.com
> > > Cc: serviceability-dev@openjdk.java.net, leonid.mesnik@oracle.com, \
> > > jonathan.gibbons@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@oracle.com
> > > To: mattias.tobiasson@oracle.com, serviceability-dev@openjdk.java.net, \
> > > jonathan.gibbons@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
> > > >
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic