Community
Participate
Working Groups
Build id: I20051215-1506 This has been a problem since the first 3.1 builds. I was hoping it would have been fixed with all the other CPU issues, but this does not appear to be the case. The use of Eclipse while the CPU is at 100% is much improved (i.e. usable), but it would be nice to do your development without the CPU running at 100% all the time. As such, the last build that was concidered usable has been 3.0.2. Items of interest: 1. I am using a clean install with an imported project 2. The Heap graphic shows that the heap is filled every 2 seconds and then drops down to 17M from 46M 3. JVM -> Sun JVM 1.5.0_06-b05 4. Machine -> Athlon XP 2000, 500Mb memory 5. OS -> WinXP SP2 6. Project includes 20,000 classes within several jars and sources attached. 5 java files have been unzipped and are being edited Here are 4 different ways to recreate this issue: 1. Upon opening Eclipse, the CPU does not settle down for about 2 minutes 2. Opening a file - CPU takes about 28 seconds to settle down The file is displayed immediately and the editor is usable Note: nothing else was done except open the file 3. Changing application focus - CPU takes about 28 seconds to settle down a) Start on Eclipse and wait for the CPU to settle down b) Change to IE or some other application for about 5 seconds c) Change back to Eclipse 4. Save the file - CPU takes about 28 seconds to settle down
Created attachment 32051 [details] Stack trace during 100% CPU I have captured a couple groups of stack traces while the CPU is running at 100% CPU. Hope they help
From your attached thread dumps, it seems that your machine is busy updating the Java model structure of JAR archives. How much maximal heap size do you assign to vour VM?
Here is the command line execution that I used (copied from what I saw when I killed javaw.exe after executing eclipse.exe directly) java -Xms40m -Xmx256m -jar "c:\Program Files\eclipse\startup.jar"
Moving to jdt.core
Could you please try with -Xmx512m and report back ?
Changed machine to P4 2.8 hyperthreading with 1GB memory JVM -> Sun JVM 1.4.2_05 OS -> WinXP SP2 Command line options: -vmargs -Xmx512M Opening Eclipse - CPU settles down after 30 seconds Changing application focus - NO CPU usage Opening a Java file for editing - 10 seconds Saving and compiling the file - 15 seconds Ran a typical 10 minute programming session with Eclipse 3.2M4 and the average CPU was 34% The same session (opening, closing files, searching, editing, saving) on Eclipse 3.0.2 had an average CPU of 5% Note: this included starting/stopping of Tomcat 5 during the same session a couple of times
Just to make sure: do you see the same stack traces as in comment 1 when the CPU is at 34% ?
The logs for those situations appear the same. However, when I tried to open as many classes as I could (I got to about 30) the User Interface locks up for about a minute and does not allow ANY access to eclipse. During this time the CPU was at 100%. An example of this is in the final stack trace in the attached file. Around the middle of the file is a stack trace that occurred when only about half the user interface was accessible and the CPU usage was 0. I could open and close the tree structure on the package explorer, but right and left click was ignored when clicking on a file. After waiting for about 5 minutes the situation did not correct itself and I had to forcefully shut down Eclipse. Stress testing Eclipse definitely causes some weird events to occur
Created attachment 33951 [details] 2nd set of logs captured
I entered bug 126174 for the UI freezing problem that you noticed.
I posted an instrumented version of jdt.core based on I20060131-1200 at http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.0.z20060202-1330.zip. Could you please do the following ? 1. install the jar in you plugins directory, 2. Create a .options file in c:\temp with the following content: org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/javamodel/cache=true 3. restart Eclipse with: -clean -debug c:\temp\.options You should get some traces that should tell us what's going on.
Where will I be able to find these traces?
They should be in the DOS console.
This is the entire contents of the DOS console for the duration of all the problems in Eclipse. Install location: file:/c:/Program Files/test/eclipse/ Configuration file: file:/c:/Program Files/test/eclipse/configuration/config.ini loaded Configuration location: file:/c:/Program Files/test/eclipse/configuration/ Framework located: file:/c:/Program Files/test/eclipse/plugins/org.eclipse.osgi_3.2.0.v20051212a.jar Framework classpath: file:/c:/Program Files/test/eclipse/plugins/org.eclipse.osgi_3.2.0.v20051212a.jar Debug options: file:/c:/temp/.options loaded Time to load bundles: 125 Starting application: 2156
Sorry I wasn't clear. You're running an 'old' build. Please install I20060131-1200 and add the plugin from comment 11.
Created attachment 34099 [details] Debug Trace Before any of the trace information displayed I had to add the following the the .options file: org.eclipse.jdt.core/debug/javamodel=true The captured stack trace was for the following sequence of events. Each event caused a run on the CPU. Open Eclipse Open file 1 Open file 2 open file 1 open file 2 add a space to file 1 remove a space from file 1 compile file 1
Created attachment 34263 [details] Proposed patch
Cary, I posted a patch for this problem at http://www.eclipse.org/jdt/core/patches/org.eclipse.jdt.core_3.2.0.z20060207-1355.jar. Note this requires you to install I20060131-1200 (or today's integration build) first, then copy the .jar file above in the plugins directory. Please let me know how it goes.
I ran Eclipse I20060131-1200 with the patch Jar file all day. None of the CPU events were encountered. However, I did see only one UI lockup that took about 10 seconds. Previously, I encountered the UI lockup around once every 5 minutes. Seeing only 1 event in 8 hours is a definite improvement. I am also going to let everyone over here know that the long awaited usable upgrade for Eclipse should be 3.2 (M5?)
Thanks for the feedback and glad it worked (it was actually a tough one). Released the patch in HEAD (so yes this will be in 3.2M5). <jdt-core-internal-note> Fix consists in avoiding to open packages and package fragment roots from jar files. When a type is looked up (NameLookup#seekTypesInBinaryPackage(...)), it is stored in an extra LRU cache (JavaModelCache.jarTypeCache). This cache is reset as soon as the classpath changes. To reproduce the initial problem, run Eclipse with -Xmx64m on a workspace with org.eclipse.jdt.core loaded as source, then open JavaModelManager.java. Editing it you will see the long CPU events reported in this bug. With the fix, the CPU events are gone. </jdt-core-internal-note>
*** Bug 125305 has been marked as a duplicate of this bug. ***
Verified by owner for 3.2 M5.
