Community
Participate
Working Groups
After running Cocoa for awhile I get a lot of pinwheels (beach balls) when switching focus between editors, views and perspectives. In fact, eventually it becomes so bad that I have to restart Eclipse. The heap monitor indicates that I've got a good 800MB+ free on my heap (I run with a big heap) and my machine is not swapping (other apps remain responsive). After restarting Eclipse the pinwheels go away. this bug created from bug 277939 comment #9
David, can you get a Java Thread dump while the app is busy, or maybe run 'Spin Control.app' to get us some samples of what's happening? Does this with a vanilla SDK? 32 and 64 bit? Sorry about all the questions, I think I'm going to need some help reproducing this one.
Created attachment 148168 [details] stack trace samples taken using jconsole I've managed to reproduce the issue. Unfortunately mac's SpinControl app is producing empty samples. Instead I connected using jconsole and took multiple stack trace samples, and pasted them into this attachment.
Created attachment 148170 [details] stack sample from clicking on editor tab previous samples were from switching perspectives. This one is achieved in the current perspective by clicking on the tab of an editor that is not the current one (ie: it's obscured by another editor)
Created attachment 148171 [details] another switching-editor sample
The samples seem pretty representative... every time I take a stack sample it seems that org.eclipse.swt.widgets.Composite.invalidateChildrenVisibleRegion(Composite.java:467) is at the top (bottom?) of the stack.
Forgot to add version/environment info: Version: 3.6.0 Build id: N20090912-2000 Also have numerous other plug-ins installed: WTP, Java EE tools, Mylyn, Subclipse
Using Apple's Java 1.6.0_15 64bit
Are you seeing the colorful apple beachball (http://en.wikipedia.org/wiki/Spinning_wait_cursor) or Eclipse's black and white busy cursor?
(In reply to comment #8) > Are you seeing the colorful apple beachball Yes, the colorful one.
All the stack traces show swt being at Composite.invalidateChildrenVisibleRegion line 466. That doesn't make a lot of sense to me. I'd expect to see the resetVisibleRegion call in the stack, but even then unless there's a paint happening, the code should be fast since we're just disposing a region.
Next time it gets slow, can you try opening a new window, and closing your original window. This will dispose all the widgets in the original window and free some memory. I'd be interested to know if this fixes or improves the slowness.
Released a fix to bug 291382 for tonight's integration build. Please give that build a try when it's available and let me know if there is any improvement here.
I had to pull the changes out before the build. Not having a window buffer was causing trouble for GC. Disregard comment 12.
(In reply to comment #11) > Next time it gets slow, can you try opening a new window, and closing your > original window. I did this and it makes no difference. (In reply to comment #13) > I had to pull the changes out before the build. Not having a window buffer was > causing trouble for GC. Disregard comment 12. Too bad! In general, the Eclipse UI gets slower and slower as the day progresses. I have to restart a couple or more times a day.
Please try I20091020-0931 and let me know if there's any improvement here. We've done some work to reduce memory usage of CCombo, reduce the number NSStrings in our NSAutoreleasePools, and some improvements to improve scrolling in editors. I'm not expecting this bug to be FIXED, but maybe there has been some improvements.
I've been using it all morning. So far so good. We may not be out of the woods yet. I tend to see this issue more when debugging enterprise apps using WTP, which I haven't been doing so much of today. Thanks very much for your efforts so far. I'll keep you updated on how it goes.
Does Mylyn use TextLayout anywhere?
Yes, I believe so (indirectly via StyledText).
I'm not sure if this is related -- I've noticed that the beachball issue almost always coincides with bug 288155. bug 288155 is a duplicate of bug 279479, however I've attached a screenshot to bug 288155 which shows a dialog that gets filled with hundreds of error messages. Could it be that the dialog is causing this havoc?
The stack trace in bug 288155 is kind of interesting. The exception there is happing in Display.timerProc. If that happens, the timer doesn't get invalidated or released and the timer will keep running. Maybe we should consider moving invalidate and release calls into a finally block to ensure that they always happen and timers aren't leaked.
released code to move the invalidate/release code into a finally.
(In reply to comment #21) > released code to move the invalidate/release code into a finally. Which I-build should I be looking for?
I20091204-0800 (or later when available)
I know it's a long shot, but have there been any improvements recently?
I've been running I20091204-0800 since it became available and I know that I've seen this issue more than once, though it's hard to say if it's occurring as frequently. Unfortunately my work pattern has changed for the past couple of weeks and I haven't been doing the same kind of activities that I'm normally doing when I experience the issue.
Thanks David. I think it's safe to say this one's not fixed. (I had my fingers crossed though)
David, any chance you are using SWT Designer from Instantiations? I'm also seeing the beachball when switching perspectives / views / editors, and it appears to be related to using SWT Designer.
Bryan, do you know what Designer is doing? Is there a particular swt call that we could improve to make the problem go away?
(In reply to comment #27) > David, any chance you are using SWT Designer from Instantiations? No, I'm not using SWT Designer.
Created attachment 158355 [details] Stack trace during Eclipse beach ball I'm running self-hosted in debug mode today, and managed to pull down this stack trace of Thread-0 during a beach ball moment. The one thing that strikes me is that the GCData array that the resetVisible() method iterates through is currently large enough to hold over 300,000 items, even though most of the slots are null. It looks like this array always grows to accommodate new GCData, but never shrinks when data is disposed. Could this mega-array be the source of the slowness & beach balling some of us are seeing? It seems the array is probably growing larger than anticipated. Like David, I also run the Web Tools & Java EE stack, Mylyn, and also Subversive and GEF amongst others.
Created attachment 158366 [details] patch to display & control Here's a proof of concept patch that changes the contexts array in Display to be a set. So far my workbench feels a bit snappier running with the patch, but I've only stress tested it a couple of hours.
Well that large array isn't going to help. We null out the contexts array when the last GC gets disposed. This means that if someone creates a GC and keeps it around (or leaks it), the array grows forever. I proved this by creating a plugin that creates a GC on a Control and doesn't dispose it.
Display.addContext had an "&&" that should have been an "||". This meant that the null entries in the array were never used, but the array would instead grow by 12 for every context added. I fixed this in HEAD and I'm not seeing the array grow out of control using that code. I'm not going to close this bug yet. Lets see what kind of gains we get from this change first. Leo - Thanks for the patch!
I looked at add context again this morning. The test should be >> if (contexts[i] == null || contexts [i] == context) fixed code in head
Awesome Kevin! I'm running your fix now.
Kevin, I realize this is cutting things pretty close, but is there any chance this fix is a candidate for 3.5.2? Looks like a pretty simple change for a potentially pretty big upswing.
I think it's too late for 3.5.2 now. We're already past the last test pass. Only real show stoppers can go in at this point. The RC4 rules state that we expect no changes at this point. http://www.eclipse.org/eclipse/development/plans/freeze_plan_3_5_2.php
Makes sense, thought I'd check anyway.
I20100209-2300 has the latest fix.
So far so good!
One week later: Performance has improved greatly & pinwheeling is gone. Kevin, your fix has really made a difference!
That's great news. I'm going to mark this bug fixed. Thanks for the patch Leo, and the testing and patience everyone else! fixed > 20100209
*** Bug 291769 has been marked as a duplicate of this bug. ***
*** Bug 297246 has been marked as a duplicate of this bug. ***
*** Bug 303941 has been marked as a duplicate of this bug. ***
