RFR: 8040250: The test test/gc/parallelScavenge/TestDynShrinkHeap.java fails with OOME

Dmitry Fazunenko dmitry.fazunenko at oracle.com
Mon May 26 13:17:51 UTC 2014


Hi Jon,

Thanks for the review!

Actually, gc/parallelScavenge/TestDynShrinkHeap.java experiences the 
same issue as gc/g1/TestHumongousShrinkHeap.java does, if run with 
different GC. 8042051 matches both failures...

The problem exists only in Main-baseline, when all HS tests are executed 
with multiple GCs.
In GC nighlties the HS tests are executed without extra flags.
I hope that adding support of @requires will allow to solve the issue.  
I also submitted INTJDK-7611364 
<https://bugs.openjdk.java.net/browse/INTJDK-7611364> to fix this 
problem locally for our nightly testing.

Thanks,
Dima


On 23.05.2014 1:31, Jon Masamitsu wrote:
> Dima,
>
> Change looks good.
>
> I noticed that the @run has UseParallelGC on it.
>
> @run main/othervm -XX:+UseAdaptiveSizePolicyWithSystemGC 
> -XX:+UseParallelGC -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=100 
> -Xmx1g -verbose:gc TestDynShrinkHeap
>
>
> Why doesn't this test run into the problem of multiple GC's specified
> on the command line when run with other GC's?  For example,
> I would expect this test to be running with all the GC's when
> nightly testing is done.
>
> I'm asking because that seems to be the problem with
>
> 8042051 - gc/g1/TestHumongousShrinkHeap.java: Conflicting collector 
> combinations in option list ?
>
> Thanks.
>
> Jon
>
>
> On 05/22/2014 08:58 AM, Dmitry Fazunenko wrote:
>> Hello,
>>
>> Would you review a very simple test fix, please.
>>
>> Description:
>> Test allocated ~1G memory and failed with OOM before any checks.
>> The fixed version specifies -Xmx1G and allocates 0.5G.
>> The test checks that memory could be decommited, so for the test it's 
>> doesn't meter how much memory to allocate initially.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8040250
>> Webrev: 
>> http://cr.openjdk.java.net/~iignatyev/dfazunenko/8040250/webrev.00/
>>
>>
>> Testing:
>> This is the very simple fix. I tested it locally running jtreg. The 
>> test failed before fix and passes after.
>>
>> Any your comments are very welcome.
>>
>> Thanks,
>> Dima
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20140526/5c4f4b66/attachment.htm>


More information about the hotspot-gc-dev mailing list