Community
Participate
Working Groups
I upgraded from 3.5 to 3.7. It seems as though the UI locks up consistently after saving files, which was not as common and/or not as lengthy. It's a severe usability issue when trying to iterate through a large number of files in a large project. I did a few thread dumps to determine what could be hanging and it appears that (at least the current issue) might be related to populating the breadcrumb. Is it possible to put that in a background thread? That might avoid blocking the UI on building the current project. Here's the pertinent part of the thread's stack; above this point is just digging into the compilation routine. I'm attaching the entire 5 thread dumps to this bug report, however. at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.notifyParticipants(ReconcileWorkingCopyOperation.java:244) at org.eclipse.jdt.internal.core.ReconcileWorkingCopyOperation.executeOperation(ReconcileWorkingCopyOperation.java:94) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:728) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:788) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1244) at org.eclipse.jdt.internal.core.CompilationUnit.reconcile(CompilationUnit.java:1205) at org.eclipse.jdt.internal.corext.util.JavaModelUtil.reconcile(JavaModelUtil.java:571) at org.eclipse.jdt.internal.ui.actions.SelectionConverter.getElementAtOffset(SelectionConverter.java:283) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditorBreadcrumb.getCurrentInput(JavaEditorBreadcrumb.java:810) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditorBreadcrumb.setInput(JavaEditorBreadcrumb.java:781) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.setBreadcrumbInput(JavaEditor.java:2007) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor.selectionChanged(JavaEditor.java:2271) at org.eclipse.jdt.internal.ui.javaeditor.JavaEditor$EditorSelectionChangedListener.selectionChanged(JavaEditor.java:300) at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2749) at org.eclipse.jface.text.TextViewer.firePostSelectionChanged(TextViewer.java:2697) at org.eclipse.jface.text.TextViewer$5.run(TextViewer.java:2676) at org.eclipse.swt.widgets.Display.timerProc(Display.java:4154) -- Configuration Details -- Product: Eclipse SDK 3.7.1.v201109091335 (org.eclipse.sdk.ide) Installed Features: org.eclipse.jdt 3.7.1.r371_v20110810-0800-7z8gFcoFMLfTabvKsR5Qm9rBGEBK
Created attachment 204553 [details] Stack trace This was taken while the UI was locked up using the following bash script: for ((i=0; i < 5; ++i)); do jstack 28843 >> ~/eclipse_bug.txt; done (where 28843 is my Eclipse process). The thread that has the action is the 'main' thread.
Seems like several threads are inside Google's compilation participant, all trying to collectTypes().
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
