United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4957990 PermHeap bloat in and only in server VM
JDK-4957990 : PermHeap bloat in and only in server VM

Details
Type:
Bug
Submit Date:
2003-11-21
Status:
Closed
Updated Date:
2010-07-21
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
hotspot
OS:
solaris_9,solaris_8,linux,solaris_10
Sub-Component:
gc
CPU:
x86,sparc
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.1_05,5.0,5.0u11,6,6u14p
Fixed Versions:
hs17 (b01)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

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
                                     
2004-06-16
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-07-08
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.
                                     
2006-01-06
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.
                                     
2006-01-06
EVALUATION

See suggested fix section for a fix for stop-world collectors.
The fix for concurrent class unloading has been split off into 6868071.
                                     
2009-08-04
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/
                                     
2009-08-04
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/8b46c4d82093
                                     
2009-09-02
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b46c4d82093
                                     
2009-09-25



Hardware and Software, Engineered to Work Together