Can you give some more details like -
How many open projects do you have in your workspace?
What operation are you performing when you hit this problem - project loading, refactoring, finding references, project compiling and building, etc.
Also, will it be possible for you to share your projects?
Thank you very much for interesting on that issue, that it is really annoying on the day to day development work, as we have to quit eclipse with FB an average of 3 times a day either because it is becoming extremely slow, or because we have an OutOfMemory popup at some point.
It is quite difficult to define what exactly trigger this over CPU usage. However, it seems that it is mainly debugging stage that it is the cause of this, as we just code and build without launching the app, the phenomenon occurs much later.
What we can also observe is that it seems to be linked to memory consumption of eclipse process, as when we exceed a rough 300-400 MB in Windows Taks List generally we also have this 50-70% CPU usage, and only quitting Eclipse solves the issue. But cannot ensure that it is always the case, I mean we can have the CPU usage increase sometimes with 800 MB and sometimes with only 300MB windows memory consumption.
Note then that increasing eclipse memory parameters in eclipse.ini doesn't change anything to this issue, maybe slightly delaying it a little bit, but that's all.
Regarding your other questions : we have many projects in the workspace, but of course we try to avoid having several opened at the same time, because search, refactoring, content assist are much longer if you have many projects opened. We can also say that this phenomenon occurs only with the main project, which is quite big (~300 classes, 40K-50K lines of code).
Unfortunately I cannot share the project as it our main asset and strictly confidential. But what I can say to you, and we think it might be a important point to check, is that project is a multi windowed AIR 2.0 project massively using Flash GoogleMap API, and RemoteObject services with the GraniteDS client server framework. We have observed another issue, but well documented is that memory consumption of the application being running under adl is growing very quickly if we display lot of objects on google maps (400MB-800MB typical memory footprint). But please note that when application is stopped and adl.exe terminates, this memory is freed, our problem here is the eclipse CPU usage process only.
Two other observations :
- the overload CPU phenomenon doesn't occurs each time we pass in debug mode. We may start and stop two or three times the application, without having the problem. But it may happen only with one debug launch, not necessarily immediatly but after sometimes of using the application.
- having said that, you should investigate on the internal FB process that build in memory the mapping of method calls flow and variables states of the application in order to display it in Variables and Debug tabs. It seems that this process goes in an infinite loop when trying to free thh previously allocated memory for this purpose. But this only a suggestion, it may come from something completely different.
So, basically you see the memory going up while debugging. Building/compiling the project works fine.
Can you attach the workspace log? Its located here -
Help -> About Flash Builder -> Installation Details -> Configuration -> View Error Log
You can send it to me directly here - sameer AT adobe DOT com
Are you using MyEclipse?
Can you please try working on your project in Flash Builder standalone as well? (Without the SVN plugin installed, solely to isolate what might be the root cause)
Can you please try disabling Network monitor?
If the suggestions above do not work, could you please add -XX:+HeapDumpOnOutOfMemoryError in your eclipse.ini and send us the heap dump?
Thank you for your patience with the above questions. This is an important issue for us to nail down and we appreciate any assistance in this.
I have similar issue - it does not really relate to memory consumption (FB never eats whole available memory), but after one hour of work, I can see FB hitting 100% CPU, demolishing my machine completely, heating it up, so that further work is not possible. It does it while being absolutely idle, no compilation or debugging turned on. I wasn't able to trace the reason, but it might have something to do with running application in debug mode - I guess that after few runs it hits 100% and just stays there (infinite loop?). I'm working on 5 open projects, it's a AIR 2.0 / Flex 3.5 / Flash 10.1 application. The only solution is to quit FB and wait 5-10 mins for machine to cool down.
I'm running on Mac with latest Snow Leopard, FB standalone. This behaviour can be confirmed on other macs with snow leopard. My colleagues with windowses (xp / vista) do not seem to have this issue.Changing JVM settings do not seem to affect this.
This bug drives me crazy and makes working with FB virtually impossible. Adobe, with your pricey product, I would expect quick reaction to such dramatic issue. If I can provide any dump data, logs or anything, I will, please advise.
Can you send your workspace log and heap dump as suggested by Anirudh above.
Sent to your mailbox.
Excellent solution. This worked for me. It brought down the recompile time from 10+ minutes to under 10 seconds.
@ Sameer: I tried the JARs suggested in the bug report, i still face this issue. Why cant Adobe provide the fix for FlashBuilder 4 as a update or exe.
In my case, the problem was network monitor enabled (the jars in jira provided fix a different issue). Try disabling it completely and see if it helps.
In my case it is a heap size reaching available limit as mentioned by Sameer and given link http://bugs.adobe.com/jira/browse/SDK-26366. We have atleast 7-8 projects that create SWC's and consumed by each other and finally by the main SWF. Once i do a clean build the memory hits the top limit thats 956M out of 990M available. Forcing GC hardly helps. Any further saving and compilation becomes a long wait.
Fix seems to be available in 4.5, but why pay more if it is a software defect in FB 4?
I have performed the same steps mentioned in the link. But if i have checked the Project/Build Automatically option or if i perform a Clean then the heap size grows to 956 mb and as i mentioned in earlier mail it never comes down.
As a workaround i sparingly use clean now and build only required projects.