Hello Phil, I have updated the test case as per your review comments. Could you please review it. http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/
Regards, Rajeev Chamyal -----Original Message----- From: Sergey Bylokhov Sent: 12 November 2015 16:02 To: Rajeev Chamyal; Philip Race; Alexander Scherbatiy; [email protected] Subject: Re: Review request for JDK-8030099 Memory usage of java process increases after pressing start button in test window Still looks fine to me. On 02.11.15 19:19, Rajeev Chamyal wrote: > Hello Phil, > > Please review the updated webrev. > http://cr.openjdk.java.net/~rchamyal/8030099/webrev.02/ > > The test case has been updated as per review comments. Added tests for both > Parallel and default collector. > > Regards, > Rajeev Chamyal > > -----Original Message----- > From: Phil Race > Sent: 30 October 2015 01:10 > To: Rajeev Chamyal > Cc: Sergey Bylokhov; Alexander Scherbatiy; [email protected] > Subject: Re: Review request for JDK-8030099 Memory usage of java > process increases after pressing start button in test window > > It is arguably most important to run this with the *default* collector. > If that changes to G1 (I think it is at least temporarily so changed in JDK > 9) then we will never see problems in the case people end up using. > > But you obviously also want to test the case that shows the bug. > > So I would say the best option is to test both : explicit parallel GC and > again with default .. even if they are the same there should be no harm done. > > You may want to increase timeout if running twice but you will have to verify > that. > > -phil. > > > On 10/29/2015 05:48 AM, Rajeev Chamyal wrote: >> 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. > -- Best regards, Sergey.
