Community
Participate
Working Groups
After updating Eclipse to 3.0M8 (from 3.0M7) I experienced some heavy freezes of the whole UI while working. Writing text was not the problem, I could even mark code passages and replace them with new code - the problem was that the output was lagging with a latency of more than 5 seconds. The Windows Task Manager showed me a CPU usage of 99% for the Java Interpreter javaw.exe when these lags happen to appear. Memory usage is also very high during these lags (like 150MB of memory). A partial solution to this problem was to minimize the eclipse window. After some time (this depends and seems to be quite random) memory usage drops slowly till reaching some value around 4mb (which seems reasonable). And of course CPU usage drops to around 10%. Working is possible again but soon lagging starts over again. I tried downgrading the java interpreter (from 1.5 beta to 1.4.2) but that doesn't seem to help. Watching the Task Manager shows some very interesting behaviour. When eclipse is minimized it uses around 5MB of memory. Maximizing the window lets the usage jump up to 10mb. Now the interesting part. If i'm not doing anything (not moving the mouse, no keyboard input) memory usage stays the same but as soon as I start moving the mouse, or doing input memory usage rises and rises. It does seem to rise until the page swapping kicks in and tries to move blocks outta RAM. I suspect this to be a problem with the redrawing code, maybe you've got a memory leak there?
Redrawing code is owned by SWT. Transferring.
Tobias, could you try the latest integration build? There have been many improvements in the styled text drawing code since M8.
I've installed the integration build but the memory trashing problem still remains. It seems worse than before. Just after starting Eclipse mem consumption rises to about 150mb. Another problem is that CDT stopped working with this build, so even if there was no memory trashing Eclipse would be useless for me. What about the nightly build? Should I give it a try?
Which version of Windows do you have ? I use Eclipse several hours day and I work with large files (>8000 lines) quite often and I never had this problem. Maybe this problem is somehow related to CDT, since I don't have CDT you could try to run Sleak to detect if there is memory been leaked. See intructions: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt- home/dev.html#tools
My system is running win2k professional patched with the latest SP (sp4). Version is 5.00.2195 I don't think this is related to CDT because trashing even occurs if CDT isn't installed at all. But i'll try this sleak plugin, maybe i can figure out whats going wrong here.
According to sleak everything seems to be okay. No resources are created during the memory trashing. So maybe its not SWT's fault?
I've ran sleak a few weeks ago and I also didn't find any problem. I would like to know why does this problem happen on your machine but not on my.
Could this be a problem with the java interpreter itself? I'm not a java coder myself but I know memory releasing is done through the automatic garbage collector. If it's a problem with javaw a bug in den GC would be obvious. But i really can't imagine that a non-beta java version like 1.4.2 has such a major bug.
I don't think so, this same java virtual machine was working fine with Eclipse M7 and you also tried different java machines.
I am experiencing the exact problem that Tobias reported. I'm running Eclipse Version: 3.0.0 Build id: 200406251208 on Windows XP Professional SP1 with Java 1.4.2_03 and have only experienced this problem after upgrading to Eclipse 3.
I can attest to this behavior since upgrading as well (and on 2 different "fresh" OS images) OS: happens on both my XP Professional and my Win2K Professional dev machines Eclipse version: 3.0.0 Build id: 200406251208 Memory allocation is sky high. javaw.exe is at 58 MB physical memory and a whopping 136 MB of virtual memory (the virtual memory seems to climb the most). Eventually, Eclipse will slow down to a crawl with GUI elements actually re-painting themselves while I watch. I NEVER saw this problem with earlier versions. My config: I am editing a fairly large project with several thousand files in it, and I'm using the linked file feature to link the source files with my workspace in Eclipse. I'm also using these startup arguments: C:\apps\eclipse\eclipse.exe -vm c:\apps\j2sdk1.4.2_05\jre\bin\javaw -vmargs - Xmx256M I'm using Java 1.3.1 JRE for compiling the project, while Eclipse itself should be using the 1.4.2 libraries. This setup was fine until version 3.0, and I never saw any sign of memory problems.
I'm seeing what appears to be the same bug, also running Eclipse 3.0.0, build 200406251208. Interestingly, this seems to be getting worse over time. In fact, the first week or so that I had Eclipse 3 installed, I thought it was fine. It's really just been this last week that it's become almost unusable. I can launch Eclipse, start using it, and within 5-10 minutes of opening and editing 2 or 3 files, memory usage has grown to > 250 MB, and the UI has slowed to a crawl. FWIW, I do have the Web Tools project stuff, plus the EPIC Perl plugin, and the Ruby plugin installed, so this could be related to one of those, I suppose.
Phillip, I would not assume it's related to any of those plugins, as I don't have any of those installed, and yet the effects you describe are precisely what I'm seeing on both of my machines.
I am having the same problems as well. I am running on Windows XP home and am using the following startup arguments: -vmargs -Xms256m -Xmx512m The problems started when I upgraded to version 3 - I'm currently using version 3.0.1. The worst case is when using the refactoring tools. A refactoring that would have taken 15 seconds on eclipse 2 now can take up to 20 minutes.
"A refactoring that would have taken 15 seconds on eclipse 2 now can take up to 20 minutes." Have you tried exactly the same refactoring in Eclipse 2 and 3 and the time difference is ~20min ? Is it reproducible ? Please open a problem report againat JDT about this.
Ya, it's reproducible. I'm working fairly large projects which prior to adding the vm arguments would cause an out of memory error if I tried any refactoring. Even a simple class rename of a new test class - one that was not called by any other classes would crash the ide. After adding the vm arguments, I can use refactoring but it is extremely slow.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
The original problem discusses minimizing and maximizing of the Eclipse window, and slow drawing. The large memory differences between Eclipse 2 and Eclipse 3 is not an SWT problem, please file bugs about this somewhere else. Sorry that this has stuck around here so long. The problem with minimizing and swap usage is discussed more in bug 85072. I am marking this as a duplicate. *** This bug has been marked as a duplicate of 85072 ***
