RFR: 8160827: gc/stress/TestStressG1Humongous.java fails with OOME

[Michail Chernov]

Hi Thomas,

Thanks a lot for reviewing this.

I updated the change, could you take another look at this, please. Test 
was excluded on 32-bit systems couple of day ago. I removed this 
@requires. Also added simple checking in getExpectedAmountOfObjects().

http://cr.openjdk.java.net/~mchernov/8160827/webrev.01/

Checked locally with 32-bit JVM - test passed.

Thanks,
Michail

On 19.07.2016 14:45, Thomas Schatzl wrote:
> Hi Michail,
>
> On Thu, 2016-07-14 at 20:41 +0300, Michail Chernov wrote:
>> Hi,
>>
>> Could I have a review for this change, please?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8160827
>> http://cr.openjdk.java.net/~mchernov/8160827/webrev.00/
>>
>> Test gc/stress/TestStressG1Humongous.java fails on some hosts due to
>> OOME. OOME is happened at
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
>> .addConditionWaiter. At my point of view, this is not related to
>> humongous allocation and GC work. This change gives more free space
>> for VM.
>>
>> Tested on different configuration and different hosts - test passed.
>    looks okay to me.
>
> Maybe also make sure that the value returned
> by getExpectedAmountOfObjects() is not negative? Very unlikely, but
> somebody may ask. Then again, I am not sure what the result of the
> remaining program would be in case this test were run with a very small
> heap.
>
> Maybe with some @run flag make sure that we can't get a too small heap
> (or check this in the test), not sure what the best way is.
>
> However, this seems to be kind of out of scope for this CR.
>
> Thanks,
>    Thomas