RFR: 8183910: gc/arguments/TestAggressiveHeap.java fails intermittently
Stefan Johansson
stefan.johansson at oracle.com
Tue May 15 14:39:30 UTC 2018
Thanks for the review Kim,
On 2018-05-15 15:51, Kim Barrett wrote:
>> On May 15, 2018, at 5:12 AM, Stefan Johansson <stefan.johansson at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review this test change to avoid memory exhaustion during testing.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8183910
>> Webrev: http://cr.openjdk.java.net/~sjohanss/8183910/00
>>
>> Summary
>> The option AggressiveHeap sets the heap to half of the physical memory, turns on ParallelGC and set a bunch of other options. The test TestAggressiveHeap only verifies that Parallel GC was set. With this in mind I don't see a good reason for letting this test set the heap size so big and cause a lot of problems in our testing environment. The suggested fix limits the heap to 128M which is half of what the option requires the machine to have. This can of course still cause failures on systems with little memory, but the problem is not bigger than today since the system must have more than 256M for the test to run.
>>
>> Testing
>> Turned off swap on my machine and ran the tests in hotspot/gc/arguments with concurrency 10. This always cause a few failures, either in TestAggressiveHeap it self of in some other test running concurrently that cannot allocate its heap. With the fix, I've run several runs without any problems.
>>
>> Since this is an intermittent issue in our testing environment I haven't tried to verify it there but limiting the memory use should really fix the problems we see there the same way as it fixed my local problems.
>>
>> Thanks,
>> Stefan
>
> Looks good.
>
> I like this approach much better than making it a “stress” test that we try to trick into being run in isolation.
>
Me too, glad you liked it too :)
Cheers,
Stefan
More information about the hotspot-gc-dev
mailing list