Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4894522

Applets do not release all memory when destroyed.

XMLWordPrintable

    • 04
    • x86
    • windows_2000
    • Verified



      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)
      ======================================================================

            dgu Dennis Gu (Inactive)
            jkimsunw Jeffrey Kim (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: