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.
|
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
|
Java