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
