<Swing Dev> Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window

[Rajeev Chamyal]

Hello Sergey,

Please review the updated test case.
Webrev : http://cr.openjdk.java.net/~rchamyal/8030099/webrev.01/

As this issue is reported for Parallel GC collector. So, I have added -XX:+UseParallelGC to child process VM arguments in test case.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Sergey Bylokhov 
Sent: 29 October 2015 02:17
To: Rajeev Chamyal; Philip Race
Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net
Subject: Re: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window

Thanks for clarification.
The fix looks fine.

On 20.10.15 11:49, Rajeev Chamyal wrote:
> Hello Sergey,
>
> I mentioned incorrectly that JDK8 is using CMS as default garbage collector. JDK 8 uses Parallel GC as default collector.
>
> Following are the results with  Parallel GC as default collector in JDK9.
>
> Max java process size before fix while running test case(webrev) : 220MB (approx.)  JDK version build 1.9.0-ea-b86.
> Max java process size after fix while running test case(webrev) : 130MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Rajeev Chamyal
> Sent: 20 October 2015 12:10
> To: Sergey Bylokhov; Philip Race
> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: RE: Review request for JDK-8030099 Memory usage of java 
> process increases after pressing start button in test window
>
> Hello Sergey,
>
> Below are my observation while testing the fix.
>
> Max java process size before fix while running test case(webrev) : 170MB (approx.)  JDK version build 1.9.0-ea-b86.
> Max java process size after fix while running test case(webrev) : 165MB(approx.). JDK9 version 1.9.0-internal-_2015_10_15_21_12-b00.
> The results are not consistent always in both cases.
>
> We cannot compare these results with JDK8 because it uses CMS collector as default garbage collector while JDK9 is using G1 collector.
> G1 collector is giving better results because it does heap compaction as well.
>
> We are using different reference types  in different files ( files registering instances with Disposer) e.g. StrikeCache uses SoftReferences.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: 20 October 2015 03:54
> To: Philip Race; Rajeev Chamyal
> Cc: Alexander Scherbatiy; swing-dev at openjdk.java.net
> Subject: Re: Review request for JDK-8030099 Memory usage of java 
> process increases after pressing start button in test window
>
> On 20.10.15 0:50, Philip Race wrote:
>> The code change looks fine. The test is delightfully complicated.
>
> I still have not got a benefit of weak references in this use case. Does it mean that weak are always better? If yes, then we should at some point change default policy for all other cases as well.
>
>> Did you run it under jtreg ?
>>
>> -phil.
>>
>>
>> On 10/19/15, 5:10 AM, Rajeev Chamyal wrote:
>>> Hello,
>>>
>>> Please review the following fix for Jdk9:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8030099
>>>
>>> Webrev:http://cr.openjdk.java.net/~rchamyal/8030099/webrev.00/
>>> <http://cr.openjdk.java.net/%7Erchamyal/8030099/webrev.00/>
>>>
>>> Issue: The memory usage of java process goes on increasing if we 
>>> call ShellFolder:listFiles API
>>>
>>> aggressively on some folder with large number of files/folders.
>>>
>>> Cause: Win32ShellFolder class registers its instances and native 
>>> data with sun.java2d.Disposer class for later disposal.
>>> Win32ShellFolder instances are getting registered as 
>>> PhantomReferences with Disposer and are not getting cleared immediately.
>>> This leads to increase of memory usage by java process.
>>> Fix: Instead of registering the complete Win32ShellFolder object 
>>> reference with disposer we are now adding only a sentinel object and 
>>> also using sun.java2d.Disposer :: addObjectRecord API which adds the 
>>> references as WeakReferences.
>>> Regards,
>>> Rajeev Chamyal
>>>
>
>
> --
> Best regards, Sergey.
>


--
Best regards, Sergey.