<AWT Dev> Memory leaks due to static references in AWT & Swing

Jaroslav Tulach jtulach at netbeans.org
Wed Jul 20 03:32:02 PDT 2011

>## 20. 7. 2011 10:04:26 ##<
> as far as I can see you suggest to replace strong references to
> focusOwner, permanentFocusOwner, focusedWindow, and activeWindow to
> weak ones.
> But do you have test which can prove that any of these fields cause
> real memory leak?

Yes, I have a test. My whole motivation is to fix our tests. Here is one of 

It is not standalone however. If the precondition for accepting my change is 
to write a standalone test, I'll prepare one and wait until it fails.

> As far as I know KFM is supposed to update these fields as soon as
> focus state has been changed, thus if
> you do have memory leak then it is a bug in KFM and your fix is just a
> workaround for the problem.

From a rational point of view, you are right. However my primary goal is to 
extinguish the problem. I don't oppose somebody seeking for the source of the 
problem, but meanwhile I'd rather see usage of weak references. It is easy to 
reason about such change and it is obvious it eliminates the GC problem in 
this case.

Btw. KeyboardFocusManager is just one of the problems. If you look at
you'll find out that we used to have additional problems with 
sun.awt.im.InputContext, java.awt.Container, 
sun.awt.im.CompositionAreaHandler, sun.awt.X11.XKeyboardFocusManagerPeer
All these classes would deserve weak reference, imho.


> On Wed, Jul 20, 2011 at 11:36 AM, Jaroslav Tulach <jtulach at netbeans.org> 
> > Hello.
> > My name is Jaroslav Tulach and I working on NetBeans. Recently I started
> > to fight with memory leaks by writing some automated tests to verify
> > that some sequence of actions does not leave a memory behind.
> > 
> > I think the tests are paying off, we managed to fix many leaks in
> > NetBeans code. However now we are facing an unsolvable problem: there
> > are some (temporary) leaks in AWT and Swing code which cause our tests
> > to randomly fail.
> > 
> > We tried to workaround the problem (by opening new unrelated windows, or
> > using reflection to clean well known references), but so far our
> > solutions are fragile and the test continue to fail in new, inventive
> > ways (for example https://netbeans.org/bugzilla/show_bug.cgi?id=197905).
> > 
> > It would be much easier if we could eliminate the (temporary) memory
> > leaks in AWT/Swing code. I am attaching a patch that uses WeakReference
> > instead of strong one that would fix one of our failing test.
> > 
> > What it would take to accept my patch? Thanks for your advice and help.
> > -jt

More information about the awt-dev mailing list