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.
