JDK-4957990 : PermHeap bloat in and only in server VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.1_05,5.0,5.0u11,6,6u14p
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    linux,solaris_8,solaris_9,solaris_10 linux,solaris_8,solaris_9,solaris_10
  • CPU: x86,sparc
  • Submitted: 2003-11-21
  • Updated: 2010-07-21
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other Other JDK 6 JDK 7 Other
5.0u23-rev,hs16.2Fixed 5.0u24-revFixed 5.0u25Fixed 6u19-revFixed 7Fixed hs16.2Fixed
Related Reports
Duplicate :  
JDK-6351173 - Crash in OSR / GC test
Relates :  
JDK-6884552 - remove some unnecessary #ifdef's introduced in the fix for 4957990
Relates :  
JDK-6885169 - merge of 4957990 and 6863023 causes conflict on do_nmethods
Relates :  
JDK-6268279 - Full GC causes core
Relates :  
JDK-6868071 - CMS: reduce perm heap bloat on account of 4957990
Relates :  
JDK-5033614 - ClassLoaders do not get released by GC, causing OutOfMemory in Perm Space
Relates :  
JDK-6234462 - OOM in Perm Gen in SAP's hotdeploy scenario
Description
Description: With updating ClassLoader several times, jdk1.4.1_05 server VM will be down with an error java.lang.OutOfMemoryError. 

Environment:
OS : Solaris8
MPU: sparcv9 processor 450 MHz * 2
Mem: 2048 Megabytes

Reproduction: 
1. To unzip the attached tp.zip.
2. To change the direcotory to tp.
3. Set the JAVA_HOME variable viable in the script client.sh.
4. To type "sh client.sh" to launch the test program.
5. You will see the test program stop there and java.lang.OutOfMemoryError shown.
...
[Loaded dummy.target.Target1692]
[Loaded dummy.target.Target1693]
[Loaded dummy.target.Target1694]
[Loaded dummy.target.Target1695]
[Loaded java.lang.ClassFormatError from 
/j2sdk1.4.1_05/jre/lib/rt.jar]
java.lang.OutOfMemoryError
[Loaded java.lang.StackTraceElement from 
/j2sdk1.4.1_05/jre/lib/rt.jar]
[Loaded java.util.HashMap$KeyIterator from 
/j2sdk1.4.1_05/jre/lib/rt.jar]

 The test program test.MainEntry creates URLClassLoader that loads and destroy the classes in the package dummy. And those classes under dummy package are just for a burden test on VM. The VM args can be referenced in the script client.sh.


2003-11-21
Changed synopsis line from:

PermHeap overflow in and only in server VM

to:

PermHeap bloat in and only in server VM

so as to avoid customer confusion that this is a "leak"
(which this is not). See evaluation and comments section
for more details.
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b46c4d82093
25-09-2009
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8b46c4d82093
02-09-2009
EVALUATION See suggested fix section for a fix for stop-world collectors. The fix for concurrent class unloading has been split off into 6868071.
04-08-2009
SUGGESTED FIX The following diffs are under test and will be submitted for review:- http://analemma.sfbay.sun.com/net/neeraja/export/ysr/perm-refs/webrev/
04-08-2009
EVALUATION As stated above, the result of treating these references as strong (as done currently) rather than as weak references (as we'd ideally want) leads to "cluster" formations such that one live method causes a cluster of other methods to remain reachable. This results in a possible perm gen footprint bloat, but NOT a leak in the traditional sense (a leak is something whose total accumulated flux is unbounded over time). Note that, once all the members of said cluster become unreachable, the space is reclaimed by GC. The test cases run well forever provided the JVM is given enough perm gen space to swallow the cluster humps. This is a day-one bug. We are working on a solution to reduce the perm heap bloat.
06-01-2006
WORK AROUND Use a larger perm gen. Note that this is not a "memory leak" in the JVM (in the sense of being unbounded over time); rather it is a perm gen footprint dilation problem. See comments in evaluation section.
06-01-2006
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
08-07-2004
EVALUATION This bug is reproducible in Tiger & Mantis. I tested on my machine softvision.india with j2sdk1.5.0_b38, 1.4.2_04. With -server VM (-XX:PermSize=64M) I see that class unloading never happens and app hangs/terminates with OutOfMemoryError. One more imp thing is, with -server -XX:MaxPermSize=128m, I *do see* that class Unloading happens and *no OutOfMemoryError* occurs. With MaxPermSize=128M at some instances PermSpace goes upto 110M but then drops around 70M after unloading. This continues and no OutOfMemoryError msgs are shown. I ran test app for almost 1 hour long to confirm this. (With -client and -XX:PermSize=64M, at some point Perm space goes upto appro 62M and then class unloading happens and Perm space drops to around 30M. This continues and no OutOfMemoryError msgs are shown.) So, it seems this issue is related to "Class Unloading" with server compiler. ###@###.### 2004-02-23 Customer reports that OurOfMemoryError occurs with -XX:MaxPermSize=128m as well though it took long time. ###@###.### 2004-02-26 ------------------------------------------- Ran the testcase with -server with the following options: -server -XX:+PrintCompilation -XX:CompileThreshold=10000000 It didn't show any compilation. After the number of classes in systemdictionary reached 5183 and used permgen reached around 48m, the unloading of the classes happened. ###@###.### 2004-04-13 -------------------------------------------- Running a fastdebug VM with TypeProfileWidth=0 makes the problem go away. We believe that the problem occurs because methodDataOops have strong references to klassOops, therefore inhibiting the unloading of those classes. If GC would treat MDO oop references as weak, then the problem would be solved. Strictly speaking, this is not a compiler2 problem, but a server VM problem. We'll work with the GC to get this bug fixed. ###@###.### 2004-04-30 ------------------------------------------- Overview: The test case operates in a loop. It creates a classLoader, and the classLoaders loads 1800 classes with about 70 methods each. This creates roughly 125K methodOops. With that many methods, PermGen space is dominated by the methodOops. For the VM to be successful in running the test, GC needs to recognize that the classLoader and its classes are dead and collect them. Further analysis indicates that HP's test case is exposing three issues. First, methodOops in the server VM are larger than client. On 1.4.2 client, methodOops are 108 bytes in size, on server, they are 132 bytes in size. In Tiger, part of the methodOop has been split off into the constantMethodOop, but the total space required for a method grows to 140 and 156 bytes, respectively. We can't "fix" this problem. Second, as mentioned above, the VirtualCallData in a MethodDataOop is being treated as strong reference by GC. Each cross-classLoader reference can possibly keep a classLoader alive. This can be worked around by using TypeProfileWidth=0. Third, nmethod::oop_do() treats inline cache oops as strong references. In HP's case, the inline cache reference keeps alive a classLoader, causing PermGen to fill, even with the workaround for issue #2. An early prototype indicates that by fixing issues #2 and #3 above, the server VM should be able to the test in under 64M in 1.5.0. It appears that bug 5033614 may be suffering the same problems as this one. ###@###.### 2004-05-26 -------------------------------- A VM with a prototype for the inline cache oops was given to the customer. Using the workaround for the MethodDataOop issue, the customer verified that their issue was solved. A combination of fixes for these two issues will be targeted for mustang. As this is primarily a GC issue, am reassigning this bug to GC, but the compiler group will continue to work with GC towards a solution. ###@###.### 2004-06-16
16-06-2004