I'm working with Eclipse Indigo, 64-bit version in 64-bit Windows 7 and the most recent version of 64-bit Java SDK. Using standard Java and XML as well as Pydev plugins. My machine has 4 GB of RAM.
When I try to open, edit, and search large XML files (42,000 lines or so) in either the XML perspective or the plaintext editor of Eclipse, the program locks up. The heap monitor in Eclipse becomes fully consumed. Waiting to see if the deadlock will halt doesn't help, and I have to restart Eclipse to get it functional again.
Any ideas what the problem is here? Bad version of Java? Eclipse Indigo or 64-bit version not road-ready to go yet?
42K is a really big file for the poor XML editor. It's likely that it's just taking a really long time to deal with this. I would file a bug against the webtools project in Eclipse and attach your file (if you don't mind sharing).
I would capture the thread dump (google "java thread dump" if you don't know how to do this) a few times while it's working so that you can get a stack trace of what's happening which might be useful to the Eclipse folks.
There is nothing wrong with Eclipse Indigo or 64 bit Eclipse (I and many others use those just fine for normal work).
Related
I'm using the eclipse neon IDE and I put it on the path: /opt/eclipse/eclipse and i am using Ubuntu 16.04 and Java 8. The problem is that when I write in the eclipse editor, this is going too slow. For example, I just typed and in the editor it still does not end.
How can I solve it?
Thx!
Try Netbeans, or IntelliJ IDEA.
A quick browse over the Interwebs shows that quite a lot of people are complaining about Eclipse slowness. Some have every manner of trick and configuration change to help speed it up. OK, you can put yourself thru all that hassle if you want, or, you can just switch to something that already works fine out of the box.
I had Eclipse Oxygen for PHP running on a CentOS 7 VM with 2G allocated RAM. I admit, that's pretty low memory, but that's the way it has to be right now. Eclipse ran so slowly, I finally gave up and killed the process from the command line.
I installed the latest Netbeans 8.2, and it not only installed more cleanly (no Java error messages, and it put an icon on the desktop), it ran PERFECTLY without changing a thing!
I eventually changed a couple of parameters, but the point is, I didn't need to change a thing to get decent performance. Even on a low-ram system, it ran plenty fast enough.
Don't blame the hardware. Not everybody has the money to buy the latest and greatest and fastest machines available, and software developers should not expect it. With some exceptions, if your application can not run adequately on 2G of ram, you are doing something wrong.
The Eclipse developers are doing something terribly wrong.
I had faced a similar issue with eclipse oxygen.
After a some research over different forums I found the following solution.
Step 1 : Open eclipse.ini file. If you find difficulty in locating the file, see this question Where's the location of the eclipse.ini file?
Step 2 : In eclipse.ini search for below 2 variables
-Xms
-Xmx
Xms indicates minimum ram that should be allocated to eclipse.
Xmx indicates maximum ram that should be allocated to eclipse.
Step 3 :Increment both the values. You can set the value as per your choice. Below is my preference.
-Xms512m
-Xmx2048m
Here
m indicates megabytes, if you don't specify m it will consider bytes by default.
The easiest thing to do would be to re-install eclipse, and if that does not work you could try to download an older version of eclipse. It could also be slow because your computer is slow.
I have a Java app installed with Install4j.
The app started failing with the dreaded error "The JVM could not be started. The maximum heap size (-Xmx) might be too large or an antivirus or firewall tool could block the execution"
After investigation it turned out that Java did an automatic upgrade from 8.111 to 8.131 and install4j was still going to the old version. The fix was to edit \.install4j\inst_jre.cfg and change the contents from
c:\program files (x86)\java\jre1.8.0_111
to
c:\program files (x86)\java\jre1.8.0_131
However, that is not a very user friendly thing to have to do. Is there any way to have the install use something more flexible? Like going through C:\ProgramData\Oracle\Java\javapath? Or anything else.
Thanks
I have standard Eclipse Kepler with CDT installed. Sometimes when it stays idle for a while the javaw.exe starts eating the CPU up to 30%. Nothing is running in Eclipse, no indexing, no library update, no building or compiling.
How can I debug Eclipse to see if something is running in background? Does Eclipse have any console or log so I can see what exactly is being done?
Not to mention, I even restarted the Eclipse but it just works for a few moment and then again reaches high CPU usage. What could be the problem?
Windows 7 64bit
Eclipse Kepler standard (plugins ADT & CDT)
Java 7
You can try add some memory to eclipse.ini parameter -Xmx512m
It can be useful in some cases but you will need to try it..
Hope that helps
I'm on a team of 6 developers and we are all using Eclipse Indigo on Ubuntu 11.04. At least once a day, if Eclipse is running, each of us experiences a total system lock-up. The only cure is a hard reboot of the PC. Some of us have had it more than ten times in one day. This does not happen if Eclipse is not running, so I can confidently say that Eclipse is the problem.
I have tried increasing the memory available to Eclipse by going into the ecplise.ini and increasing the Permsize, MaxPermSize, Xms, and Xmx. This has made no difference and everyone's PC is still locking up.
Has anyone experienced this before? I could understand maybe on one PC, but it happens on every single PC!
Java version: java-6-sun-1.6.026 JDK version
Ecplise version: Indigo SR1 BuildID 20110916-0149
Ubuntu version: 11.04 64-bit
EDIT: Ctrl-Alt-FnX keys do not work once the PC has locked up.
EDIT: I've revisited the eclipse.ini settings and increase the memory some more. So far I haven't had a crash yet. I will use the other developers as guinea pigs, but I'm hopeful that these settings will stop the crashing.
-XX:PermSize=256m
-XX:MaxPermSize=512m
-Xms1024m
-Xmx2048m
This is not to resolve Eclipse problem... which might be happening because of some display issues I suspect.
Instead of hard reboot you can press keystrokes Ctrl+Alt+F1 together to reach console and there you can login to a text based terminal and kill the Eclipse process.
more a comment than an answer, but I cant add you a comment yet.
I'm kinda using the same setup: Ubuntu 11.04 64bit with Eclipse Indigo SR1 RC3 64-bit (buildid 20110909, didnt had time or need to update to a newer release yet, but RC3 is stable for me). Make sure, you have installed the 64-bit version of Eclipse.
OpenJDK in combination with Eclipse didnt went well for me, so I changed to java-sun jdk 1.6/7. Make sure Eclipse is not referencing to the OpenJDK installation instead of java-sun jdk.
I had some issues with Eclipse Indigo (pre SR1) freezing in combination with SVN Subversive/m2eclipse plugins. For me it got better with the SR1 (RC3), but still not perfect (a freeze now and then). A while later Subversive SVN had an update, and now it's stable again. In short: make sure, you have installed the newest plugin versions (use eclipse update sites, no local copies). Older versions might lead to the same problems I experienced.
What other plugins are you using, can you verify if your Eclipse crashes without any plugins installed?
Two other issues I'm aware of: with Ubuntu Karmic Koala (9.10) rendering UI elements was broken/lead to crashes as well (GTK_NATIVE_WINDOWS). Later Eclipse had problems with the native scrollbars (think it was with Ubuntu 10.10 or 11.04). I'm pretty sure, problem 1 aint an issue anymore with Eclipse Indigo + 11.04. Problem 2 I'm not sure if it was 10.10 or 11.04. But I still start my eclipse with the following script.sh and it works for me, you could give it a shot as well:
#!/bin/bash
export LIBOVERLAY_SCROLLBAR=0
export GDK_NATIVE_WINDOWS=false
exec $(dirname $0)/eclipse "$#"
Try upgrading the kernel to the latest version. I think this lock up is caused by the kernel bug detailed on this page https://bugs.launchpad.net/ubuntu/+source/linux/+bug/924905
While you wait for better answers, I would definitely try a virtual machine like Virtual Box to:
Try to see if I can replicate the problem in a Virtual environment, which is similar to your actual environment. This way you can see if the problem the combination of the versions of software that you're using or your physical hardware.
Run Eclipse through the VM. It may not crash and will prevent you from having to do a full re-boot of the system, until you determine what the actual problem is.
I have a similar problem. From time to time it happens that the complete X11 desktop freezes. I can still move the mouse but clicks on elements have no effect.
In this situation I switch to the text console and kill eclipse. After I did that, everything works again.
I am using a laptop with an Intel graphics chipset. So I tend to blame it on the the graphics driver.
I have other computers with different graphics hardware where I haven't noticed the problem, but I don't use eclipse that often on them. On all I am using Ubuntu 11.10 64bit with gnome or unity desktop.
I have the same issues. It is very inconvenient. I have just confirmed that killing eclipse fixes the issue for me.
However, I have found something strange in that I can still click on the stupid overlay scrollbars. It's like they have the focus of the entire system.
What seems to have fixed the issue to me was to install the gnome shell and start using gnome 3, then turn off the overlay scrollbars in the startup scripts for X. I installed gnome 3 for a separate reason and disabled the scrollbars because I find them annoying, but I do find that this has solved the problem for me. You may be able to get away with just disabling the scrollbars, information for which is readily available on google.
I am using eclipse 3.5 (cocoa build) on Macos 10.5 with Java 1.5.0.19.
I just have 3 java files opened
1 files ~ 2000 lines
the other 2 are ~ 700 lines.
But when I switch from 1 file tab to another, eclipse takes a long time (~ 20 seconds) to switch to another tab.
I have already change the eclipse.ini to
more eclipse.ini
-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.jee.product
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=512m
-Xms128m
-Xmx1024m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
Is there any way to make eclipse 3.5 more speedy?
Thank you.
I switched this line in the eclipse.ini file (found inside the eclipse application package):
-Dosgi.requiredJavaVersion=1.5
to
-Dosgi.requiredJavaVersion=1.6
and tab switching was speedy again.
Go with the 32-bit Cocoa release. The 64-bit won't help IMHO. It really works great on my 2.4 GHz MBP. I usually have about 30 files open, some fairly large, never experienced what you describe.
Try to get a new plain-vanilla 32-bit Cocoa distro, don't modify anything and check if there's an issue. It could be a rogue plugin, too. Do you have any installed?
Check you heap status. Open the Eclipse preferences, in the very first preferences page there's a "show heap status" option. You might be running low on memory. Check the swap status of your machine using the activity monitor - if it swaps a lot I'd recommend shutting down other applications. In general, I recommend 4 GB RAM for development machines.
I know this is kind of late to the game, but I found that changing the permissions to ~workspace.metadata.plugins\org.eclipse.e4.workbench to deny myself access stopped the slow-down issue.
Seems that Eclipse (4.2.0) writes out a corrupt settings file every so often, and when it's loaded in at startup again it slows everything down as it's constantly throwing errors internally. Changing the security on that directory so that Eclipse can't write to it is a kind of "fix"! It does mean that each time Eclipse is started it's back to its default settings, but if speed is more important, I think it's a worthwhile sacrifice.
There are now patches for Juno to begin addressing this issue. See comment #212 on bug 385272 for information on how to update your installation. If you wait a little longer you should find these fixes in the Kepler milestone on 12/21/2012.
(I believe the other suggestions posted here, e.g. increasing memory or tweeking various startup params or prefs might have some positive effect on performance, but the underlying problem is threads run amok as described in the bug report.)
This might be the bug that was referred to. https://bugs.eclipse.org/bugs/show_bug.cgi?id=282229
switching to 1.6 really helps.
This is the link to locate eclipse.ini file for mac
http://wiki.eclipse.org/Eclipse.ini
This eclipse bug report is spot-on with the behavior you describe. (I had the same experience using a new Juno installation on a beefy XP machine.)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=385272
The most useful part of the bug report was in comment 29, which suggests creating a new workspace. The easiest way to do this is:
1) exit eclipse
2) rename .../path/to/workspace/.metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi
(e.g., append ".old")
3) start eclipse
I believe changing -Dosgi.requiredJavaVersion=1.5 to 1.6 may help only incidentally, if at all.
Increase the memory limits in eclipse.ini seems to have fixed this for me - not sure if it will stay fixed though
FROM:
-vmargs
-Xms40m
-Xmx512m
TO
-vmargs
-XX:MaxPermSize=512m
-Xms256m
-Xmx784m
ALSO - if you came from aptana3 and imported your project - You need to do this
Click Project Properties
Go to "Builders"
Make sure there are no "Missing Builders" If there are, uncheck them - I had two left over from aptana when I imported my project (com.aptana.ide.core.unifiedBuilder AND com.aptana.editor.php.aptanaPhpBuilder)
---- UPDATE ----
It was fixed - but not for the reasons I thought. My SVN was no longer recognized by eclipse. As soon as I hit 'share with team' and reconnected it the tab-switching issues reappeared. I'm going to try and figure out if It's an svnKit vs JavaHL problem - I'm not sure which connector I picked when I setup eclipse this time.
If you want confirm this is your issue trying disconnecting from the SVN (Team->disconnect) and restarting eclipse
This is an known issue.
Since you are using JDK1.5, you can try the Carbon variant.
I experience the same issue using OS X 10.5.7 and Eclipse 3.5.2 on a fairly low end machine (early 2006 iMac with 1.5GB). Right after I start my machine however, everything is really snappy. I can even launch JBoss AS and there is still no slow-down. I monitor "Swap used" in activity monitor, and it stays at 0 bytes swap used.
Then, I launch something else, like iTunes and mail or switching to another account.
Things become slow then, which is expected, and I see "Swap used" increasing. Eclipse slows down to a crawl, and working with it is near to impossible.
Then I logout the other account, close down all other apps that I opened, so the state of my machine is basically the same again as when it was still fast. BUT... it stays dog slow! Even though I closed all the other apps, "Swap used" in activity monitor only decreases a little (from ~1.2GB to ~700MB). Just switching tabs between 2 very simple Java files takes up to 20 seconds, meanwhile I see in activity monitor that the CPU usage goes up to a solid 100%.
There definitely is something strange going on here. This does not seem like normal behavior. It is as-if Mac OS X goes into a 'slow mode' when I demand too much resources from it, but when the resources are there again it fails to recover.
Highly annoying!
If I reset the machine and open the exact same working set again (Eclipse with the same 2 files open, JBoss AS started in debug mode, Safari with 1 window) everything is really fast again.
I can now more or less confirm that the problem is really with Eclipse 3.5.
I've run Eclipse on a much more powerful Mac, a 27" core I7, 2.93Ghz with 8GB ram and a SSD running OS X 10.6.4. Initially this was extremely smooth and snappy, but after an up time of a dozen hours or so, Eclipse suddenly began to slow-down again. I had very little to almost nothing running in the background. Just Eclipse (32 bits, given it 1.5GB memory), JBoss AS and Safari.
A simple tab switch would take a few seconds and meanwhile I noticed the CPU load on one core going to 100%. The same happened with switching perspectives and various other operations.
When I restarted only Eclipse, everything was completely fast again. This happened a couple of times.
For me the issue was the SVNKit connection integration to the Juno version of Eclipse. I am doing Android Development using the Juno version of Eclipse and when I turned on the SVNKit Team Integration I got the following issues described:
Very slow switching between code files in the Eclipse IDE.
Extra large gap and space in the tool bar between the print and Android SDK Manager icons.
For me... I turned off the following settings under Window->Preferences->Team->SVN under the View Settings... there was a setting for "Show synchronize info incrementally"... I turned that off and the switching between files improved.... but there is still a delay versus NOT having SVN connected.
Without SVN connected... the switching between files is normal.
I had Java 1.6 in the Eclipse.ini
I did not change the settings for memory.
TL;DR for the bug thread:
http://wiki.eclipse.org/Platform_UI/Juno_Performance_Investigation#Resolution
Worked for me.
The original problem of slow switching between tabs has reappeared in Eclipse Neon (4.6.2 only?) using the Dark theme.
Solution: disable themed scrollbars in e4-dark_win.css (bottom of file):
StyledText {
swt-scrollbar-themed: false;
[...]