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

[Thomas Schatzl]

Hi Bengt, Dima,

On Fri, 2014-08-08 at 14:35 +0200, Bengt Rutisson wrote:
> 
> 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?

There does not seem to be new information gain when running the test
with different region sizes as the problem is independent of it. Also,
the test has been set up to be highly reproducible using a 1M region
size and the given heap and object sizes.

It would take considerable effort to modify it for multiple region sizes
for no noticable gain.
> 
> Could we make the test check the time? Maybe do the loop for 1 minute
> but no more than 20 iterations?

I implemented this idea as it seems less failure prone than trying to
guess the speed of the machine. Fast machine easily finish the test
within the given time, slower ones should get enough coverage.

CR:
https://bugs.openjdk.java.net/browse/JDK-8054362

Webrev:
http://cr.openjdk.java.net/~tschatzl/8054362/webrev.1/

Testing:
jprt, local jtreg

Thanks,
Thomas