United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4894522 Applets do not release all memory when destroyed.
JDK-4894522 : Applets do not release all memory when destroyed.

Details
Type:
Bug
Submit Date:
2003-07-22
Status:
Closed
Updated Date:
2004-01-07
Project Name:
JDK
Resolved Date:
2003-11-15
Component:
deploy
OS:
windows_2000
Sub-Component:
plugin
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.1
Fixed Versions:
1.4.2_04 (04)

Related Reports

Sub Tasks

Description

Name: jk109818			Date: 07/22/2003


FULL PRODUCT VERSION :
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

FULL OPERATING SYSTEM VERSION :
Windows 2K
Version 5 (Build 2195: Service Pack2)

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 6


A DESCRIPTION OF THE PROBLEM :
The memory in use (as viewed from the Windows Task Manager)
seemingly grows without bounds when navigating between
pages containing one or more Swing Applets. This memory is
never fully reclaimed when the browser windows containing
applets are closed and the user navigates to a page that
contains no applets.

This happens with the most basic applet (Sun's
HelloSwingApplet applet - see below). Our larger more
complex applet can be instantiated many times in a browser
session. For some of our customers, this apparent "memory
leak" results in excessive consumption of system resource
resulting in poor performance.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Test Sun's Swing applet example. Browse to
http://java.sun.com/docs/books/tutorial/uiswing/start/swingA
pplet.html.

As you do this monitor the "Memory Usage" in the Windows
Task Manager for the IEXPLORE.EXE process.

2. Click on HelloSwingApplet.html link" At this point the
Java Applet is intialised.

3. Close the HelloSwingApplet.html window.

4. Click on HelloSwingApplet.html link" again.

5. Repeat step 4 a few times.

6. Close all applet windows.

EXPECTED VERSUS ACTUAL BEHAVIOR :
After all applet windows have been closed, the memory in
use by the IEXPLORE.EXE process should return to
approximately where it was before any applets were
launched. At the very least, it should return to the level
it was when the first applet (and hence the JRE) was
initialised.

After launching several instances of the applet and
subsequently closing all applet windows, the memory usage
for the IEXPLORE.EXE process is significantly higher than
it was before any applets were launched. This is expected
as the JRE has now been initialised. However, the memory in
use slowly (but significantly) increases as more browser
pages containing applets are launched and subsequently
closed again.



Conclusion
==========
The JRE fails to release memory back to the operating
system when applets are destroyed.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;          //This is the final package name.
//import com.sun.java.swing.*; //Used by JDK 1.2 Beta 4 and all
                               //Swing releases before Swing 1.1 Beta 3.
import java.awt.*;

public class HelloSwingApplet extends JApplet {

    // This is a hack to avoid an ugly error message in 1.1.
    public HelloSwingApplet() {
        getRootPane().putClientProperty("defeatSystemEventQueueCheck",
                                        Boolean.TRUE);
    }

    public void init() {
        JLabel label = new JLabel(
                           "You are successfully running a Swing applet!");
        label.setHorizontalAlignment(JLabel.CENTER);

        //Add border.  Should use createLineBorder, but then the bottom
        //and left lines don't appear -- seems to be an off-by-one error.
        label.setBorder(BorderFactory.createMatteBorder(1,1,2,2,Color.black));

        getContentPane().add(label, BorderLayout.CENTER);
    }
}


---------- END SOURCE ----------
(Incident Review ID: 180431) 
======================================================================

                                    

Comments
EVALUATION

This bug is same as 4873484. At each refresh of the browser a new classloader is created, because of this singletons are no longer possible . At each refresh a new instance of singleton class is getting loaded.

###@###.### 2003-10-28

Adding the info about client's applet which is showing the memory leak

1. Open Internet Explorer
2. Go to 
http://webtop.micromuse.com:8080/Webtop1.2_demo/panels/eventlists/index3.html
3. Login with username "guest" password "0nlin3dem0" There are two 
zeroes and one three in the password.
4. Press CTRL, ALT and DEL and invoke the task manager
5. Watch the performance subwindow in the task manager for memory usage
6. Reload the applet several times with the refresh button and watch the 
memory usage rise...

Also find the attached test results doc from client.

###@###.### 2003-08-28


The test applet HelloSwingApplet.html will start inside IE browser, 
in step 3: Close the HelloSwingApplet.html window.

I am not sure what it is. The only way to close this applet is to close the IE browser. If that is the case, the memory usage for IE will go away (No IExplorer process anyway). Then start a new IE browser, the memory usage looks OK.

If you just switch to another page without applet in step 3, because JVM is still running on your machine, so IExplorer will show more memory usage. That is the normal behavior. I tested it using new Tiger M3 build.

I don't think this is a bug in JPI.

###@###.### 2003-08-04


                                     
2003-08-04
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.4.2_04

FIXED IN:
1.4.2_04

INTEGRATED IN:
1.4.2_04

VERIFIED IN:
1.4.2_04


                                     
2004-06-14



Hardware and Software, Engineered to Work Together