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