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; [email protected] 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; [email protected] > 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; [email protected] > 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.
