<Swing Dev> [12]RFR: JDK-8198003: javax/swing/JFileChooser/6396844/TwentyThousandTest.java throws error

[Krishna Addepalli]

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.bylokhov at oracle.com>
Cc: Krishna Addepalli <krishna.addepalli at oracle.com>; swing-dev at 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
>>
>
>