<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Jon,<br>
<br>
Thanks for the review!<br>
<br>
Actually, gc/parallelScavenge/TestDynShrinkHeap.java experiences the
same issue as gc/g1/TestHumongousShrinkHeap.java does, if run with
different GC. 8042051 matches both failures... <br>
<br>
The problem exists only in Main-baseline, when all HS tests are
executed with multiple GCs. <br>
In GC nighlties the HS tests are executed without extra flags.<br>
I hope that adding support of @requires will allow to solve the
issue. I also submitted <a id="key-val" rel="4727378"
href="https://bugs.openjdk.java.net/browse/INTJDK-7611364">INTJDK-7611364</a>
to fix this problem locally for our nightly testing.<br>
<br>
Thanks,<br>
Dima<br>
<br>
<br>
<div class="moz-cite-prefix">On 23.05.2014 1:31, Jon Masamitsu
wrote:<br>
</div>
<blockquote cite="mid:537E6CB7.6040305@oracle.com" type="cite">Dima,
<br>
<br>
Change looks good.
<br>
<br>
I noticed that the @run has UseParallelGC on it.
<br>
<br>
@run main/othervm -XX:+UseAdaptiveSizePolicyWithSystemGC
-XX:+UseParallelGC -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=100
-Xmx1g -verbose:gc TestDynShrinkHeap
<br>
<br>
<br>
Why doesn't this test run into the problem of multiple GC's
specified
<br>
on the command line when run with other GC's? For example,
<br>
I would expect this test to be running with all the GC's when
<br>
nightly testing is done.
<br>
<br>
I'm asking because that seems to be the problem with
<br>
<br>
8042051 - gc/g1/TestHumongousShrinkHeap.java: Conflicting
collector combinations in option list ?
<br>
<br>
Thanks.
<br>
<br>
Jon
<br>
<br>
<br>
On 05/22/2014 08:58 AM, Dmitry Fazunenko wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
Would you review a very simple test fix, please.
<br>
<br>
Description:
<br>
Test allocated ~1G memory and failed with OOM before any checks.
<br>
The fixed version specifies -Xmx1G and allocates 0.5G.
<br>
The test checks that memory could be decommited, so for the test
it's doesn't meter how much memory to allocate initially.
<br>
<br>
Bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8040250">https://bugs.openjdk.java.net/browse/JDK-8040250</a>
<br>
Webrev:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~iignatyev/dfazunenko/8040250/webrev.00/">http://cr.openjdk.java.net/~iignatyev/dfazunenko/8040250/webrev.00/</a>
<br>
<br>
<br>
Testing:
<br>
This is the very simple fix. I tested it locally running jtreg.
The test failed before fix and passes after.
<br>
<br>
Any your comments are very welcome.
<br>
<br>
Thanks,
<br>
Dima
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>