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

Dmitry Fazunenko dmitry.fazunenko at oracle.com
Thu Aug 7 16:35:30 UTC 2014


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?

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/20140807/a7274442/attachment.htm>


More information about the hotspot-gc-dev mailing list