Bugzilla – Full Text Bug Listing
| Summary: | [performance] many transient threads in rapid succession can hang debug UI | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Darin Wright <darin.eclipse> | ||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | caspar_d, christian.campo, ndsilva, pawel.1.piech, stepper | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
I've experimented with a few approaches to the problem: (1) Support in the platform to delay the processing of "add" deltas (say 500ms) in case a corresponding "remove" delta arrives sooner. This way the "add/remove" can be avoided/canceled all together. However, this does not play out entirely well as a refresh might be triggered between the add/remove that causes the "added" elements to appear. In this case, the "removes" were never run, so the removed elements remain in the tree until another refresh. It seems like this could be solved by noting the fact that a refresh has occurred and clearing pending add jobs and run remove requests - however, I was not able to make this play nicely yet. (2) Support in the JDT debug model to supress create/terminate events for transient threads. This is similar to the above approach, but at the model level threads are not revealed unless they live for at least 500ms. This way, the UI never knows about the threads. This works, but is not an ideal solution, as clients of the model do not get true view of model state. (3) Support in the JDT debug model to filter running threads. This is similar to (2), but goes even further to reduce the number of events, elements in the UI. Again, not ideal as the model is hiding its true state (threads) from clients. (4) Not yet tried, but filtering similar to (2) or (3) could be done in the Java debugger's content providers. This way, the model state/API is accurate for all clients, but the platform is shielded from the transient threads. Ideally, a platform solution would be possible to handle problems from any debugger. To date, the debug platform views are designed to keep up with deltas generated by models in real time. Changing to a "only update once every N time units" would be a significant change. Happens on Linux too. It's been like this for over a year. Killing the IDE and the process being debugged from the command line, has become a routine. We also had the problem recently with a lib that creates thousands of threads within minutes that the debugger tilted. At the end it was not only a problem that it couldnt keep but we also couldnt stop the client anymore and the tree view was kind of frozen. Missing tree elements (just blank) in the middle. The IDE still worked ok, just the debugger session and the client hang endless and had to be killed. Is there any plan to fix this ? 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |
Created attachment 172518 [details] Sample project While debugging a performance issue I discovered that a Java program being debugged can saturate the debug view to the point that it just can't keep up. A program that creates many short lived threads in rapid succession (sample attached) will cause the debug view to spin its wheels attempting to add/remove the transient threads, becoming unresponsive. Steps: * Import the sample project * Place a breakpoint in MyClass400, on the sysout * Debug the main class "TestTransientThreads" class Note that sometimes I can't event terminate the program and have to exist Eclipse to regain control. The problem is actually in the debug platform (handling of add/remove deltas), however, one possible fix would be for JDT to hide/filter transient threads from the platform to avoid the issue. With the current view framework, this is likely the simplest solution.