United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-5071686 : JVM Leaks large amount of memory when running applets

Details
Type:
Bug
Submit Date:
2004-07-06
Status:
Resolved
Updated Date:
2004-10-13
Project Name:
JDK
Resolved Date:
2004-10-12
Component:
deploy
OS:
windows_2000
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.4.2_05
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

Description
The applet uses large amounts of memory, e.g. - one or two megabytes each time it is displayed,
when redisplay an image multiple times using applet. The amount of virtual memory consumed by Internet Explorer grows by around 87KB in each iteration. After numerous invocations, virtual memory is completely consumed.

This problem is reproducible in Internet Explorer 6.0, Netscape 7.0 and the latest version of Mozilla.

For simulating the problem, see the comments part.
###@###.### 2004-07-06
###@###.### 2004-07-06

                                    

Comments
EVALUATION

I ran RunWIEapplet.html with JacoZoom as described in README file using latest promoted build of 1.5.0 (B57)
and 1.4.2_04.
I navigated many times back and forth to the WebImageApplet to allow this applet to be destroyed and reload.

- With 1.5.0, IExplore's memory footage stays pretty constant at ~ 42.5M on my machine.  I do not see any obvious leakage
with subsequent runs of the applet.

- With 1.4.2_04, I can see the leak of ~600K each time the applet is reloaded in the browser (that's, Java Plugin is in used).

However, Windows Task Manager's process monitor is not a good tool to examine leak.
I will try to profile with OptimizeIt.  But in order for me to do that, please send source code for WebImageApplet.java
(source code for all, if you could, would be even more helpful).

As for this point, per initial my investigation, it looks that this is a 1.4.2 issue, not a 1.5.0 issue.  I will continue to profile
the example to confirm this.  There are many leak resolutions across the board in 1.5.0, but not necessarily that all
can be applicable to 1.4.2.  I would suggest to escalate this problem to CTE (if you have
not already done so), to have them address this problem in current 1.4.2 patch.  CTE can work with us if they need help.

###@###.### 2004-07-12

-------------------------------------------------------------
This is an escalated bug against 1.4.2. Problem is reproducible in 1.4.2 and using Optimizeit, I found that two things are causing the memory leak:

1. The URL instances grow in number after every reload.

URLClassPath has two member fields 'urls'(Stack) and 'path'(ArrayList) and in method addURL(URL url) we are adding the passed 'url' to 'urls' and 'path' without checking if it already exists in them. I modified addURL to avoid the addition if 'url' already exists in the stack and arraylist. With this change the amount of leak decreased.

2. With the above change, I still saw the instances of following objects growing:
javax.swing.text.GapContent$MarkData
javax.swing.text.GapContent$StickyPosition
javax.swing.text.AbstractDocument$LeafElement

These instances get created when some string is written into the
Sun JavaPlugin Console window. As the testcase is printing lot of data into the plugin console, the above mentioned instances keep growing in number. But if after every iteration of applet loading, the plugin console is cleared(by pressing 'c' in console), then these instances don't grow further.

In the implementation, these instances are stored in an array (children in AbstractDocument class)and the array keeps growing as more and more strings are inserted in the console. But on clearance, the size of array is not reduced, only the contents are replaced in replace() method in javax/string/text/AbstractDocument.java. So the customer is facing this memory leak because of growing size of this array. I think we should remove the contents and reduce the size of array when the 'length' parameter value is less than the size of 'children' array. 

###@###.### 2004-07-13
===========================================================================

1) The first case mentioned above (leak in URLClassPath) is minimal as the path ArrayList and urls stack contain only url path for applet loaded jars.  But I agree, without checking for existence of url path before add, duplicating entries will happen everytime the same resource is visited.  Since the ClassLoader is reused each time applet is restarted (without shutting down the browser), ArrayList and urls can grow unecessarily.  But this leak should be small.

2) I'm interested to inspect the 2nd leak that you mentioned in (2) above, but I do not have source code to test applet.  Please attach testcase source code to bug report as soon as you can.  This fix may be applicable to 1.5.0_01 and 1.6.0 as well.

Thanks.

###@###.### 2004-09-17
---------------------------------------------------
The bug is applicable to 1.5.0_01 and 1.6.0. I have attached the testcase with this bugreport.

###@###.### 2004-09-22
                                     
2004-09-17
SUGGESTED FIX

--- ConsoleWindow.java  Fri Aug 27 05:04:31 2004

*** 56,65 ****
--- 56,67 ----
  import sun.plugin.util.PluginLogger;
  import sun.plugin.cache.JarCache;
  import sun.plugin.cache.FileCache;
  import sun.plugin.services.BrowserService;
  import sun.plugin.util.PluginSysUtil;
+ import javax.swing.text.Document;
+ import javax.swing.text.PlainDocument;
  
  class ConsoleWindow extends JFrame
  {
      {
        // Change metal theme - make all fonts PLAIN instead of

*** 249,258 ****
--- 251,264 ----
            {
                // Add header in the beginning of Console window
                String strVersion = displayVersion();
                String strHelp = displayHelp();
                String strHeader = strVersion + "\n" + strHelp;
+ 
+                 Document document = new PlainDocument();
+                 textArea.setDocument(document);
+ 
                textArea.setText(strHeader);
  
                //textArea.setText("");
                textArea.revalidate();
  


--- URLClassPath.java   Wed Sep 15 01:49:36 2004

*** 107,116 ****
--- 107,119 ----
       * Appends the specified URL to the search path of directory and JAR
       * file URLs from which to load classes and resources.
       */
      public void addURL(URL url) {
        synchronized (urls) {
+             if (path.contains(url))
+                return; 
+           
              urls.add(0, url);
            path.add(url);
        }
      }
                                     
2004-10-02
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_07
1.5.0_01

FIXED IN:
1.4.2_07


                                     
2004-10-02



Hardware and Software, Engineered to Work Together