Bug ID: JDK-5071686 JVM Leaks large amount of memory when running applets

Type: Bug
Component: deploy
Sub-Component: plugin
Affected Version: 1.4.2_05

Priority: P2
Status: Resolved
Resolution: Fixed
OS: windows_2000
CPU: x86

Submitted: 2004-07-06
Updated: 2004-10-13
Resolved: 2004-10-12

Other	JDK 6
1.4.2_07Fixed	6 b08Fixed

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

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_07 1.5.0_01 FIXED IN: 1.4.2_07

02-10-2004

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); } }

02-10-2004

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

17-09-2004