Bug ID: JDK-6671092 java.lang.OutOfMemoryError thrown with new plugin

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6
6u10 b26Fixed

build tested - 6u10 pit b13 from the following location
http://j2se.east/plugin/1.6.0_10-pit/2008-02-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)
This may be a regression of 6613370.
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.

EVALUATION 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.

18-05-2008

SUGGESTED FIX webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6671092.1 testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6671092/

18-05-2008

Relates :	JDK-6613370 - Plugin2 : OutOfMemoryError while running some of the applets
Relates :	JDK-2162617 - Strong reference to RepaintManager in AppContext keeps components alive too long
Relates :	JDK-6703401 - Strong reference to RepaintManager in AppContext keeps components alive too long
Relates :	JDK-6709152 - java.lang.OutOfMemoryError is still getting thrown while reloading some of the applets