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.
Mem l. occurred after fanatic clicking on Object Browser's middle pane toolbar button "Class" or "Interface". Problematic class: 14403 instances of class org.openide.explorer.view.NodeRenderer$List Kept by: org.openide.explorer.view.ListView$NbList@0x906e570a (368 bytes) : field component => Instance of [Ljava.awt.Component;@0x888c570a (16 bytes) : Element 0 of Instance of [Ljava.awt.Component; => javax.swing.CellRendererPane@0xb894590a (216 bytes) : field component => Instance of [Ljava.awt.Component;@0x6018b00a (65536 bytes) : Element 8555 of Instance of [Ljava.awt.Component; => org.openide.explorer.view.NodeRenderer$List@0x680ffb0b (364 bytes) So, we must somehow "refresh" CellRendererPane.
Automated change of version from Other to Dev.
Apparently, we have a bug in VisualizerNode/NodeRenderer.List. We create one VisNode for a Node. We create one Renderer.List for one VisNode. Thus we have one renderer for one Node in ListView but we should have one renderer for whole ListView.
Version: 'Dev' -> 3.2
Target milestone -> 3.3
Could you check this if you have time? Thanks. If you won't please return back.
Target milestone -> 3.3.1.
There is still a huge memory leak. Try finding a file containing text "a" and then cycle back and forth between two files found in search results dialog. I'm not sure if the problem is in swing or really in our ListView implementation, but we shouldn't use 1 item <=> 1 renderer relation anyway, as creating a renderable component is about 10-50 times slower that setting up existing component. I'll investigate it more. I tried walking the references but my OptimizeIt died so I ahev to start from beginning :-( Raising priority.
One side of the problem is the implementation of the JList's UI, which adds all the rendering components used during paint to an intermediate component (javax.swing.CellRendererPane), but never removes them (while e.g. JTree's UI does removeAll at the end of paint()). This together with reusal of a ListView for changing model and with having ListView in a singleton TC causes the leak. The other side is the usage of 1 Node <=> 1 rendering component, which is resource wastefull and also significantly slower on the first paint, see newly added benchmark in performance/test/perf/src/javax/swing/ListCellTest.java which shows that allocating new JLabel and setting if fully up is about 30 times slower than taking existing JLabel and setting it fully up. => For first 20-30 paint requests, the shared component is faster. As Ales already noted, we should use shared rendering component which will significatly reduce the impact of the leak to the level of non-issue.
It seems I have workable solution for this. I'll polish it a bit and put it in (hopefully) tomorrow.
Checked in: /cvs/openide/src/org/openide/explorer/view/ListView.java,v1.47.6.2 /cvs/openide/src/org/openide/explorer/view/NodeRenderer.java,v1.13.14.1 /cvs/openide/src/org/openide/explorer/view/TreeTableView.java,v1.7.14.1 /cvs/openide/src/org/openide/explorer/view/TreeView.java,v1.76.2.4 /cvs/openide/src/org/openide/explorer/view/TreeViewCellEditor.java,v1.28.14.1 /cvs/openide/src/org/openide/explorer/view/VisualizerNode.java,v1.19.2.1 Most of the above files were only little changes to accept the modified package-private API
While pasting CVS log, forget to mark it fixed :-(
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.