Bugzilla – Full Text Bug Listing
| Summary: | [Widgets] \eclipse hangs for ~15 seconds when opening a new file | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Koski <david_koski> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cocoakevin, danny.mandel, david_koski, Mike_Wilson, mschrag, ray |
| Version: | 3.5 | Keywords: | triaged |
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | stalebug | ||
| Attachments: | |||
Is this reproducible? As I said, I can reproduce it within a few minutes of use by opening files on multiple computers (though with similar eclipse setups). Folks I work with have seen strange pauses as well. I don't know if other people can reproduce this or not. how large are the files you're opening? Are there any really long lines? (In reply to comment #3) > how large are the files you're opening? Are there any really long lines? I just opened a file that is 29 lines long and saw this huge pause & beachball cursor. The longest line is 124 characters. Is there some other data I can give you to track this down? I wouldn't say I can make it happen at will, but it happens on at least 25% of the files I open. We need a reproducible test case. (In reply to comment #5) > We need a reproducible test case. So that isn't too likely -- I (as I suspect most of eclipse users) am a user of eclipse, not a developer of eclipse. I am a *developer* and I can attach to it in a debugger or run profiling tools, or whatever, but I would have no idea how to produce a test case that reproduces this. I would expect the developers of eclipse to do that. Anyway, I can reproduce this pretty easily and if you want me to do something to give you more info, let me know. I've seen similar slowness, but it appears to be related to the number of files I have open. If I have 6 or less editors open, it is generally ok but once I get above 8 then there is a REALLY big performance hit. If I close all of the editors and reopen them this appears to return things to normal. Created attachment 146683 [details]
another output from sample showing a slightly different set of work
Here is another output from sample -- I think this may be the more typical case from looking at a lot of sample output:
5274 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__II
5274 -[NSAutoreleasePool release]
5274 NSPopAutoreleasePool
5274 _CFAutoreleasePoolPop
5271 CFRelease
5260 -[NSAttributeDictionaryEnumerator dealloc]
5221 -[NSAttributeDictionary release]
5221 -[NSConcreteHashTable removeItem:]
5207 -[NSConcreteHashTable rehashAround:]
5195 hashProbe
2073 attributeDictionaryIsEqual
1139 -[NSAttributeDictionary isEqualToDictionary:]
There are either a lot of these NSAttributeDictionary and their enumerators or it is an expensive process to get rid of them.
Per various mailing lists, this is private to the AppKit framework, so the trick is finding out what use SWT makes of it (indirectly).
Maybe if we reproduce your environment we'll be able to replicate your problem. What build of Eclipse are you using? What (if any) additional plugins have you installed? What type of files are you opening? (In reply to comment #9) > Maybe if we reproduce your environment we'll be able to replicate your problem. > What build of Eclipse are you using? What (if any) additional plugins have you > installed? What type of files are you opening? Build id: 20090619-0625 specifically this packaging of it: http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/galileo/R/eclipse-java-galileo-macosx-cocoa.tar.gz I am running Mac OSX 10.6, Build 10A433 (though I saw this on Leopard (10.5) as well). This is opening java files (small and medium size for the most part). I am trying a clean version of eclipse with no additional plugins. I have 47 java projects with a total of 3782 java source files, about 120k lines of text. I run with: -XX:MaxPermSize=256m -Xms256m -Xmx768m I was able to maybe reproduce it with this setup (see attached sample output). I just open files until I had around 30 open. Opening a new file would take 10+ seconds. If I set General -> Editors -> Close Editors automatically to 8, it seems snappier (and I have this ON with my normal eclipse install). I could open files and though it did seem to get slower, it never reached the pain threshold (the first couple files I opened were super fast, slight pause later). I tried installing one of my plugins: WOLips, WOLips Base, WOLips Third Party Feature, version 3.4.5950 from: http://webobjects.mdimension.com/wolips/nightly info: http://wiki.objectstyle.org/confluence/display/WOL/Install+WOLips+with+Eclipse+Update+Manager Even with the "close editors = 8" it still slowed down after opening half a dozen different files. Created attachment 146698 [details]
another sample output showing very slow opening of java editors with a clean install of eclipse
Attaching the sample output from a clean install of eclipse. It doesn't look quite the same as the other sample, though it is still doing work with NSAttributeDictionary (and NSAttributedStrings).
I run eclipse without changing any of the default arguments and haven't had this problem. Where are you setting -XX:MaxPermSize=256m, -Xms256m, -Xmx768m? By the way MaxPermSize is set to 256M by default in the eclipse.ini file. I suspect WOLips is the problem here as no one else has reported this bug to us. The native sampling isn't really providing useful information. I'd be more interested in what the java thread dumps (kill -3 pid) look like during the slowness. Can you provide that information? Have you filed a bug against the WOLips developers? (In reply to comment #12) > I run eclipse without changing any of the default arguments and haven't had > this problem. Where are you setting -XX:MaxPermSize=256m, -Xms256m, -Xmx768m? > > By the way MaxPermSize is set to 256M by default in the eclipse.ini file. Yes, in eclipse.ini. As I mentioned I run a fresh download of eclipse and can reproduce this after opening around 30 editors. Created attachment 147110 [details]
thread dump of eclipse during the long pause
(In reply to comment #13) > I suspect WOLips is the problem here as no one else has reported this bug to > us. The native sampling isn't really providing useful information. I'd be more > interested in what the java thread dumps (kill -3 pid) look like during the > slowness. Can you provide that information? > Have you filed a bug against the WOLips developers? I attached a thread dump. The common activity in every case was this: "main" prio=6 tid=0x0e000c00 nid=0xa0b13500 runnable [0xbfffe000] java.lang.Thread.State: RUNNABLE at org.eclipse.swt.internal.cocoa.OS.objc_msgSend(Native Method) at org.eclipse.swt.internal.cocoa.NSObject.release(NSObject.java:120) at org.eclipse.swt.widgets.Display.removePool(Display.java:3390) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3104) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) which exactly matches with the objc samples -- it is releasing an objc object and that is super expensive. As I noted previously I can make this happen with a bare eclipse (it seems -- I can't be 100% sure it is the same bug, but it gets very slow). Yes it might be something WOLips is triggering -- it certainly seems to happen faster. Also, this is the same plugin I was using with eclipse 3.4 which had none of these problems. We're releasing an NSAutoreleasePool. This is a normal part of event processing. I cannot reproduce this bug. I have over 50 editors open right now, and opening a new one is almost instantaneous. I'm also running on old (slow) hardware. please attach your ini file and I'll try running with your ini file. (In reply to comment #17) > We're releasing an NSAutoreleasePool. This is a normal part of event > processing. > I cannot reproduce this bug. I have over 50 editors open right now, and opening > a new one is almost instantaneous. I'm also running on old (slow) hardware. > > please attach your ini file and I'll try running with your ini file. I have an 8 core MacPro with 6G of RAM, so it should not be the HW. I cannot reproduce with the carbon version, so it is something specific to Cocoa. Here is my ini file -- I think it is stock except for the Xms: -startup ../../../plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar --launcher.library ../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.0.0.v20090519 -product org.eclipse.epp.package.java.product -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m -vmargs -Dosgi.requiredJavaVersion=1.5 -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -XX:MaxPermSize=256m -Xms768m -Xmx768m -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts This might be related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229 That kind of furious activity in the text view might be responsible for putting so much stuff in the autorelease pool (or in the NSAttributeDictionary which gets released). I cannot reproduce this one. I have tried the same build with the same ini, getting 40+ projects in my workspace, opening 80 editors. The next editor opens fast for me. http://craigjolicoeur.com/blog/disable-spindump-on-os-x-to-prevent-system-slowdowns I have noticed that when eclipse DOES spin, spindump on Leopard/Snow Leopard makes this situation WAY worse -- burning a huge amount of ram and CPU to record information about the hang. This isn't the solution to the underlying problem, but it makes it substantially much less annoying. incidentally, when i do get a spin, i see the same thing David sees -- it seems to always be releasing an autorelease pool. i wonder if eclipse is churning an unusually large numbers of objects ... *** Bug 290082 has been marked as a duplicate of this bug. *** Could somebody attach a small WOLips project? Created attachment 149528 [details] example WOLips project The WOLips 3.5 install site is http://webobjects.mdimension.com/hudson/job/WOLipsEclipse35/lastSuccessfulBuild/artifact/site . You can get away with just installing the "standard" plugins, though without actually having WebObjects installed (which doesn't deploy as part of this), you'll get a heap of build errors. If you really want to go all the way with it, let me know -- it's really only downloading one more thing and setting up a properties file. When an NSAutoreleasePool accumulates a lot of garbage in it, it can take some time to release the pool. Some of this is beyond our control because Cocoa uses the pools as well. Where possible I've changed our code to explicitly release objects instead of putting them into the pools. A small change was also made for bug 290449 that might be related to this bug. That change is in I20100209-2300. If you notice any improvement, could you please update this bug. Bug triaged, visit https://wiki.eclipse.org/SWT/Devel/Triage for more information. 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 143025 [details] output of sample while switching files Build ID: 20090619-0625 Steps To Reproduce: When running eclipse on a Mac, start opening java files. I use F3 (open definition), cmd-T (open type). After a while some of the files will take 15 seconds to open with the cpu running flat-out on one core. Other folks I work with have reported similar behavior, perhaps when many files are open. More information: I will try and attach the full sample file, but here is a snippet of what it is doing. There are 3 chunks that are nearly identical: 604 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__IIIILorg_eclipse_swt_internal_cocoa_NSRange_2 604 -[NSConcreteMutableAttributedString addAttribute:value:range:] 513 -[NSMutableRLEArray replaceObjectsInRange:withObject:length:] 513 -[NSAttributeDictionary release] 513 -[NSConcreteHashTable removeItem:] 513 -[NSConcreteHashTable rehashAround:]