Community
Participate
Working Groups
Deactivating a Mylyn context that has several resources in it should close the associated editors for those resources. However, while the Eclipse UI will remove the editor content, it may leave editor tabs. Reactivating and deactivating the Mylyn context again will close the editors. Reactivating and deactivating the context a third time will re-introduce the editor tabs. A brief story of what's going on: Mylyn calls WorkbenchPage.openEditors() and WorkbenchPage.closeEditors() to open/close these editors. openEditors does not fully realize editors that are not visible. It is these unrealized editors that can remain when the context deactivates. In the process of deactivating the context, after the closeEditors() call, Mylyn calls WorkbenchPage.getEditors() (which is deprecated), which fully realizes all the unrealized editors. Interestingly, a call to getEditorReferences() at the same point in time returns an empty list. Conclusion: WorkbenchPage appears to be holding onto editor references after an unrealized editor is closed. Reproducing: I was able to reproduce this behavior without the 'help' of Mylyn: * Open several windows in a workbench, then restart it. (Restarting the workbench will fully realize only the active editor.) * Close all windows. * Use a custom command to call WorkbenchPage.getEditors(). All windows, except the previously active one reappear!
Fix pushed to Gerrit: https://git.eclipse.org/r/12595
Created attachment 230647 [details] Test Failures with patch set 1 I get 5 test failures in ApiTestSuite, attached: testIDESaveAllEditors(org.eclipse.ui.tests.api.IWorkbenchPageTest) testAddPartListenerToPage(org.eclipse.ui.tests.api.IPartServiceTest) testLocalPartService(org.eclipse.ui.tests.api.IPartServiceTest) testPartHiddenBeforeClosing(org.eclipse.ui.tests.api.IPartServiceTest) testAddPartListenerToWindow(org.eclipse.ui.tests.api.IPartServiceTest)
The fundamental problem is that the IDE is not removing editor references for opened but not fully realized editors when they are closed. This leakage only becomes visible when certain APIs are called, WorkbenchPage.getEditors() being one. Steffen: Are Mylyn users (other than me) seeing this? Can you give me a sense of its priority to you?
(In reply to comment #3) > The fundamental problem is that the IDE is not removing editor references for > opened but not fully realized editors when they are closed. This leakage only > becomes visible when certain APIs are called, WorkbenchPage.getEditors() being > one. That's very interesting. I have noticed that editor management get significantly slower after using the workbench for a longer period of time. I'm not fully understanding the impact of the defect but could this be caused by task activations and deactivations slowly eating up memory or increasing the number of editor references the workbench manages? > Steffen: Are Mylyn users (other than me) seeing this? Can you give me a sense of > its priority to you? We have had a number of reports related to editor restore on e4 but I don't recall anything performance related. This certainly sounds like a problem that would affect Mylyn users using automated editor management (which is the default). Please let us know if we can do anything on our end to help out.
*** Bug 402889 has been marked as a duplicate of this bug. ***
I have not seen this issue, but apparently others have. It would be great for this to be fixed.
Although the root cause of the issue lies in platform UI, a contributing factor is Mylyn's use of the deprecated method IWorkbenchPage.getEditors(). I would be interested in knowing whether Mylyn could use the less expensive IWorkbenchPage.getEditorReferences().
Steffen, do you know there's a reason we use getEditors instead of getEditorReferences? I suspect it's just legacy and we can change that.
From a quick glance I don't see any code in Mylyn 3.9 that invokes getEditors() on the code paths that are executed on Eclipse 4.2 or later. We should be using getEditorState() and openEditors() only in EditorStateParticipant when running on 3.8.2/4.2.2/4.3. Paul, do you happen to have a stack trace for the getEditors() call to analyze further? There is a call in FocusOutlineAction which is probably just legacy and is probably worth cleaning up. Is that call the problem?
Yes, that is where I'm seeing the call. I'm using Mylyn from the Kepler release (3.9.0): Thread [main] (Suspended (breakpoint at line 2262 in WorkbenchPage)) WorkbenchPage.getEditors() line: 2262 FocusOutlineAction.getViewers() line: 87 FocusOutlineAction(AbstractFocusViewAction).valueChanged(IAction, boolean, boolean) line: 297 FocusOutlineAction(AbstractFocusViewAction).update(boolean) line: 275 AbstractFocusViewAction$1.contextChanged(ContextChangeEvent) line: 148 InteractionContextManager$4.run() line: 464 SafeRunner.run(ISafeRunnable) line: 42 InteractionContextManager.deactivateContext(String) line: 454 TaskActivityMonitor$2.taskDeactivated(ITask) line: 80 TaskActivityManager.deactivateTask(ITask) line: 518 TaskListCellModifier.toggleTaskActivation(TreeItem, MouseEvent) line: 128 TaskListView$11.mouseUp(MouseEvent) line: 898 TypedListener.handleEvent(Event) line: 220 EventTable.sendEvent(Event) line: 84 Tree(Widget).sendEvent(Event) line: 1058 Display.runDeferredEvents() line: 4170 Display.readAndDispatch() line: 3759 PartRenderingEngine$9.run() line: 1113 Realm.runWithDefault(Realm, Runnable) line: 332 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 997 E4Workbench.createAndRunUI(MApplicationElement) line: 138 Workbench$5.run() line: 610 Realm.runWithDefault(Realm, Runnable) line: 332 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 567 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 150 IDEApplication.start(IApplicationContext) line: 124 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 109 EclipseAppLauncher.start(Object) line: 80 EclipseStarter.run(Object) line: 372 EclipseStarter.run(String[], Runnable) line: 226 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 88 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 55 Method.invoke(Object, Object...) line: 613 Main.invokeFramework(String[], URL[]) line: 636 Main.basicRun(String[]) line: 591 Main.run(String[]) line: 1450 Main.main(String[]) line: 1426
Thanks for the stack trace. I filed bug 414837 so track changes in Mylyn to avoid usage of getEditors() in FocusOutlineAction.
New (and much simpler) fix and JUnit pushed to Gerrit for review: https://git.eclipse.org/r/17317
Looks good. Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=69fa5ef99e4c20aa47314f505d6385c1afa2b303 PW
Verified fixed in 4.4.0.I20131029-2000
