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.
In a dev build, I had some NBM projects open, then I closed them. I went away, did some stuff, did a GC (still no projects open), and found heap still around 60 Mb. After taking a heap dump, I found that the projects were still loaded. (13 NBM, 1 freeform.) jhat reports that PRN.PC is holding onto them - why, I'm not sure. Sample root ref graph (excluding weak references): Static reference from org.netbeans.modules.project.ui.OpenProjectList.INSTANCE (from class org.netbeans.modules.project.ui.OpenProjectList) : --> org.netbeans.modules.project.ui.OpenProjectList@0x9c1d90e8 (40 bytes) (field pchSupport:) --> java.beans.PropertyChangeSupport@0x9c1d92a8 (24 bytes) (field listeners:) --> sun.awt.EventListenerAggregate@0x9c1d92c0 (12 bytes) (field listenerList:) --> [Ljava.beans.PropertyChangeListener;@0x9ec391b0 (152 bytes) (Element 5 of [Ljava.beans.PropertyChangeListener;@0x9ec391b0:) --> org.netbeans.modules.project.ui.ProjectsRootNode$ProjectChildren@0x9c254970 (45 bytes) (field array:) --> org.openide.nodes.Children$1@0x9e784d98 (32 bytes) (field referent:) --> org.openide.nodes.ChildrenArray@0x9cba5208 (24 bytes) (field map:) --> java.util.WeakHashMap@0x9cba5220 (44 bytes) (field table:) --> [Ljava.util.WeakHashMap$Entry;@0x9d942cb0 (136 bytes) (Element 4 of [Ljava.util.WeakHashMap$Entry;@0x9d942cb0:) --> java.util.WeakHashMap$Entry@0x9d9430c0 (36 bytes) (field value:) --> java.util.LinkedList@0x9d9430e8 (20 bytes) (field header:) --> java.util.LinkedList$Entry@0x9d943100 (20 bytes) (field previous:) --> java.util.LinkedList$Entry@0x9d943118 (20 bytes) (field element:) --> org.netbeans.modules.project.ui.ProjectsRootNode$BadgingNode@0x9d921258 (61 bytes) (field original:) --> org.netbeans.modules.project.ui.PhysicalView$GroupNode@0x9d920968 (74 bytes) (field project:) --> org.netbeans.modules.apisupport.project.NbModuleProject@0x9d570338 (36 bytes) Note that the root refs seem to be split about 50-50 between two instances of PRN.PC, which I guess means Projects and Files tabs. The refs look normal if the projects were still open - which they were not (and they were not displayed in the Projects tab). From inspecting the heap dump, it seems that the ChildrenArray.map has a 32-slot array of which 11 slots are filled. Bug in children perhaps? I would expect that there would only be one active Children.Info object.
> From inspecting the heap dump, it seems that the ChildrenArray.map has > a 32-slot array of which 11 slots are filled. Bug in children perhaps? Not really. The map is weak and it expects that leftovers will drop off themselves. But in case there is a loop from value to the key (a common bug when dealing qwith WHM), it will not happen. I'll look at this tomorrow, hopefully reproducing it myself, so I could trace the path between the value (in fact the PRN$WN or something else in the list) and its corresponding key.
Only one WHM.E had a non-null referent: org.openide.nodes.Children$Info@0x9cba51f0. The value was an empty list. The other entries had as their values LinkedList's containing one ProjectBadgingNode apiece. I suppose the other entries ought to have been cleared out of the map, but they weren't, even after clicking on the GC button multiple times (which is supposed to also run finalizations).
Sure. I already realized this, just haven't time to add the note here: Another problem with WHM is that even if the keys are freed, the values (and WHM$Es) stick there up to next WHM access (get or mutation) - there is a ReferenceQueue associated with the entries which is checked on every operation but never asynchronously (no thread or finalizer). Opening another project should free the old items, but it is still far from OK.
In this case, maybe Children* is still at fault. I certainly don't see a problem in the project system; it is called setKeys(Collections.emptySet()); there is nothing more it can do. Children.Info.finalize() is supposed to call ChildrenArray.finalizeNodes, which calls remove(null) in an attempt to clear out the entries with collected keys. So why isn't this working?
I think it's worse than that. As far as I can tell, the projects don't get collected at all. I had four NBM projects and a freeform project open. I closed them, waited fifteen seconds, did a GC. I opened an unrelated j2seproject, did a GC, closed it, waited, did a GC, etc. Still, I can see that a number of projects are loaded, including projects that I have not been working on for hours now: $ jmap -histo 15752|egrep 'Project$'|fgrep -v action 1379: 16 640 org.netbeans.modules.apisupport.project.NbModuleProject 1386: 5 640 org.apache.maven.project.MavenProject 2880: 1 80 org.netbeans.modules.java.j2seproject.J2SEProject 4330: 1 24 org.netbeans.modules.ant.freeform.FreeformProject That's 23 nonopen projects loaded! And my standing heap is 123 Mb. Not good. Raising priority since we seem to have a serious and (by me) reproducible leak.
this sounds interesting, but is probably unrelated. 1386: 5 640 org.apache.maven.project.MavenProject this class is not the actual project type in netbeans but the underlying maven object holding the maven project definition. The maven project type class is named NbMavenProject an is missing from your list, so it's being sucessfully GCed. The mistery remains who holds these MavenProject instances and why.
Jesse, I still can't reproduce the problem you describe. There were few related leaks though. uilogger used to keep closed projects in memory from the event descriptor (event was: close those 12 projects, so the references sneaked in). Fixed today. Navigator seems to reference the very first opened file which in turn probably references its project (issue 100122). There were more editor leaks (reported and fixed recently) that might have kept their projects in memory as well. So in which build do you see the problem? Can you reproduce it with newest (tomorrows) build?
BTW: Your observation may be related to issue 100245 (in case you've got VWP instaled).
I do not run VWP.
Can't reproduce today. I filed #100263 for another leak. :-) Then after working around that, I closed all my projects and checked again. This time I still have many projects in memory... but JHAT reports no strong root references. So I am not sure why they are not being collected. BTW the OQL query select heap.livepaths(p) from instanceof org.netbeans.api.project.Project p doesn't seem to work; it seems that instanceof does not work on interfaces??
BTW: you can try Timers/counters, node "Important instances->Project" and "find refs" to find directly from the running IDE.
Reassigning to Radim.
Still reproducible? BTW: there's common misconception of Children.removeNotify, where many people tend to do cleanup of listeners and other things which usually prevent the children nodes from being freed - so removeNotify is never called and the structure leaks wholesale. But that's probably not the case here.
My understanding was that Children.removeNotify should be called when the node has been collapsed for a while, or is no longer displayed at all, even if the Children object is still strongly referenced. Not true? If so, there are going to be a _lot_ of broken Children subclasses out there.
Well, that's actually the case. It seems I'll need to add a big fat warning into the removeNotify() javadoc. removeNotify() is basically good just for cleaning up the key objects (which may be expensive) from memory once the nodes themselves are freed.
I have updated the javadoc of Children.removeNotify to warn about the pitfalls. openide/nodes/src/org/openide/nodes/Children.java,v1.24 Reassigning back.
I don't see how the Javadoc update to Children.removeNotify applies here. ProjectsRootNode.ProjectChildren does not hold explicit references to its created subnodes that I can see. So I still suspect a bug in Children code. But need to check again whether the originally reported problem is reproducible.
Not reproducible for me any more. 1. Start 070927, fresh userdir, JDK 6, Ubuntu. Pass 'openide/util openide/fs openide/nodes openide/loaders openide/modules openide/text openide/windows openide/actions openide/awt openide/dialogs' on command line so they get opened. Accept license, close welcome screen. 2. Wait for CP scanning to finish. 3. File > Project Group > (none) to close all. 4. Wait 30+ seconds, do a full GC. Heap goes from 63 -> 26 Mb. Another GC, -> 21 Mb. Another, still 21 Mb. 5. Get a heap dump using jmap and inspect for NbModuleProject's. None found.