Hi Sergey, I have noticed the presence of the Disposer thread in the local test that I have run on both Mac and Windows. May be there could have been a mistake in pasting the log in the bug. As you pointed out most threads are blocked, except the "AWT-Windows" and "AWT-EventQueue-0" threads, which are not. So I guess there is some time being spent in cleaning up the window resources as well.
So, coming to the test, while I agree that the timeout should be adequate for the stuff being done in the thread, this test mimics the scenario of user continuously opening folder containing a large number of files in quick succession, and sees if it leads to OOME. But, I feel it does a bit too quickly (comparing to the human speed), and that is leading it to take a little longer - since there is no control once the code is executing the COM object deletion. Thanks, Krishna -----Original Message----- From: Philip Race Sent: Saturday, November 3, 2018 11:28 PM To: Sergey Bylokhov <sergey.bylok...@oracle.com> Cc: Krishna Addepalli <krishna.addepa...@oracle.com>; swing-dev@openjdk.java.net Subject: Re: <Swing Dev> [12]RFR: JDK-8198003: javax/swing/JFileChooser/6396844/TwentyThousandTest.java throws error 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 >> > >
