Eclipse 3.5.1 uses lot of memory

Question

Hi,

I have migrated to Eclipse 3.5.1 and observed it is taking 560 mb when doing clean build. And memory is not getting collected after used. It stays like this.

Any solution to this?

JVM : jdk1.6.0_17 Windows XP, 2GM RAM

Below is my eclipse.ini

-showlocation
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
384m
-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-vm
C:/Program Files/Java/jre6/bin/client/jvm.dll
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms128m
-Xmx384m
-Xss4m
-XX:PermSize=128m
-XX:MaxPermSize=384m
-XX:CompileThreshold=5
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-Dcom.sun.management.jmxremote
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jaydeep/Ericsson/eclipse_galileo/eclipse/dropins

Jaydeep.

Answer 1

That doesn't sound like an inordinate amount of memory. How large is the project your are building?

Also, the memory may be freed within the JVM (I.e. it will be available for other Java processes) but it will not be returned to the OS until the JVM (Eclipse) shuts down.

Answer 2

AFAIK a java virtual machine won't give up its reserved heap size once it has increased. I see in your parameters, your PermSize has the potential of being 384Mb and your Heap size up to 384Mb, which means your virtual machine can grow up to 768Mb -- and stay there (I'm not 100% sure if stack space gets added to that as well).

I'm afraid eclipse is just a monster. If you need to make it lighter, maybe try and remove plugins you don't need.

If you're worried about "memory leaks", you can see exactly how much space is being used by the different internal memory heaps by using "jstat".

Answer 3

Some time back I had problems with memory usage when building a very large project. I was never able to prove it definitively, but I came to the conclusion that Eclipse was using a lot of space to represent compilation warnings. Try turning off all Java compiler warnings and doing a rebuild and see if that makes any difference.

Answer 4

Do you know for sure that the heap isn't being garbage collected? Try enabling the "heap status" in the status bar (enable it in the preferences) and watch if the actual used memory ever goes down (you can click on the widget to set a reference marker).

Eclipse in general loves to eat memory, but some plugins are more memory-hungry than others. If you've installed any extensions, try uninstalling them one by one to see if there's a smoking gun.

One of my current projects eats upwards of 1.6 GB during a build. It's just something we've had to live with, really...

Answer 5

I have spent a lot of time looking at Eclipse-related memory issues particularly with Eclipse 3.2 and the infamous PermGen problem.

A few things that may make a difference:

1) Drop the amount of memory used for the initial heap size: -Xms40m instead of -Xms128m. 2) Don't set a minimum PermGen size: remove -XX:PermSize=128m

1&2 will reduce the initial amount of space you need.

3) Don't start up the help system - loading the documentation plug-ins uses a lot of memory, which never gets eliminated. 4) Use the Preferences/General/Startup and Shutdown page to deselect plug-ins that you don't need when Eclipse starts up.

3&4 will keep the memory usage from growing too early.

5) If you don't need the Max PermGen and Max Heap as large as they are, consider setting them lower until/unless you have an error/crash reflecting either of these. Running out of PermGen will generally crash the JVM and dump a log file in the configuration folder, while heap errors will be reported to the normal .log file.

Having addressed these, you will likely still see the Windows memory grow over time without being released, though the JVM may not use everything it has available at any given time. The task manager shows how much the JVM has available to it, while the Java memory can usually be monitored via jconsole (distributed with the JDK) and will usually be less.

Hope that helps.