This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 100713 [details] Screenshot of profiler root references to one of the NbModuleProject's Found 44 NbModuleProject's in my heap, with no projects or editors open. I am investigating other unrelated leaks I have found, but it seems that ComponentPeer.doc2DictionaryCache leaks Project instances. Seems like the first entry in the table has an NbEditorDocument as the key which is being held by sun.awt.im stuff, and the value has some DictionaryImpl's which hold on to projects. Use assertGC to verify any fix.
100708-85a3b8b8e517
I think there may be two independent concerns: first, as in bug #188915, the project may hold the Document (although I do not think that should be typical); second, a closed document may be held from JDK internals (like sun.awt.im). The first problem is fixed by: http://hg.netbeans.org/jet-main/rev/9dbd4c17f257 The second problem seems more like a bug in the code that holds the closed document. As such, I would prefer not to pollute spellchecker (and possibly many other places) with complex, performance degrading workaround(s), which is only used in quite rare cases (the typical usage of the IDE includes an open editor, I think). It would be better, IMO, to workaround the problem on one place. What exactly is the chain that holds the document? Thanks.
(In reply to comment #2) > first problem is fixed So, RESOLVED/FIXED? > project may hold the Document (although I do not think that should be typical) Seems to be typical in the case of Maven projects. > the typical usage of the IDE includes an open editor, I think Naturally, and open projects too. The point is to ensure that projects (and their typically large transitive closures) are not held in memory long after the projects have been closed and all associated editor windows are closed. And that requires exercising great care with any caches or other static state, unfortunately. > What exactly is the chain that holds the document? sun.awt.im.CompositionAreaHandler.compositionAreaOwner.clientComponent = org.openide.text.QuietEditorPane whose model is the NbEditorDocument.
Integrated into 'main-golden', will be available in build *201007250001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9dbd4c17f257 User: Jan Lahoda <jlahoda@netbeans.org> Log: #188511: making sure that document-dictionary cache will not prevent GCing of documents even if the dictionary holds the document (may happen through project).
> > project may hold the Document (although I do not think that should be typical) > > Seems to be typical in the case of Maven projects. But they should not for prolonged periods, without a good reason, IMO. > > > the typical usage of the IDE includes an open editor, I think > > Naturally, and open projects too. The point is to ensure that projects (and > their typically large transitive closures) are not held in memory long after > the projects have been closed and all associated editor windows are closed. And > that requires exercising great care with any caches or other static state, > unfortunately. Sure. But I still think it is better to ensure that the document will not be in memory and so all document->whatever caches will be cleared automatically, as opposed to hack each of these caches to clear despite the fact that the document still exists. The document itself is leaking anyway, and that may be pretty big thing too.
(In reply to comment #5) >> Seems to be typical [for Project -> Document] in the case of Maven projects. > > But they should not for prolonged periods, without a good reason AFAIK it just uses the Document of pom.xml as the master source of metadata about the project. Whether it ought to be listening only to saved changes, I don't know; this seems to be how XAM/XDM works, or at least how the Maven support is using it. I am not deeply familiar with that code (yet). > The document itself is leaking anyway Not unless someone has misimplemented a cache as in this case, or the document would be released alongside the project when the project is closed. > and that may be pretty big thing too. Perhaps, but likely much smaller than the Project with its various associated objects.
I suggest to mark this issue as resolved/fixed and if the main problem persists (projects still hold from somewhere) to create a new issue with exact reference chain showing where the problem is now after this fix and after 188915 is fixed.
Sure. From time to time I notice that projects are leaking yet again and take a memory dump. Just have to remember to do so around code freeze time.
Ok, making it fixed.
BTW: I think I know how to resolve the "compositionAreaOwner.clientComponent" leak - I should be able to get to that soon.