debug tree is slow with lots of thread creation #351
Comments
|
This appears to be the same thing as this issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=552328 However, adding the system properties mentioned there: does not help my situation. Taking a heap dump of the running process, I see I have 164 megabytes worth of TreeModelContentProvider$DelayedDoModelChangedJob. Sampling some more stack traces, I see lots of: which leads me to think that someone implemented some kind of "preserve the selection when updating the tree" in JFace, which is leading to a dramatic slowdown in processing tree updates. Looking at this, it seems to me that |
|
This bug is most likely caused by eclipse-platform/eclipse.platform@485d054 |
Only proceed maximum 100 model changes of the Debug view in one batch and then give other UI tasks a chance to proceed in between. This should avoid long UI freezes while updating the JFace tree in case debuggee application generates many model changes that need to be processed in the Debug view Change-Id: I0a9ef6764e41f88ace3bae57ed40adaad9a8c368 Signed-off-by: Joerg Kubitz <[email protected]> Reviewed-on: https://git.eclipse.org/r/c/platform/eclipse.platform.debug/+/186381 Tested-by: Platform Bot <[email protected]> Reviewed-by: Andrey Loskutov <[email protected]>
Why do you think so? Without that change UI will be not slow but simply frozen. |
Previously the tree would have processed very large batches at a time, only calling the very slow getSelection() once per batch. Now the batches are much much smaller, meaning the tree calls getSelection() very often, and getSelection() is very slow. |
|
Please note that I mean no disrespect, and I may well be wrong here - I am a long-time Java developer and Eclipse user, but I am making educated guesses based on what I see in the Eclipse code. |
Can you provide full stack trace that shows this method called from the debugger code? The issue description only shows some incomplete stack trace. Also if you could provide an example project that shows the issue, it would be much easier to discuss about possible root cause & solution. |
|
The full stack trace looks like the below. "main" #1 [3984] prio=6 os_prio=0 cpu=116000.00ms elapsed=386.28s tid=0x000001cfd6621be0 nid=3984 runnable [0x00000076d64fd000] |
|
Attaching leak report from the heap dump I took while Eclipse was chewing away on the queue of jobs (after I had already quite the applications I was debugging) |
We have limited resources. If the problem is important to you, maybe you can try to provide an example project "inspired" by your application, that can demonstrate the issue. I see that the stack doesn't match current master. Which Eclipse version do you use? |
|
So I tried to create a replica project to demonstrate the problem. So it must be something weird about my application that is triggering the debug code (either in the VM or in Eclipse) to generate large numbers of events. Unfortunately this is a very old and large application with lots of moving parts, so tricky to isolate the problem area. But I have used the eclipse heap dump to examine one of the events (see screenshot below). Does this mean anything to you? For example I see that the event is called "JDI thread evaluations" ?
|
Not really. |
|
So I have a simple reproducer project, which confirms a thought I had last night, that something in my codebase is creating a very large number of short-lived threads. |
|
Run the reproducer for 10 or 20 seconds (with the JDT debug view open), then close the sample window. The debug tree will keep processing for 30 seconds or more after the application is closed. |
|
Hmmm, my bug looks exactly like this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=573810 And similar to that one, it looks like all the high-velocity threads in my debugger view are GC threads, they don't seem to be coming from my application (I checked this by comparing that I see in eclipse to what I see when running the jstack command) But I have "Show System Threads" turned off, so it seems to me that the problem is that Eclipse is not filtering out the GC threads properly. |
|
Removed needinfo, as the reproducer project is given in #351 (comment) |
Any code pointers as to where the events originate? From my initial debugging it looks like the filtering needs to be pushed to the source, we cannot rely on improving the processing of events, we need to prevent the source from generating the events. |
|
I do not remember, but you could put a breakpoint in the Constructor of the Event classes created, probably somewhere here: |
I have a couple of apps that are rather thread-heavy, as in 10s of threads and threads being created/removed every second or so.
The tree in the debug view gets reallllly slow, and even when the programs terminate, I can see that Eclipse is still busy updating the tree view in the debugger for several minutes after.
Is this a known issue? Any workarounds?
Sample stack trace of where Eclipse is getting stuck:
"main" #1 [10932] prio=6 os_prio=0 cpu=1671875.00ms elapsed=3480.47s tid=0x00000289dea3efc0 nid=10932 runnable [0x000000d218efd000]
java.lang.Thread.State: RUNNABLE
at org.eclipse.swt.internal.win32.OS.CallWindowProc(Native Method)
at org.eclipse.swt.widgets.Tree.callWindowProc(Tree.java:1576)
at org.eclipse.swt.widgets.Control.windowProc(Control.java:4845)
at org.eclipse.swt.widgets.Tree.windowProc(Tree.java:6142)
at org.eclipse.swt.widgets.Display.windowProc(Display.java:5040)
at org.eclipse.swt.internal.win32.OS.SendMessage(Native Method)
at org.eclipse.swt.widgets.Tree.findItem(Tree.java:2909)
at org.eclipse.swt.widgets.TreeItem.getItem(TreeItem.java:720)
at org.eclipse.jface.viewers.TreeViewer.replace(TreeViewer.java:469)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.handleAdd(TreeModelContentProvider.java:1358)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1276)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1312)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1312)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateNodes(TreeModelContentProvider.java:1312)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.updateModel(TreeModelContentProvider.java:576)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider.doModelChanged(TreeModelContentProvider.java:543)
at org.eclipse.debug.internal.ui.viewers.model.TreeModelContentProvider$DelayedDoModelChangedJob.runInUIThread(TreeModelContentProvider.java:449)
at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:148)
at org.eclipse.ui.progress.UIJob$$Lambda/0x0000028981aa2438.run(Unknown Source)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:132)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4047)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3663)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1155)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:342)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1046)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:645)
at org.eclipse.ui.internal.Workbench$$Lambda/0x00000289811ffa88.run(Unknown Source)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:342)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:552)
The text was updated successfully, but these errors were encountered: