Applets and memory not being released by Java Plug-in

Question

Hi.
I am experiencing a strange memory-management behavior of the Java Plug-in with Java Applets. The Java Plug-in seems not to release memory allocated for non-static member variables of the applet-derived class upon destroy() of the applet itself.
I have built a simple "TestMemory" applet, which allocates a 55-megabytes byte array upon init(). The byte array is a non-static member of the applet-derived class. With the standard Java Plug In configuration (64 MB of max JVM heap space), this applet executes correctly the first time, but it throws an OutOfMemoryException when pressing the "Reload / Refresh" browser button or if pressing the "Back" and then the "Forward" browser buttons. In my opionion, this is not an expected behavior. When the applet is destroyed, the non-static byte array member should be automatically invalidated and recollected. Isn't it?
Here is the complete applet code:
// ===================================================
import java.awt.*;
import javax.swing.*;
public class TestMemory extends JApplet
  private JLabel label = null;
  private byte[] testArray = null;
  // Construct the applet
  public TestMemory()
  // Initialize the applet
  public void init()
    try
      // Initialize the applet's GUI
      guiInit();
      // Instantiate a 55 MB array
      // WARNING: with the standard Java Plug-in configuration (i.e., 64 MB of
      // max JVM heap space) the following line of code runs fine the FIRST time the
      // applet is executed. Then, if I press the "Back" button on the web browser,
      // then press "Forward", an OutOfMemoryException is thrown. The same result
      // is obtained by pressing the "Reload / Refresh" browser button.
      // NOTE: the OutOfMemoryException is not thrown if I add "testArray = null;"
      // to the destroy() applet method.
      testArray = new byte[55 * 1024 * 1024];
      // Do something on the array...
      for (int i = 0; i < testArray.length; i++)
        testArray[i] = 1;
      System.out.println("Test Array Initialized!");
    catch (Exception e)
      e.printStackTrace();
  // Component initialization
  private void guiInit() throws Exception
    setSize(new Dimension(400, 300));
    getContentPane().setLayout(new BorderLayout());
    label = new JLabel("Test Memory Applet");
    getContentPane().add(label, BorderLayout.CENTER);
  // Start the applet
  public void start()
    // Do nothing
  // Stop the applet
  public void stop()
    // Do nothing
  // Destroy the applet
  public void destroy()
    // If the line below is uncommented, the OutOfMemoryException is NOT thrown
    // testArray = null;
  //Get Applet information
  public String getAppletInfo()
    return "Test Memory Applet";
// ===================================================Everything works fine if I set the byte array to "null" upon destroy(), but does this mean that I have to manually set to null all applet's member variables upon destroy()? I believe this should not be a requirement for non-static members...
I am able to reproduce this problem on the following PC configurations:
* Windows XP, both JRE v1.6.0 and JRE v1.5.0_11, both with MSIE and with Firefox
* Linux (Sun Java Desktop), JRE v1.6.0, Mozilla browser
* Mac OS X v10.4, JRE v1.5.0_06, Safari browser
Your comments would be really appreciated.
Thank you in advance for your feedback.
Regards,
Marco.

Answer 1

Hi Marco,
my guess as to why JPI would keep references around, if it does keep them, is that it propably is an implementation side effect. A lot of things are cached in the name of performance and it is easy to leave things laying around in your cache. Maybe the page with the associated images/applets is kept in the browser cache untill the browser needs some memory and if the browser memory manager is not co-operating with the JPI/JVM memory manager the browser is not out of memory, thus not releasing its caches but the JVM may be out of memory. Thus the browser indirectly keeps the reference that it realy does not need. This reference could be inderect through some 'applet context' or what ever the browser uses to interact with JPI, don't realy know any of these details, just imaging what must/could be going on there. Browser are amazingly complicated beast.
This behaviour that you are observing, weather the origin is something like I speculated or not, is not nice but I would not expect it to be fixed even if you filed a bug report. I guess we are left with relleasing all significatn memory structures in destroy. A simple way to code this is not to store anything in the member fields of the applet but in a separate class; then one has to do is to null that one reference from the applet to that class in the destroy method and everything will be relased when necessary. This way it is not easy to forget to release things.
Hey, here is a simple, imaginary, way in which the browser could cause this problem:
The browser, of course needs a reference to the applet, call it m_Applet here. Presume the following helper function:
Applet instantiateAndInit(Class appletClass) {
Applet applet=appletClass.newInstance();
applet.init();
return applet;
When the browser sees the applet tag it instantiates and inits the new applet as follows:
m_Applet=instantiateAndInit(appletClass);
As you can readily see, the second time the instantiation occurs, the m_Applet holds the reference to the old applet until after the new instance is created and initlized. This would not cause a memory leak but would require that twice the memory needed by the applet would be required to prevent OutOfMemory.I guess it is not fair to call this sort of thing a bug but it is questionable design.In real life this is propably not this blatant, but could happen You could try, if you like, by allocating less than 32 Megs in your init. If you then do not run out of memory it is an indication that there are at most two instances of your applet around and thus it could well be someting like I've speculated here.
br Kusti