On Tue, 3 Nov 2020 17:02:33 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> > The test fails if OutOfMemoryError is thrown, right? > > Is the reduced execution time enough to catch the original bug? > > It depends on the system, if it is really slow and just a few iterations out > of 5000 will be done then the original bug will not be caught. If the system > is fast and all 5000 iterations will be done, then the bug will be found. I agree with the idea of minimising the time spent to run the test. But the test is useless if it has no time to fail. I just ran the test on my laptop with 10+22 where the original bug [JDK-8175015](https://bugs.openjdk.java.net/browse/JDK-8175015) isn't fixed. It fails as one would expect. It took about 12 minutes with `-Xmx8m` (less than 8500 iterations). After reducing the heap size to 4m, the test failed in 3 minutes (less than 2500 iterations). But the modified test times out after 1.5 minutes and the test does not fail. Thus 90 seconds limit seems too short. Shall we increase the timeout to 5 minutes at least and reduce the heap size to make the test fail faster. The number of iterations can be reduced as well, say to 10,000. The test runs quickly on a recent build, it takes less than 10 seconds to perform 50,000 iterations. To be precise, it took 5.5 seconds with `-Xmx8m` and a little longer around 6 seconds with `-Xmx4m`. Obviously the run time depends on the hardware and can fluctuate significantly. On the other hand, it does no good if the test always exits by timeout without catching the original bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/923
