|
Quick Lists
|
|
Bug ID:
|
4249798
|
|
Votes
|
30
|
|
Synopsis
|
Memory leak in java plug-in
|
|
Category
|
java_plugin:plugin
|
|
Reported Against
|
1.1.2
, 1.1.3
, kestrel-rc1
|
|
Release Fixed
|
1.2.2_005,
1.3(Bug ID:2027784)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
4-Low
|
|
Related Bugs
|
4316856
,
4318947
,
4422483
|
|
Submit Date
|
25-JUN-1999
|
|
Description
|
Release java plugin 1.1.2
The customer wants to be able to leave the applet page and
return to it later thereby starting and stopping the applet several
times without having to quit and restart the browser.
If the backward and forward buttons of the browser are clicked
too quickly, memory usage by the VM gets to the point where thrashing occurs.
TEST CASE:
import java.awt.*;
import javax.swing.*;
import java.util.Vector;
import sun.applet.AppletSecurityException;
public class test extends JApplet {
JFrame x[] = new JFrame[3000];
int i;
public void init() {
System.out.println("init()");
for (i = 0;i < 3000;i++) {
x[i] = new JFrame("abc");
}
}
public void destroy() {
System.out.println("destroy()");
for (i = 0;i < 3000;i++) {
x[i] = null;
}
}
}
**************************************************************
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title> HP Viridia</title>
</head>
<body>
<h1>HP Viridia</h1>
<hr>
<OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
WIDTH = 400
HEIGHT = 400
codebase="http://java.sun.com/products/plugin/1.1/jinstall-11-win32.ca
b#Version=1,1,0,0">
<PARAM NAME = "CODE" VALUE = "test.class" >
<PARAM NAME = "CODEBASE" VALUE = "." >
<PARAM NAME = "ARCHIVE" VALUE = "test.jar">
<PARAM NAME="type"
VALUE="application/x-java-applet;version=1.1">
<PARAM NAME="dbname" VALUE="">
<COMMENT>
<EMBED
type="application/x-java-applet;version=1.1.2"
java_CODE = "test.class"
java_ARCHIVE = "test.jar"
java_CODEBASE = "."
dbname = ""
WIDTH = 400
HEIGHT = 400
pluginspage="http://java.sun.com/products/plugin/1.1.2/plugin-install.
html">
<NOEMBED>
</COMMENT>
alt="Your browser understands the <APPLET> tag but
isn't running the applet, for some reason." Your browser is completely
ignoring the <APPLET> tag!
</NOEMBED>
</EMBED>
</OBJECT>
<hr>
</body>
</html>
********************************************************************
|
|
Work Around
|
N/A
|
|
Evaluation
|
** Jul 16 1999 12:13PM carolyn **
The change to plugin that creates separate threads
for use by the init() and destroy() methods of the
applets and ensures that both methods are
completed once they are started is non-trivial.
For this reason, I have started conferring with
development engineering to ensure that the
proposed binary does not have any major flaws
and is likely to pass code review, which is
a requirement for patch release.
Since the plugin bundled with JDK1.2.2 has
part of the fix, would it be possible for the
customer to try JDK1.2.2 with the test
case to verify that this is an acceptable fix
for the problem?
Additional parts of the proposed fix address
memory leaks within plugin and jre.
Does the customer have any questions about the
following:
1. The thrashing during initialization of the
test case is caused by heap compaction
and expansion to meet the memory
requirements of this test case.
Similar thrashing can be seen by running the test
case from appletviewer with the verbosegc
option.
When default values of the -ms and -mx
options are used, verbosegc reports
that object space and handle space in
the heap are expanded more than 6 times.
However when the below options are used,
there is no expansion because the minimum
heap size (-ms option) is initialized to a
value larger than the default value of 4m.
The -mx option for maximum heap size is also
larger than the default 16m, so more heap memory
is available before the Out of Memory
exception is thrown.
> appletviewer -J-verbosegc -J-ms16m -J-mx128m test.htm
2. The same thrashing during initialization can
be avoided in the plugin by setting the -mx
and -ms option in the plugin control panel.
3. Since the backward and forward buttons of the
browser are not blocked, it is possible for more
than one applet init() threads to be running
concurrently which can cause many allocations of
JFrame if the clicking is faster than the
execution of the init() and destroy() methods.
Too many allocations of JFrame can again result
in Out of Memory exception if the -mx parameter
in the Control Panel is not large enough.
4. Once the heap has expanded within the Java
Virtual Machine running in the plugin, it
does not shrink.
Leaks:
Although the proposed fix addresses the leaks
associated with non-completion of destroy()
method, there is a very slight improvement
with leak of Java heap.
This test was performed by ensuring that both the
init() and destroy() method completed, which
means that clicking of the backward and forward
buttons was not quick.
Plugin Control Panel options:
-ms16m -mx128m -Djava.compiler=NONE
The java heap size use is taken from:
1. Instrumenting the test case at the end of
the destroy() method with a calls to gc() to
aggresively free everything it can as recommended
in "The Java Programming Language Second Edition"
by Arnold&Gosling, page 322.
2. Obtaining used heap:
long freeMem,totMem,usedMem;
freeMem = Runtime.getRuntime().freeMemory();
totMem = Runtime.getRuntime().totalMemory();
usedMem=totMem - freeMem;
System.out.println("destroy() end mem used " + usedMem +
" total " + totMem + " free " + freeMem);
Once the Java heap amounts stabilize, difference in the
reported amount of heap used in plugin1.1.2_003 patch
was approximately 6600 bytes per init()/destroy() and the
proposed fix difference used was approximately 5500 bytes per
init()/destroy().
****
** Jul 9 1999 4:57PM carolyn **
Have created separate threads for use by the init() and destroy()
methods of the applet to ensure that both methods are completed
once they are started.
As a result, preliminary testing while running Optimizeit shows
that all of the JFrame objects initialized in the init() method of
the applet are eventually destroyed through execution of the
destroy() method of the applet.
However, since the backward and forward buttons of the browser are not
blocked, it is possible for more than one applet init() threads to
be running concurrently which can cause many allocations of
JFrame if the clicking is faster than the execution of the
init() and destroy() methods. Too many allocations of JFrame
can again result in Out of Memory exception if the -mx parameter
in the Control Panel is not large enough.
The threads implementation is a backport from 1.3.
Will quantify remaining leaks that appear in Optimizeit and
compare them to the leak showing in the Task Manager window
before the end of next week.
****
|
|
Comments
|
Submitted On 16-JUL-1999
cwichmann
Noticed this too. For example try all of the sun
plugin demos and the VM will quickly grow. (Mine
increased to 55Megs)
Submitted On 23-JUL-1999
cwichmann
This also appears in the 1.2.2 Plugin
Submitted On 17-APR-2000
jteale
also noticed this against the 1.3 Plugin beta release
Submitted On 15-JUN-2000
justinyork
We are having what I assume is a similar problem. On the
Windows platform, our applet's memory footprint grows
incessantly despite our forcing GC to run. We even verify
that our finalize() methods are called and that all
instance variables are set to null, and all Hashtables and
Vectors are manually purged of data (.clear()
and .removeAllElements()). This is a big problem for us.
Any idea when this will be fixed?
Submitted On 19-JUN-2000
fgerard
We are having the same problem, an applet grows till we get
an OutOfMemoryException. And to make it worse some of out
clients are using W98 and if you kill the browser the JVM
of the plug-in remains up in a way that our clients have to
reboot to recover the memory.
Submitted On 15-DEC-2000
2bean
Also noticed in plugin 1.3.0-C. Each reload consumed 15 mb.
(runtime memory 40 mb) Closing IE release the memory. (W98)
Submitted On 26-FEB-2001
jessn
I have noticed this problem, when I have been using
JBuilder. The maximum number of heaps I have noticed the
VM has used is about 75-80 Megs!
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
|
