JDK-4871440 : memory growth of over 100m with 1.4.1_02 vs. 1.3.1
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.1_02,1.4.2
  • Priority: P2
  • Status: Closed
  • Resolution: Not an Issue
  • OS: solaris_2.6,solaris_8
  • CPU: generic,sparc
  • Submitted: 2003-05-29
  • Updated: 2003-08-07
  • Resolved: 2003-08-07
Related Reports
Duplicate :  
JDK-4872150 - Regression: VM C Heap increases 4-5 folds when moving from 1.3.1 to 1.4.1
Relates :  
JDK-4899343 - CMS collector: prompter finalization?
Description
the application is a server side single threaded app that does an XML post and parses it there is a Oracle database connection made with each request

Apple's WebObjects is used 

   Pmapout1.txt is a pmap dump taken right after the process starts up.
   Pmapout2.txt is taken after 1 hour after the process has stabilized 
while
   running upto 1000 transactions. Of particular concern is the heap segment at 
 0002A000
   which grows from 5 to 100 MB. 
   
   Before: 0002A000    5504    5448    2008    3440 read/write/exec    [ heap ]
   After: 0002A000  104960  104904    1184  103720 read/write/exec    [ heap ]
   
   We don't think this is related to the java heap which remains stable: 
   
   Before: F0000000  115712   58336    1392   56944 read/write/exec    [ anon ]
   After: F0000000  116736   94200       8   94192 read/write/exec    [ anon ]
   
   
   2. top results
   
    Before: 178M   (90M-Res)
    After: 282M    (249M-Res)
    
   
   3. vm arguments
   
   -client -XX:+DisableExplicitGC -XX:NewRatio=2 -Xms96M -Xmx96M 
   

A simple program shows that there is more memory used in 1.4.1 and some would be expected but over 100m is unexeptable.

The only test case is on the customer system and they are going to give us access to it to.

there isn't unbounded memory growth, but the 100m jump from 1.3.1 is a great concern
Comments
EVALUATION May be a duplicate of 4872150 ###@###.### 2003-06-05 in this customer's case, the heap growth is mostly because of native call java.util.zip.Deflater.init(). it allocates some memory that will be freed in Deflater's finalize(), they are using a lot of Deflaters and it seems 1.4.1 doesnt finalize those as quickly as 1.3.1, these Deflater's is eventually freed in 1.4.1 but the heap size stays up. now they have added call to Deflater.end() to free up the native memory after using them(Deflater) the heap usage is back to 1.3.1 level. so there seems to be no bug except for the question why in the same configuration 1.4.1 doesnt finalize as quickly as 1.3.1. the customer is happy with adding the "end" call and it seems they are not interested in this question now, so i will close this one as "not a bug" ###@###.### 2003-08-07
07-08-2003