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

[Erik Helin]

Hi Thomas,

On Monday 11 August 2014 11:12:04 AM Thomas Schatzl wrote:
> 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/

looks good!

Thanks,
Erik

> Testing:
> jprt, local jtreg
> 
> Thanks,
> Thomas