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

[Philip Race]

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
>>
>
>