build tested - 6u10 pit b13 from the following location
http://j2se.east/plugin/1.6.0_10-pit/2008- customer -22.08_28/
OS tested - Nevada x86, XP Pro, RHEL 5
browsers tested - FF3,IE7

Description - java.lang.OutOfMemoryError is thrown with the new plugin under some scenarios.
In one particular scenario we are defining a byte array of around 55M and on refreshing the browser/reloading the applet java.lang.OutOfMemoryError will get thrown. If we set array to null inside the destroy method then java.lang.OutOfMemoryError is not getting thrown.

Steps to reproduce:

Run the following applet
http://sqeweb.sfbay/deployment2/jitu/plug-bug/ALC/MemoryTest.html

Reload the applet several times until the following exception is thrown:
Exception in thread "thread applet-MemoryTest-11" java.lang.OutOfMemoryError: Java heap space
	at MemoryTest.init(MemoryTest.java:65)
	at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Posted Date : 2008-03-04 20:01:31.0

This may be a regression of 6613370.
Posted Date : 2008-03-04 20:13:33.0

It looks like the applet reference will still be bound and no GC will happen
when the browser initiates an applet stop/destroy.

We have to look into the 'destroy()' logic,
where we have a left over applet reference,
and therefor a memory leak.
Posted Date : 2008-05-14 13:00:58.0

N/A

There were several reasons why the Plugin2Manager instance, and
therefore the applet, were being kept alive too long. It isn't
completely clear why some of these didn't show up during the
investigation of prior bug 6613370.

  - The StartAppletListener in PluginMain was finalizable and was
    therefore keeping a semi-strong reference to the Plugin2Manager
    alive.

  - The Runnable which disposed the AppContext was implicitly keeping
    the Plugin2Manager alive during this operation. Factored this out
    into a separate static inner class.

  - The AppletContextImpl, which is stored in the AppContext, was also
    a non-static inner class of the Plugin2Manager. Some outside code
    expects the AppletContext reference to be stored in the AppContext
    (rather than a weak reference, for example), so the
    AppletContextImpl's reference to the Plugin2Manager was made weak.

  - The Swing RepaintManager, which is stored in the AppContext, keeps
    strong refereces to the Components it manages. Because it seemed
    too risky to make extensive changes in this class at this point in
    the release, a workaround was added to clear the RepaintManager
    from the AppContext before disposing the AppContext. A follow-on
    bug, 6703401, has been filed to track the deeper RepaintManager
    issue.

With these changes the test case can now be reloaded rapidly.
Posted Date : 2008-05-18 05:00:52.0