RFR (XXS): 8054362: gc/g1/TestEagerReclaimHumongousRegions2.java timeout

[Bengt Rutisson]

Hi Thomas and Dima,

On 2014-08-07 18:35, Dmitry Fazunenko wrote:
> Hi Thomas,
>
> The fix you made is certainly safe but it makes the test weaker.
>
> As I see from your explanation the timeout happens only on very slow 
> machines.
> What if test tries to detect if the machine is slow or not and set the 
> iteration number accordingly.
> I mean something like:
>
> int iterations = 20;
> if (|Runtime.getRuntime().availableProcessors()|  < 2 ||
>           |Runtime.getRuntime().||maxMemory() < 1G)|  {
>    // perhaps the machine is slow, reducing iterations to avoid timeout
>    iterations = 2;
> }
> |
> Another suggestion (not related to that bug). What if update the test to check with various region sizes?
> Not only with 1M?|

Could we make the test check the time? Maybe do the loop for 1 minute 
but no more than 20 iterations?

Bengt

> |
>
> Thanks,
> Dima
> |
>
> On 07.08.2014 19:43, Thomas Schatzl wrote:
>> Hi all,
>>
>>    can I have reviews for this following tiny change? The test mentioned
>> in the subject times out on very slow machines (Atom N-270) on aurora.
>>
>> This is fixed by decreasing the number of internal runs of the test.
>>
>> The given value (2) has been determined to take ~1min on that machine,
>> while preserving the crash reproducability without the fix on large
>> machines. Going lower makes the test not fail sometimes.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8054362
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8054362/webrev/
>> Testing:
>> test case, jprt
>>
>> Thanks,
>> Thomas
>>
>

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