Community
Participate
Working Groups
I am using the Git Staging View to see this problem. I have one unstaged file in my repository. Right-click on the changed file to view the pop-up menu. In debug I have a breakpoint in BindingManager.addBindingManagerListener(IBindingManagerListener). 2 of those listeners are added for 2 different CommandContributionItems every time I view that pop-up menu. Those listeners are never removed. The listeners are notified when an editor is opened, closed, and many other window actions. You can see that with a breakpoint in BindingManager.fireBindingManagerChanged(BindingManagerEvent). The list of listeners just keeps growing. Closing the view or perspective does not remove the listeners. This looks like one major reason that my performance degrades over time (bug 385272). Sorry if this is a duplicate, it seems different than the recent ones Dani has entered (bug 389250 bug 389257).
My JVisualVM snapshots posted in bug 385272 show this problem, but they don't include profiling of classes in org.eclipse.jface.*. Thus you can't search for the BindingManager classes. But you can still see that CommandContributionItem.update() is called about 100,000 times when closing 30 editors. update() is the method called by IBindingManagerListener.bindingManagerChanged
While at it I made a full platform code search for addBindingManagerListener and removeBindingManagerListener. The delta shows that there is a call to add with no apparent removal and is made in org.eclipse.ui.internal.Workbench.initializeDefaultServices() I am not familiar with the code here and suspect it is because it is some init code but still I think some clean up may be needed as it is done for other listeners registered in the same method.
Failing to remove a listener is a very easy programming mistake that seems to be resolveable only by diligent code review or platform profiling. With many Eclipse projects in the Simultaneous release and some of them in Incubation, it seems inevitable that many will duplicate this bug. Third party plugins will make the situation worse. As a result of NPEs, I have reported and queried unexpected command/menu listening against at least EMF Facet and Papyrus. Is there any way for the platform to protect itself against this? Perhaps an easy to access dump of all the non-platform imposed drains on platform resources and a SimRel requirement for projects to list their expected drains.
Created attachment 221201 [details] Possible patch Paul, could you check the proposed patch?
Created attachment 221303 [details] Additional patch for "Show view" The "Show view" menu itself is also leaking CommandContributionItem's and related element. Every time the menu is about to be displayed, the list of available views gets reconstructed. The list is associated with a menu manager that never gets released. The proposed patch remembers the menu manager and releases its elements before a new menu manager is created. The patch is a "minimal change" approach. I don't think we really need to recreate the menu manager every time, but I tried to keep changes to the minimum to avoid side effects.
(In reply to comment #4) > Created attachment 221201 [details] > Possible patch I would suggest putting the disconnectReferences() in the widget dispose call as well. It's possible to dispose the widget and the have its fill(*) method called again without disposing the ICI or disconnecting it from its parent contribution manager. (In reply to comment #5) > Created attachment 221303 [details] > Additional patch for "Show view" This looks good. PW
(In reply to comment #6) > I would suggest putting the disconnectReferences() in the widget dispose > call as well. Great idea, done! Change released into R4_2_maintenance: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=c50d62e0e5dbd753e6560440392780b7fdcd6707
I have done some testing with this patch. While it appears that the steady leaking is gone, I am still seeing odd behavior with CommandContributionItems. I added a println to CommandContributionItem.update(String) System.out.println(getClass().getName() + "(id=" + getId() + ", objectid=" + Integer.toHexString(hashCode()) + ")"); When I first start eclipse with a Java perspective I can open and close Java editors, switch between Java/Git perspective, switch between Java editors all without seeing any calls to CommandContributionItem.update. (Other than initially building the workspace). Now if I open the 'Window -> Show view' menu I see calls to that update. Now every time I do any of the above actions I see multiple calls to update. So if I open a java editor I see the following updates called 12 times! Even something like opening the workspace preferences causes these same updates to be called 18 times! org.eclipse.ui.menus.CommandContributionItem(id=org.eclipse.ant.ui.views.AntView, objectid=1f95fc4) org.eclipse.ui.menus.CommandContributionItem(id=org.eclipse.ui.views.ResourceNavigator, objectid=1e82e1b) org.eclipse.ui.menus.CommandContributionItem(id=org.eclipse.ui.views.ProgressView, objectid=2eab5b) org.eclipse.ui.menus.CommandContributionItem(id=org.eclipse.ui.navigator.ProjectExplorer, objectid=f3a6e) org.eclipse.ui.menus.CommandContributionItem(id=org.eclipse.ui.views.TaskList, objectid=1e154b9) org.eclipse.ui.menus.CommandContributionItem(id=org.eclipse.ui.texteditor.TemplatesView, objectid=602764) Then using the Git perspective really multiplies the problem because so many of their menu items are CommandContributionItems. It just doesn't seem to me that these should need to be updated so many times. Or even updated at all in the above scenarios? Have I found a different bug?
I've opened Bug 390379 to investigate that. PW
Thanks Paul, once there is an i-build after SR1 goes out I will test this fix in my every day development.
Paul, Oleg, things seems *much* better now that I am using a 4.2.2 build for my development. So far I am not seeing the gradual performance degradation! I am still seeing some room for improvement. I just entered bug 391270 which suggests how to go further with the fix you did here.
*** Bug 377119 has been marked as a duplicate of this bug. ***
in M20130116-1800 PW
