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: [email protected] To: [email protected] Cc: [email protected] 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: [email protected] > To: [email protected], [email protected] > Cc: [email protected] > 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: [email protected] >> To: [email protected] >> Cc: [email protected], [email protected], >> [email protected] >> 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: [email protected] >> To: [email protected], [email protected], >> [email protected] >> 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 >>>
