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 98881 [details] Screenshot of profiler root references to one of the NbModuleProject's Not sure if reproducible, but probably is a P2. 100512, Linux. Had opened and now closed a couple of project groups; now nothing open, yet 42 live NbModuleProject instances in heap! The problem is that you have a WeakHashMap where the values refer strongly to the keys (via processorPath). I tried to fix in 477a4e92bee0 but I guess this got reverted in dbalek's 84c0b0fe9d02 a couple of weeks ago - looks like there is some attempt to produce similar behavior but it does not appear to be working.
Hm, seems that this cannot be solved by any number of WeakReferences (the APTUtils need to listen on APQ$Result to be notified on changes and recompile the affected source root to fix/introduce error badges as appropriate). I have an ugly hack/patch for 6.9, that should make sure that both the listening works and APTUtils are not held in the map(s) after projects are closed. But will need to be investigated deeper in the future.
I committed&pushed the patch: http://hg.netbeans.org/jet-main/rev/c2b5efb36b52 I hope it will work reasonably. Will need more investigation and refinement after 6.9, IMO.
Integrated into 'main-golden', will be available in build *201005170932* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ User: Log:
Still happening (with identical backtrace) in a 7.2 dev build. I analyzed a heap dump and found 117 (!) projects in heap even though none were open. Most of the ones I bothered checking for GC root refs pointed to APTUtils.
Again today, exactly 117 NBM projects leaked. Slightly different backtrace this time, on #31: this org.netbeans.modules.apisupport.project.NbModuleProject #31 project org.netbeans.modules.apisupport.project.Evaluator #50 evaluator org.netbeans.spi.java.project.classpath.support.ProjectClassPathImplementation #383 impl org.netbeans.api.java.classpath.ClassPath #470 processorPath org.netbeans.modules.java.source.indexing.APTUtils #22 value java.util.HashMap$Entry #294598 [16] java.util.HashMap$Entry[] #38942 (1,024 items) table java.util.HashMap #30786 knownSourceRootsMap org.netbeans.modules.java.source.indexing.APTUtils class APTUtils
Any progress? I have not bothered to check heap dumps lately since this remains open and it was typically the major memory leak bug I could find in any dump.
So what exactly should I do to reproduce? I tried to open openide.util.lookup and close it (with some debugging logging), and the knowSourceRootsMap is empy and even though the project still seem to be held, I do not see them to be held through the APTUtils cache.
Not sure how to tell you to reproduce - I do not have specific instructions. Just to check that this bug is still active, I took a heap dump of my IDE as it was running today (all projects and files closed, all potentially troublesome windows like Find Usages closed, waited a little while, GC'd, used jmap -dump:live), then opened the dump in a fresh IDE. Sure enough, there was one freeform project in heap (probably nbbuild), and 58 NBM projects. Picking the first one in the list, I clicked Show Nearest GC Root, and APTUtils.knownSourceRootsMap was the static field in the trace. #11 was held by an AWT bug (sun.awt.im.CompositionAreaHandler). #22, #33, #44, and #55 were all held by by kSRM. So I think that confirms my observation that this is the most common leak. Of course leaks are tricky to pinpoint in an app this size and the Profiler's analysis is not perfect, and there are several other leaks visible (from parsing.api, editor.bookmarks, etc.); I would be more motivated to file them all if the most common one were fixed.
(In reply to comment #8) > Not sure how to tell you to reproduce - I do not have specific instructions. Unfortunately, I do not see much that could be done based on just a screenshot from the profiler. The maps is there for several reasons: -so that we can listen on project's queries are reindex when the query result changes -so that we do not run various queries on projects too often (there are project types that can block for a pretty long time before answering a single a query). -so that we do not load the APs classes too often (as many APs are very slow to load, including most of the NB APs, which neglect to use the standard @SupportedAnnotationTypes, which would give us opportunity to do some caching of the results, and moreover some of them use Class.getCanonicalName, which loads also the enclosing class(es), meaning tons of classes are loaded to find out the AP should not be run in the specific editor window) So, the map itself is not going away. The map is (or should be) cleared when the JavaCustomIndexer is notified that some roots were removed from the indexing cache. And if that event does not arrive under some circumstances, it needs to be debugged why - but I was not able to reproduce so far (I added a task that prints the size of the kSRM each second, and it goes to 0 when all projects are closed. > Just to check that this bug is still active, I took a heap dump of my IDE as it > was running today (all projects and files closed, all potentially troublesome > windows like Find Usages closed, waited a little while, GC'd, used jmap > -dump:live), then opened the dump in a fresh IDE. Sure enough, there was one > freeform project in heap (probably nbbuild), and 58 NBM projects. Picking the > first one in the list, I clicked Show Nearest GC Root, and > APTUtils.knownSourceRootsMap was the static field in the trace. > > #11 was held by an AWT bug (sun.awt.im.CompositionAreaHandler). #22, #33, #44, > and #55 were all held by by kSRM. So I think that confirms my observation that > this is the most common leak. Of course leaks are tricky to pinpoint in an app You mean "the most common leak after all projects are closed". Which on itself is a limited priority - there are many much more serious problems (incremental leaks of something in the editor, repeated exceptions, etc.). If there would still be a leak after another (small) project is opened, that would make it (somewhat) more serious. > this size and the Profiler's analysis is not perfect, and there are several > other leaks visible (from parsing.api, editor.bookmarks, etc.); I would be more > motivated to file them all if the most common one were fixed.
(In reply to comment #9) > many APs are very slow to load, including most of the NB APs If there is a problem, fix it, whether by changing them to use less refactoring-friendly string constants (pending my language RFE for X.class.gCN() to be considered a compile-time constant), or by making the AP handler cache the result of gSAT(). Mostly off topic here I guess. > if that event does not arrive under some circumstances, it > needs to be debugged why - but I was not able to reproduce so far OK. Any particular flags to check this? Or maybe APTUtils could print a WARNING if all projects are closed yet kSRM is nonempty? Somehow it seems to happen to me after a normal IDE session, but that does not mean I know how to reproduce in isolation. > You mean "the most common leak after all projects are closed". Perhaps, I am not sure. Today I tried closing all projects then opening an unrelated j2seproject and getting a heap dump. Seven NbModuleProject's were leaked, though not via APTUtils.map; editor.bookmarks.BookmarkManager responsible for most of them (bug #212261). > If there would > still be a leak after another (small) project is opened, that would make it > (somewhat) more serious. Fairly serious, I would say, since we could be talking about hundreds of megs in total. But again I do not know if that is the case or not.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss