Community
Participate
Working Groups
Once every sixty seconds my CPU gets pegged for one second while the Java editor does something in the background. I'm sure there is some background thread doing something important by design, but we need to lower that thread's priority so that it doesn't interrupt iTunes. If someone knew where the code was that does it I'd be happy to look at optimizing it. I'm confident this is a Windows-only issue.
The Java editor has no such timer. I assume you have auto-refresh of resources checked but that should not result in work for the Java editor. Do you see this only if the Java editor is open? If so, please reopen with a stack trace that shows the Java editor doing the work.
Other causes for this: - auto-save of workspace (General > Workspace) - CVS auto-update (if enabled, see Synchronize view's view menu)
I checked workspace and CVS. They have different timeouts than every minute. Watching in the task manager, javaw.exe is the process that pegs once each minute. And it appears that program is loaded by Eclipse as it goes away when Eclipse is shut down. I was assuming it was the Java editor, but it could be some other part of Eclipse that relies on javaw.exe? I have J2SE 1.5.5. Possible helpful information here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5101898
The following link explains how to make a thread dump. Please create some thread dumps at points where you see the peak and attach them here. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/development/bug-incomplete.htm
The processor pegs at the System.gc call in IDEIdleHelper.java. That is triggered every 60 seconds. For proof I put the org.eclipse.ui.ide/debug/gc=true in the .options file and watched it. That call should not not be running in a high-priority thread, but that is a bug to be posted somewhere else.
.
John, MvM tells me you're responsible for this piece of code...
Yes, I put that in. I don't think the thread or priority matters when calling System.gc(). All Java threads are suspended during this call. I really don't think there is any way to influence its priority. There are a number of options for configuring this: ide.gc=false will turn it off ide.gc.interval=<int> will change the frequency These options can be set either in eclipse.ini, or using command line argument: eclipse -vmargs -Dide.gc=false
So is enabling -Xincgc a valid alternative to periodically executing System.gc() ? Here's a possible reference: http://java.sun.com/developer/JDCTechTips/2004/tt0420.html
-Xincgc is not a standard Java VM option. The -X options don't exist on all VMs, and are not guaranteed to exist across different releases of a given vendor's VM. Since Eclipse must be able to run on a variety of VMs, it's not an alternative from a global Eclipse point of view. However, for a particular user running on a particular VM, you can feel free to use non-standard VM arguments in place of the Eclipse IDE gc policy.
Brannon, can you describe the specs of the machine you are using? I'm admittedly on a 2.5Ghz pentium, but I only observe the gc taking up to 40% of the CPU for a very brief blip. You mentioned that you also see Eclipse interrupting your tunes during startup, but does it occur at other times while you are using Eclipse, such as when compiling? I.e., is it only this 60 second blip that causes your music to skip?
This feature was introduced by Bug 92164.
Alex, you bring up a good point about hardware specs, but it should only effect things if it had to swap something out of memory. I guess that my point was that if Visual Studio 2003 can load a serious project without interrupting my music during load or edit, then Eclipse should be able to do it as well. The thing is, I cannot pull up a webpage with a Java applet and have it not interrupt my music. And this is the case for every version of Java I've ever used on both of my current machines as well as all the older ones. One is a P4@2400/1.5GB@800/RAID0@7200x2 and the other is Athlon@2000/1GB@533/RAID1@7200x2. Of course I've always used Sun's JVM stuff and I've only used it on Windows. I'm tempted to blame this issue on Sun. The task manager shows that all processes affected are at normal priority, including javaw.exe, so it's not a process priority issue, though maybe if I ran iTunes as a realtime process it would not interrupt the music. It's as though the GC locks all the memory for the whole system, though I'm not sure how it would do this without a kernel-level driver. And maybe that's how it does it. It could have an embedded driver or use some other trick for kernel-level access.
I admit that I have often seen java programs bring my Windows machine to its knees when under heavy computation (although not garbage collection in particular). I have attributed this more to the operating system's process scheduler than to java - in my opinion an OS should not let a single process take over all the machine's CPU like that... I don't think you need to be operating in kernel space on Windows to kill responsiveness of other apps.
This bug and workarounds for it are posted on Sun's site here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5101898
(In reply to comment #15) > This bug and workarounds for it are posted on Sun's site here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5101898 > This bug has nothing to do with audio. My entire machine is hung every minute because of a CPU spike. The mouse, keyboard, everything.
Can you both tell us what VM you are using (so we can figure out if it's a Sun 5.0 Windows only problem)? James, the built in gc doesn't run when there has been recent keyboard or mouse activity, so it seems odd that you are noticing keyboard and mouse lockup (unless you start using the keyboard and mouse after a long pause, and just happen to start right when the GC is running). The gc is scheduled with a minimum interval of 60 times its last duration, so it's using at most 1 second of CPU every minute.
(In reply to comment #17) > Can you both tell us what VM you are using (so we can figure out if it's a Sun > 5.0 Windows only problem)? James, the built in gc doesn't run when there has > been recent keyboard or mouse activity, so it seems odd that you are noticing > keyboard and mouse lockup (unless you start using the keyboard and mouse after > a long pause, and just happen to start right when the GC is running). The gc > is scheduled with a minimum interval of 60 times its last duration, so it's > using at most 1 second of CPU every minute. > Hello John, I am using Sun's VM version 1.5.0_05-bo5. Operating under Windows 2000 using Athlon processor. I have 1G of memory. The eclipse version is 3.2RC3. The VM is operating in mixed mode. I have been having this problem for some time but in all honesty have ignored it because I figured it would be fixed soon enough and learning RCP was more important. The CPU anywhere from 85 to 100% periodically. I cant really say if its every minute but it seems that way. It only spikes for a fraction of a second but it absorbs all resources. <--- Typing after the "c" in resources was delayed for a fraction of a second. It only started happening after I installed 3.2 of Eclipse.
So here is what I've learned: The java threading model uses a priority range of Thread.MIN_PRIORITY (1) to Thread.MAX_PRIORITY (10). Using the Ctrl-Brk in the Eclipse debug console I see about ten threads running. Several run at 10. Several run at 5. And others run at various priority levels. Windows supports priorities of IDLE_PRIORITY_CLASS BELOW_NORMAL_PRIORITY_CLASS NORMAL_PRIORITY_CLASS ABOVE_NORMAL_PRIORITY_CLASS HIGH_PRIORITY_CLASS REALTIME_PRIORITY_CLASS So those six get mapped into Java's ten priority levels, with 10 corrosponding to realtime. The thing is this: you rarely if ever want a Windows thread running at the Realtime priority level. Sun has put in some command line parameters to make it not map to the Realtime priority. They are listed in the Sun bug posted above as well as here: http://blogs.sun.com/roller/resources/watt/jvm-options-list.html Adding -XX:ThreadPriorityPolicy=0 (=1 is default in my of Java v.1.5.5) actually makes a great improvement for me: my music now only stalls during UI Init. The GC no longer freezes the system. I'm tempted to do the manual mapping using the -XX:JavaPriority10_To_OSPriority=, etc.
Wow. I just found a great link on the topic and had to post it: http://www.javaperformancetuning.com/news/roundup058.shtml
Ladies and Gents, we have a solution. Behold my eclipse.ini file: -vmargs -Xms40m -Xmx256m -Xoptimize -Xconcgc -XX:ThreadPriorityPolicy=0 -XX:JavaPriority1_To_OSPriority=1 -XX:JavaPriority2_To_OSPriority=2 -XX:JavaPriority3_To_OSPriority=2 -XX:JavaPriority4_To_OSPriority=3 -XX:JavaPriority5_To_OSPriority=3 -XX:JavaPriority6_To_OSPriority=4 -XX:JavaPriority7_To_OSPriority=5 -XX:JavaPriority8_To_OSPriority=6 -XX:JavaPriority9_To_OSPriority=7 -XX:JavaPriority10_To_OSPriority=8 And she works without any skips -- ever! Of course this only applies to Sun's 1.5.* stuff (I think). It appears there is some initialization stuff that should have an hourglass that doesn't that seems to hog the processor such that I cannot edit any text. I believe loading the help View is one of these. But at least it doesn't make my music skip! As a side note, does anyone know how or have an instructional link on how to set parameters for my web browser's JVM plugin? I'd like to fix the issue for webpage loads as well.
Thanks for looking into this Brannon - it clearly looks like a VM problem. For the curious, Eclipse uses Thread.NORM_PRIORITY+1 (6) for the UI thread, and typically Thread.NORM_PRIORITY (5) for background work (jobs). It clearly looks like the gc in the Sun VM on Windows operates at a very high os priority.
(In reply to comment #22) > Thanks for looking into this Brannon - it clearly looks like a VM problem. For > the curious, Eclipse uses Thread.NORM_PRIORITY+1 (6) for the UI thread, and > typically Thread.NORM_PRIORITY (5) for background work (jobs). It clearly > looks like the gc in the Sun VM on Windows operates at a very high os priority. > The only problem is that it doesnt explain why this doesnt occur with 3.1 nor any other java application. I am running a oodb server on my local machine and when I stop Eclipse all is working fine even though I still have a java process running.
It sounds like it occurs in Eclipse 3.2 because of our use of System.gc(). The question is, is it a bug to be calling System.gc(), or is it a bug in the implementation of that method in that particular VM that causes machines to freeze?
The bug is that Sun's JVM runs at too high of a priority by default. This issue accurs in 3.1 but it only shows up at load time -- not once every minute for the System.gc call like it does in 3.2 (which still suffers from the issue during load time as well).
If it is a bug in Sun's VM -- and Sun's VM is used widely -- maybe we should workaround the bug (i.e., remove the gc).
I think the gc is fine. Just use the eclipse.ini file posted above for your workaround. What I would like to see is for the eclipse.ini file to support multiple JVMs. In other words, you could put a header in like [Sun JRE 1.5.*] that contained all the useful or necessary switches for that particular JVM. The user, then, would never know there is an issue.
I would vote for the removal of the gc. 3.1 worked fine without it and the changes to the ini file still does not completely resolve the problem though it does help. I am still having the same problem -- though not as frequently --- with the changes in the ini.
I have a suggestion: - we turn off this option by default "ide.gc=false" - and add an option in the memory monitor to turn it on
While in theory this change should improve performance, it would be helpful to see some numbers. Re-opening because of comment #29 and Bug 121562.
A way to turn this off programatically makes sense. However, I haven't seen much evidence of how much of a problem this is causing. We've had two people report this, one of whom observes the same behaviour in other Java apps such as simple applets. The benefits, reduced peak memory usage and reduction of gc during "busy" periods, is admittedly hard to measure. I have been running with this for six months and find that it greatly reduces the occurrence of gc pauses while typing in Eclipse, because it only runs when I stop typing for several seconds. James, I assume you notice this when it causes gcs while you are not using Eclipse? One thing I can try is to ensure it doesn't run any more if Eclipse stops receiving events. I.e., after a gc runs, another mouse or keyboard event from within Eclipse would be needed to reschedule it again.
(In reply to comment #31) A few days ago I replaced my hard drive and downloaded jsdk 1.5_06 and the problem has completely vanished. I have nothing in my ini file regarding thread priorities. While the periodic spiking is occuring there is no visible affect on any applications I am using. Prior to this build the problem only occured with Eclipse. I am running an OODB server as a local host which also used the prior vm and the problem did not exist with the OODB server. I can only assume that Sun fixed the problem with the newer release of the vm. John, I would not reopen this unless others begin to see the problem with 1.5_06 or later. Hope this helps and doesnt add more confusion. I apologize for not posting this sooner but I wanted to run the environment as long as possible to insure that the problem really had disappeared.
Please don't take the idle gc out by default. It makes a big positive difference in perceived interactive performance. But see also bug 92164 comment #22, and bug 109760.
While idle GC doesn't interrupt my music player on WinXP, it does cause Windows Media Player and my TV software (dscaler) to hang for about half a sec every time GC is ran. Windows XP task manager shows major CPU spikes for Eclipse's java process while GC'ing. I like to leave Eclipse in the background for long periods, but this change has forced me to shut it down when I'm not using it. My system is running on Athlon 64 3700+ and 2GB ram, so it's certainly not about slow hardware. My VM is Sun Java 1.5.0_06-b05. Please consider disabling the idle GC if there's no way to fix these side effects.
See comment #8 for how to disable it.
Closing. The CPU pinning was due a bug in early releases of the Sun java 5.0 VM. It is fixed in jsdk 1.5_06.
I believe this to be unresolved in jsdk 1.5_06. I am seeing exactly the same symptoms as described -- approximately every minute there is a hard freeze while typing or scrolling in any application while the IDE is open in the background. Task manager shows Eclipse's javaw.exe process peaking at 100%. The only solution I have found is to set ide.gc=false. This is under Windows XP, 1Gb RAM, 1.6GHz Pentium M, Eclipse 3.2 build I20060428-1315.
I have the same problem with jdk 1.6.0-b105 under windows 2000 and eclipse 3.2.1. My tv program freezes shortly every 60 second.
I had the same problem for a long time 2.4Ghz 2GB RAM using myeclipse I tried to add the mentioned lines in eclipse.ini and to change jdk to 1.5_06 and nothing works. It seems the problem is the myeclipse visual JSP designer text edition pluging. Worst if outline view is present. Deactivating it works nice. I hope to help somebody. Good luck
