Community
Participate
Working Groups
Here is what I did: 1) Created a new workspace, containing java project and folder 2) In the filesystem, I added 2500 *.java files (random Eclipse source files) to the folder. 3) Back in the workspace, did refreshLocal on the project - this causes a build - build ends, there are > 50,000 errors (package declarations don't match folder name) - Progress monitor changes to say "Updating" At this point the UI is frozen. The only thing that is responsive is the scroll bar on the tasks view, which is slowly growing as the problems get added. Eventually (after 20 minutes) it stops responding altogether. Dumping the stack (Ctrl+Break in console) yielded the following dump. After awhile, even trying to dump the stack did nothing. I can't tell from looking at the stack if this is really a deadlock, or just a case where the VM died due to some overload. I will try to reproduce. There was an existing PR for limiting the number of tasks in the tasks view, which is probably relevant in this case. Full thread dump Classic VM (J2RE 1.3.0 IBM build cn130-20010502, native threads ): "ModalContext" (TID:0x2411ed0, sys_thread_t:0xb60c798, state:CW, native ID:0 x3ac) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at org.eclipse.ui.internal.Semaphore.acquire(Semaphore.java:20) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:3 4) at org.eclipse.swt.widgets.Display.syncExec(Display.java:1593) at org.eclipse.ui.views.tasklist.TaskListContentProvider.resourceChanged (TaskListContentProvider.java:285) at org.eclipse.core.internal.events.NotificationManager$1.run(Notificati onManager.java:125) at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatfo rm.java(Compiled Code)) at org.eclipse.core.runtime.Platform.run(Platform.java(Compiled Code)) at org.eclipse.core.internal.events.NotificationManager.notify(Notificat ionManager.java:140) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges (NotificationManager.java:43) at org.eclipse.core.internal.events.NotificationManager.broadcastChanges (NotificationManager.java:64) at org.eclipse.core.internal.resources.Workspace.broadcastChanges(Worksp ace.java:110) at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace. java:698) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1189 ) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOp eration.java:78) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(Modal Context.java:98) "Java indexing: org.eclipse.jdt.internal.core.search.indexing.IndexManager" (TID:0xaea848, sys_thread_t:0xb0fb7f0, state:CW, native ID:0x400) prio=5 at java.lang.Thread.sleep(Native Method) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java(Compiled Code)) at java.lang.Thread.run(Thread.java:498) "Finalizer" (TID:0x8e8708, sys_thread_t:0x829298, state:CW, native ID:0x434) prio=8 at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java(Compiled Code )) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java(Compiled Code )) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java(Compiled C ode)) "Reference Handler" (TID:0x8e8750, sys_thread_t:0x8252a0, state:CW, native I D:0x104) prio=10 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:421) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java(Compiled Code)) "Signal dispatcher" (TID:0x8e8798, sys_thread_t:0x823d20, state:R, native ID :0x418) prio=5 "main" (TID:0x8e87e0, sys_thread_t:0x235500, state:R, native ID:0x33c) prio= 5 at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:151) at org.eclipse.core.launcher.Main.run(Main.java:502) at org.eclipse.core.launcher.Main.main(Main.java:362) Monitor pool info: Initial monitor count: 32 Minimum number of free monitors before expansion: 5 Pool will next be expanded by: 36 Current total number of monitors: 72 Current number of free monitors: 66 Monitor Pool Dump (inflated object-monitors): sys_mon_t:0x00234940 infl_mon_t: 0x00234b30: java.lang.ref.Reference$Lock@8EFE58/8EFE60: <unowned> Waiting to be notified: "Reference Handler" (0x8252a0) sys_mon_t:0x00234f38 infl_mon_t: 0x00234b70: java.lang.ref.ReferenceQueue$Lock@8F2A70/8F2A78: <unowned> Waiting to be notified: "Finalizer" (0x829298) sys_mon_t:0x00235218 infl_mon_t: 0x00234e50: org.eclipse.ui.internal.Semaphore@FF5AA8/FF5AB0: <unowned> Waiting to be notified: "ModalContext" (0xb60c798) JVM System Monitor Dump (registered monitors): ACS Heap lock: <unowned> System Heap lock: <unowned> Sleep lock: <unowned> Waiting to be notified: "Java indexing: org.eclipse.jdt.internal.core.search.indexing.IndexM anager" (0xb0fb7f0) Method trace lock: <unowned> UTF8 Cache lock: <unowned> Heap lock: <unowned> Rewrite Code lock: <unowned> Monitor Cache lock: owner "Signal dispatcher" (0x823d20) 1 entry JNI Pinning lock: <unowned> JNI Global Reference lock: <unowned> Classloader lock: <unowned> Linking class lock: <unowned> Binclass lock: <unowned> Monitor Registry lock: owner "Signal dispatcher" (0x823d20) 1 entry Thread queue lock: owner "Signal dispatcher" (0x823d20) 1 entry Thread identifiers (as used in flat monitors): ident 7 "ModalContext" (0xb60c798) ee 0x0b60c5c8 ident 6 "Java indexing: org.eclipse.jdt.internal.core.search.indexing.IndexM anager" (0xb0fb7f0) ee 0x0b0fb620 ident 5 "Finalizer" (0x829298) ee 0x008290c8 ident 4 "Reference Handler" (0x8252a0) ee 0x008250d0 ident 3 "Signal dispatcher" (0x823d20) ee 0x00823b50 ident 2 "main" (0x235500) ee 0x00235330 Java Object Monitor Dump (flat & inflated object-monitors): java.lang.ref.Reference$Lock@8EFE58/8EFE60 locknflags 80000200 Monitor inflated infl_mon 0x00234b30 java.lang.ref.ReferenceQueue$Lock@8F2A70/8F2A78 locknflags 80000400 Monitor inflated infl_mon 0x00234b70 java.text.RuleBasedCollator@DE7778/DE7780 locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1 org.eclipse.swt.widgets.RunnableLock@FF5A90/FF5A98 locknflags 00020000 Flat locked by threadIdent 2. Entrycount 1 org.eclipse.ui.internal.Semaphore@FF5AA8/FF5AB0 locknflags 80001b00 Monitor inflated infl_mon 0x00234e50 org.eclipse.ui.actions.WorkspaceAction$1@1DB29E0/1DB29E8 locknflags 00070000 Flat locked by threadIdent 7. Entrycount 1
Note that the main thread has blown out of the UI event loop! I suspect a VM error such as OutOfMemoryError has broken the event loop and now the app is stuck in some weird state... main thread is unwinding due to an uncaught exception being thrown, but is somehow waiting on other threads before it can die?
I suspect the stack trace from my earlier comment is somehow incomplete. I've run the test case for an hour from a self hosting workspace, and it was still running the Viewer update code after that hour. Below is a typical stack trace during that period. After an hour, it had successfully inserted 9,215 of 67,763 errors! I suspect inefficiencies in the JFace update code aren't helping (for example it should grow the HashMap once rather than have it regrow lazily after each insertion). I think the real issue here is that there should be a limit on the number of entries that can be added to the Tasks view. This is severe! Thread [main] (Suspended) HashMap.rehash() line: 292 HashMap.put(Object, Object) line: 351 TableViewer(StructuredViewer).mapElement(Object, Widget) line: 490 TableViewer(StructuredViewer).associate(Object, Item) line: 149 TableViewer.doUpdateItem(Widget, Object, boolean) line: 157 TableViewer(StructuredViewer).updateItem(Widget, Object) line: 887 TableViewer.add(Object[]) line: 99 TaskListContentProvider.updateViewer(List, List, List) line: 311 TaskListContentProvider$1.run() line: 287 UIWorkspaceLock.doPendingWork() line: 53 UISynchronizer$1.run() line: 23 RunnableLock.run() line: 29 UISynchronizer(Synchronizer).runAsyncMessages() line: 93 Display.runAsyncMessages() line: 1342 Display.readAndDispatch() line: 1170 ModalContext$ModalContextThread.block() line: 133 ModalContext.run(IRunnableWithProgress, boolean, IProgressMonitor, Display) line: 258 ProgressMonitorDialog.run(boolean, boolean, IRunnableWithProgress) line: 335 BuildAction(WorkspaceAction).run() line: 271 BuildAction.run() line: 154 BuildAction(Action).runWithEvent(Event) line: 453 ActionContributionItem.handleWidgetSelection(Event) line: 407 ActionContributionItem.handleWidgetEvent(Event) line: 361 ActionContributionItem.access$0(ActionContributionItem, Event) line: 352 ActionContributionItem$ActionListener.handleEvent(Event) line: 47 EventTable.sendEvent(Event) line: 54 MenuItem(Widget).notifyListeners(int, Event) line: 635 Display.runDeferredEvents() line: 1365 Display.readAndDispatch() line: 1167 Workbench.runEventLoop() line: 727 Workbench.run(Object) line: 710 InternalBootLoader.run(String, URL, String, String[]) line: 820 BootLoader.run(String, URL, String, String[]) line: 285 Method.invoke(Object, Object[]) UIMain(Main).basicRun(String[]) line: 151 UIMain(Main).run(String[]) line: 502 UIMain.main(String[]) line: 52
We are changing this to simply show a message when the number of items exceeds a limit (2000), configurable on the task list filters dialog. No items will be shown in this case. The message will recommend adjusting the filtering options to reduce the number of shown items.
fixed in f1. tasks filter dialog has ui to limit total number of tasks to 2000, and this filter is on by default. other similar bugs to this seem to isolate SWT table as the cause of the delay under large load. as our viewer framework does not support the notion of managing a table's model via lazy population, there does not seem to be an easy way to better solve this problem for 2.0 release other than this fix.
