On Wed, Jul 20, 2011 at 2:32 PM, Jaroslav Tulach <[email protected]> wrote: >>## 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 > them: > http://hg.netbeans.org/ergonomics/file/f6cc96cf2c44/core.windows/test/unit/src/org/netbeans/core/windows/services/NbPresenterLeakTest.java > > 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.
it would be nice to see one. >> 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 > http://hg.netbeans.org/ergonomics/file/d4208adce5f1/java.kit/test/qa- > functional/src/org/netbeans/test/ide/WatchProjects.java#l125 > 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. I agree that WeakReference is a nice/simple way to fix (workaround) a lot of problems, but I always prefer to use a hard way ;) Oleg. > > -jt > >> On Wed, Jul 20, 2011 at 11:36 AM, Jaroslav Tulach <[email protected]> > wrote: >> > 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 >
