<AWT Dev> RFR: 8241806: The sun/awt/shell/FileSystemViewMemoryLeak.java is unstable

Alexey Ivanov aivanov at openjdk.java.net
Thu Nov 5 12:37:55 UTC 2020

On Tue, 3 Nov 2020 17:02:33 GMT, Sergey Bylokhov <serb at 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

More information about the awt-dev mailing list