It is very strange if there is no disposer thread.
It should be created by the first thing that requests the service in a
static initializer
block for the class and then live forever.
Could it be that OOME was thrown on that thread ? It looks like it would
cause the
thread to exit.
I don't expect we do much allocation there - it is all about the opposite.
Still, the Disposer.run() method only catches Exception and OOME is a
subclass of Error, not Exception.
We should probably change the run() method to catch Throwable.
-phil.
On 10/31/18, 11:44 AM, Sergey Bylokhov wrote:
Hi, Krishna.
The current timeout for this test is 1000 seconds, which is 16 minutes.
I guess such timeout should be enough for everything which is done in
this test.
BTW there is no Disposer thread in the stack, it is also strange that
most of the threads in the stack thread are blocked.
See some comments inline.
On 31/10/2018 07:58, Krishna Addepalli wrote:
Hi All,
Please review a fix for JDK-8198003:
https://bugs.openjdk.java.net/browse/JDK-8198003
Webrev: http://cr.openjdk.java.net/~kaddepalli/8198003/webrev00
This test tries to create a huge(20000) files and show them in
JFileChooser, which inturn creates 20000 instances of File class.
This internally has a reference to native file handle through COM
object (IShellFolder), which is added to java2d.Disposer, to be
disposed after use. The test then tries to fill the memory and
thereby tries to check if the File records are deleted by GC. It
repeats this test about 20 times for each of the installed L&Fs. So
the problem essentially boils down to how fast the Disposer thread
can clean up the objects, which may not always obey the time limit
constraints.
The test uses java2d.Disposer as a way to delay next iteration and to
not overload the system, the test assumes that if its own
disposerRecord is executed then it is likely all previous objects are
collected. Instead of this mechanics we can use simple sleep(), but I
think that the root cause is an absent of Disposer thread, which means
that our disposerRecord will not be executed, and our test will hang
forever.
It is also strange that the "Swing-Shell" thread which should dispose
the native IShellFolder is also blocked and do nothing.
On Mac, the test always throws OOME – while running for Aqua L&F. Now
the difference between the other L&Fs and Aqua is that, it in Aqua
L&F, each File instance is wrapped inside SortableFile class, which
are then presented in the JFileChooser, to provide quick sorting of
the files. So, this makes it a tad bit slower in Mac to release the
File objects.
The solution is three fold:
1.After each run, make sure System.gc() is called to make sure that
some memory is available for subsequent run. Also, a Global Exception
Handler is registered which does another round of GC calls to make
sure that the memory is not run out of.
2.Reduce the number of times the test runs (down from 20 to 10),
since running additional number of times only increases the test case
runtime without any additional information.
3.Create and Delete files parallelly – although this doesn’t have a
big impact, it does help to provide more time for the actual test to
run.
Even with these changes, the test fails sometimes on Mac while
running Aqua L&F, so this L&F can be skipped.
Thanks,
Krishna
