RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

Per Liden per.liden at oracle.com
Thu Apr 7 11:55:22 UTC 2016


On 2016-04-07 13:24, Dmitry Fazunenko wrote:
> Hi Per,
>
> The fix looks good, but a couple of suggestions regarding:

Thanks Dima!

> GcCapacityTest.java.frames.html
>
> 1)  -Xmx128  --> -Xmx128m

Ah, thanks for catching that!

>
> 2) Remove @ignore 8149778
> Adding -Xmx should fix 8149778 as well.

I looked at 8149778, but I couldn't convince myself that those timeouts 
are caused by the same issue. At a glance it looked more like an other 
bug in the tests. I got the feeling that with -Xcomp C2 optimizes 
provokeGC() in a way which causes it to not retain the list of objects 
it's creating. IIRC, the output from the jstat OU counter seems to 
indicate that the live set was very small, so you'll never reach 70% 
heap usage and just loop forever. My analysis here could be wrong, but 
I'd like to keep that tag in this commit, and let Alexander (who is 
assigned to 8149778) figure out what the fix should be. Ok?

cheers,
Per

>
> Thanks,
> Dima
>
>
>
> On 06.04.2016 12:32, Per Liden wrote:
>> Summary: This patch updates the tests in serviceability/tmtools/jstat/
>> to use a fixed (and relatively small) heap size. Without this these
>> tests tend to run out of memory on machines with VM overcommit
>> disabled. This has happened in nightly testing.
>>
>> The patch also moves a misplaced @ignore tag and cleans out an unused
>> method.
>>
>> Testing: Without this patch I can easily get these tests to OOM on my
>> local workstation by just disabling VM overcommit. They pass with this
>> patch applied.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152989
>> Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/
>>
>> cheers,
>> Per
>>
>


More information about the hotspot-gc-dev mailing list