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