Updated 03.08.07: eclipse.ini is sensitive to which line break is used. See Eclipse bug#198823
Many users seem to have problems with running out of memory when using Eclipse 3.2 in combination with additonal plugins such as those from JBoss Tools or even Eclipse WTP.
For those who just want the solution scroll down to the bottom, you can skip my “rant” about it.
The Problem
Eclipse default memory settings (at least for Eclipse 3.2) is to run with the following memory settings specified in its eclipse.ini file:
-vmargs
-Xms40m
-Xmx256m
This is ok for most users, but users can tweak these settings by editing eclipse.ini or via the command line, e.g.
eclipse -vmargs -Xms128m -Xmx512m
This would give some more room for extra many open projects and/or using plugins that might need additional memory (e.g. query results when running HQL via Hibernate Tools).
So why am I blogging about this ?
Well, it turns out that the combination of a eclipse.ini’s weird syntax and Sun JVM’s ‘alternative’ memory handling can give alot of headache.
Eclipse.ini
eclipse.ini is a configuration file that is located in the root of your Eclipse installation which is used as the default arguments passed to Eclipse.
This is all nice, but it is so easy to make it have zero effect by doing what makes the most sense, namely putting all the arguments on a single line in your eclipse.ini:
-vmargs -Xms128m -Xmx512m
The above line is simply ignored (or just not parsed correctly) by eclipse and hence the JVM is just started with the Sun VM default memory settings and the user thinks everything is fine.
The *correct* way of using eclipse.ini is to put each command line argument on individual lines:
-vmargs
-Xms128m
-Xmx512m
The best way to know if your command line arguments actually has been passed in correctly is to go to Help/About [Product Name] and click “Configuration Details” and check that the property “eclipse.vmargs” contain the values you expected.
This is expected and *correct*:
eclipse.vmargs=-Xms512m
-Xmx512m
-jar
/opt/eclipse32-3.2.2/startup.jar
This is *not*:
eclipse.vmargs=-jar
/opt/eclipse32-3.2.2/startup.jar
And that is exactly what happens when you put everything on one line in .eclipse.ini, so be careful!
Sun JVM PermGen
Sun JVM’s has a concept of PermGen space that is a *seperate* allocated memory region that is used for e.g. allocating classes. This is actually the memory region most people have issues with and not so much the normal heap space, but as a normal user one have a hard time realizing this when eclipse (or rather the jvm) just says “Out of Memory” or simply just crashes.
The solution for this is to add a MaxPermSize value to the vmargs. e.g. I normally use -XX:MaxPermSize=128m to make sure I don’t run out of PermGen space.
The Solution
*shameless plug*: Get Red Hat Developer Studio when it is relased which does this automatically for you, or…
Increase the memory settings via command line or eclipse.ini:
Command line
eclipse -vmargs -Xms128m -Xmx512m -XX:MaxPermSize=128m
Eclipse.ini
The trick is to remember each argument has to be on seperate lines:
-vmargs
-Xms128m
-Xmx512m
-XX:MaxPermSize=128m
Other solutions
Use a JVM that uses the normal heap for PermGen-like allocations (that is any non-Sun JVM AFAIK)
or help out with reducing the memory footprint of your favorite plugins by running them through a profiler and report found issues or possibly even contribute patches to the Jira 
Related links
Igor’s blog about using jconsole to debug memory issues with Eclipse
Sun blog with nice explanation of PermGen and what might cause it in user code
Eclipse Program Launcher documentation
JBoss Tools/RHDS forum post that made me want to write this blog
