JDK-6327297 : OutOfMemoryError after running a few SwingSet2 Applet
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows
  • CPU: x86
  • Submitted: 2005-09-22
  • Updated: 2010-04-02
  • Resolved: 2005-11-23
Related Reports
Duplicate :  
JDK-6351698 - Regression: 4506928 testcase is passing with 142_10-b03 but failing with 142_11-b01
Relates :  
JDK-5052169 - memory leak triggered by use of Component$NativeInLightFixer
Relates :  
JDK-5076963 - JNI bugs in sun.awt.windows.WToolkit.eventLoop()
Description
Tested on windows XP machine.

Install Mustang b08.

Start a IE window.  enable java console.

Go to:

http://javaweb.sfbay.sun.com/~ngthomas/applet/swingset/

There is 10 swingset2 applet link listed, try to load each of them in the same browser session.  e.g click on 1, which will start the loading of the swingset2 applet, after it finish loading and started, click back on the same browser, and click on 2.

Continue and see if you can run all 10 listed.

after 5 or so, you will get outofmemory errors:

java.lang.OutOfMemoryError: Java heap space
Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java heap space

This is happening since mustang b08; b07 or earlier has not problem, tiger also has no problem.

If you replace the following class files from b07 rt.jar into b08 rt.jar, problem seems to go away:

java.awt.Component*.class
java.awt.EventQueue*.class

Now you can run all 10 swingset2 applet in the same browser session without problems.
Comments
EVALUATION The cause of this bug was verified to be the same as the cause of 6351698: the fix for 5097531 does not free some global/local JNI refs. I will close this as a duplicate even though this bug is older, as 6351698 was already fixed in 1.4.2 and we cannot close it.
23-11-2005
EVALUATION I've rebuild JRE that will free some native resources and put awt.dll into IE's appropriate dir but the leak is still there. It might relate to a misteke while building JRE though.
06-10-2005
EVALUATION There are several candidates to be the regressing fix for current CR: 5076963(activeWindow GR) and 5052169(InLightFixer). The second is not the reason as I just backout that fix and still see OOME there. The first in unlikely as the submitter tried my fix and still sees the problem. The last one is 4952802(event pref.) and it is the most possible cause. We already fixed on of problems with it (6174747 - caching Component in hash holded the reference) but the leak look still there and I'm starting to believe that IExplorerEmbeddedFrame holded by one of the native references. Seems we doesn't clear one of global refs in native peers rather then in our shared code.
06-10-2005
EVALUATION I'm profiling the applet and found that IExplorerEmbeddedFrame holds via plugin classes (IExplorerPluginObject and plugin AppletViewer) and goes to JNI global ref. Unfortunately Java profiler doesn't show a native ref details. It's also hard to audit every global ref inside JDK (or event awt) code.
04-10-2005
EVALUATION public class IExplorerEmbeddedFrame extends sun.awt.windows.WEmbeddedFrame which is the child of heavyweighted Frame. First idea is that plugin just doesn't clear its references but seems the reason is in other place. Perhaps this is because we doesn't clear activeWindow while doing Java_sun_awt_KeyboardFocusManagerPeerImpl_clearNativeGlobalFocusOwner(). This has been done in the fix for 5076963 since every local reference are only valid in it's own thread and we may not clear the link that came from other thread at all. Another possible cause is 5052169 where we clearing every instances reserved for NativeInlightFixer. But the second cause is unlikely.
23-09-2005
SUGGESTED FIX *** /tmp/geta16854 2005-09-23 16:48:43.000000000 +0400 --- awt_KeyboardFocusManager.cpp 2005-09-23 16:48:21.000000000 +0400 *************** *** 128,134 **** AwtToolkit::GetInstance().InvokeFunction ((void*(*)(void))AwtComponent::ClearGlobalFocusOwner); ! CATCH_BAD_ALLOC; } } --- 128,137 ---- AwtToolkit::GetInstance().InvokeFunction ((void*(*)(void))AwtComponent::ClearGlobalFocusOwner); ! JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); ! if (activeWindow != NULL) { ! env->DeleteLocalRef(activeWindow); ! } CATCH_BAD_ALLOC; } }
23-09-2005
EVALUATION some evaluation done by me so far: Recently I discovered this outOfMemory problem, and I trace back the issue and found out it first occur in mustang b08. First I tried to replace the rt.jar from b07 into b08, and then the problem went away; so I tried to dig further and seems like replacing the following classes from b07 seems to fix the problem: java.awt.Component*.class java.awt.EventQueue*.class Same problem exists for b53. I used JProfiler to find out where does all the memory go. I find out after you run each applet (click back on the brwoser to get out), the IExplorerEmbeddedFrame for that applet still exists, so I think basically it holds on all the memory in the applet, so after 5 or so SwingSet2 got run, we run out of memory because we got 5+ IExplorerEmbeddedFrame instances. But in b7 or tiger, whenever we get out of the applet, IExplorerEmbeddedFrame will be disposed and thus the memory can be reclaimed, so we won't run out of memory so easily. This behaviour started in b8, and replacing EventQueue and Component from b7 fixes it. When it run out of memory for me, I have like 6 instances of IExplorerEmbeddedFrame. When I do a "Show Paths to GC root" with the tool, the end path says "JNI Global Reference". Some are thru Swingset2Applet, some thru sun.plugin.AppletViewer, some thru sun.plugin.util.AnimationPanel. There are other end paths to the reference too, like Component$NativeInLightFixer, SunVolatileImage, etc. Many different ends. But these are not in red. Only "JNI Global Reference" is in red, but I don't know what does it mean in red though.
23-09-2005