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 
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?


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: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20140807/a7274442/attachment.html>

More information about the hotspot-gc-dev mailing list