JDK-6613370 : Plugin2 : OutOfMemoryError while running some of the applets
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u5
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: generic
  • Submitted: 2007-10-05
  • Updated: 2010-04-04
  • Resolved: 2007-10-31
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
6u10Resolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Some of the applets are throwing "Exception in thread "AWT-EventQueue-4" java.lang.OutOfMemoryError: Java heap space" at thh time of loading or when applet is refreshed
Scenario I:
Try loading the following applet inside the browser,  If on refreshing the page java.lang.OutOfMemoryError exception is getting thrown then bug is reproduced:

http://sqeweb.sfbay.sun.com/deployment2/jitu/deployment_JDK7_int_ws/deployment/src/plugin/manual/html/MemoryTest.html

Note: In this particular test we are defining a byte array, if we set array to null inside the destroy method then no exception is getting thrown.

Scenario II: Load the following applet inside the browser, it will fail to load with java.lang.OutOfMemoryError exception getting thrown
http://sqeweb.sfbay.sun.com/deployment2/jitu/plug-bug/security/ImageTest/JvmGifVulPoc1.html

Comments
EVALUATION This bug is being marked as a duplicate of 6622332 for bookkeeping purposes and does not need to be re-verified independently. In the case of a regression please file a new bug.
31-10-2007

EVALUATION Worked around AWT bug 6616095 where a strong reference is keeping the AppContext alive too long. Strong references to the Applet2Manager and from there to the applet instance were preventing timely garbage collection of the applet. Fixing this bug uncovered subtle problems that will arise if or when we implement the class loader caching mechanism from the old Java Plug-In. Added notes on usage of problematic APIs. Note that these changes do not fix all of the issues described in the bug report. Specifically, the second scenario occurs because the applet attempts to allocate 80 MB, and the default heap size is 64 MB. The reason this test case works in the old plug-in is due to 4222760, which was a hack to change the heap size based on the available physical and virtual memory designed to work around the lack of multiple JRE support. See CJavaJNI::AddMemoryOption. Now that we have the ability to change the heap size on a per-applet basis, we are not going to incorporate said hack into the new plug-in.
16-10-2007

SUGGESTED FIX http://sa.sfbay.sun.com/projects/deployment_data/6u5/6613370.1
16-10-2007