JDK-6410143 : Out of memory in web application with JVM 1.4.2_05/1.4.2_08
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2_08
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2003
  • CPU: x86
  • Submitted: 2006-04-07
  • Updated: 2010-08-19
  • Resolved: 2006-10-10
Related Reports
Duplicate :  
JDK-6293787 - Unexpected memory growth while using Inflater/Deflater classes
Description
We are experiencing problems with Sun HotSpot JVM 1.4.2_05/1.4.2_08 along with BEA WebLogic 8.1.4/8.1.5. The signature of the problem is that we observe excessive GC, increasing System Memory usage, increasing Processor usage and increasing System Handle count. For our confirmation for the problem with HotSpot JVM, we tried running our application using JRockit 1.4.2_05/1.4.2_08 with BEA WebLogic 8.1.4/8.1.5, and there the application does not show the signature explained above. Also on WebSphere with IBM's JVM we don see this problem.
In result of the above said behavior of HotSpot JVM, our application response times have crossed undesirable limits (because of GC hogging the system).
we used following JVM options in WL: -Xms512m -Xmx1464m -XX:MaxPermSize=96m-Xloggc:c:/gc.log -XX:+PrintGCDetails.
The application is web based, which is trying to fetch some data from the repositories/ database and renders it on IE. I am not very sure exactly what kind of details can help you more to relate to the problem.
Comments
EVALUATION Haven't heard any disagreement with my suggestion that the problem is one of prompt finalization. I'm closing this as a duplicate of 6293787 that will deal with that for jdk7.
10-10-2006
EVALUATION Based on what I've observed from the IBM GC logs the problem is that the finalizer thread is not running sufficiently often to finalize objects and free space. This is a known problem the fix for which is targetted to dolphin.
16-05-2006
EVALUATION Suggested to increase the heap size and need to get GC logs with IBM jdk. Tried with the option suggested by engineering ie UseParallelGC ,but they are still facing the same problem and provieded the GC logs to engineering for verification.
02-05-2006
EVALUATION The size of the heap is too small to run efficiently. From file SunHotSpotJVM1.4.2_05_BrowseToLevel4_gclog.gc toward the end of the file is the line 3112.601: [Full GC 3112.601: [Tenured: 1332607K->1332604K(1332608K), 2.9228269 secs] 1482495K->1389926K(1482496K), [Perm : 30241K->30241K(30464K)], 2.9228948 secs] The segment "Tenured: 1332607K->1332604K(1332608K)" indicates that the amount of live data in the heap is 1332604K (that is the amount of space used in the tenured generation by live objects). The GC is collecting about 3k of garbage, the application is allocating it again so that the heap is full and another collection has to start. Try a larger heap. In SunHotSpotJVM1.4.2_10_BrowseToVolumeLevel_gclog.gc the line toward the end of the file 3650.643: [Full GC 3650.643: [Tenured: 1332607K->1332607K(1332608K), 2.8928690 secs] 1482495K->1382636K(1482496K), [Perm : 32050K->32050K(32256K)], 2.8929340 secs] again shows that the heap is almost full of live data. The segment Tenured: 1332607K->1332607K(1332608K) shows that almost no garbage is found (at least whatever is found is less than 1K). Please try a larger heap and let us know if that fixes the problem.
27-04-2006