Here's what I use (though I have them in the shortcut instead of the settings file):
eclipse.exe -showlocation -vm "C:\Java\jdk1.6.0_07\bin\javaw.exe" -vmargs -Xms256M -Xmx768M -XX:+UseParallelGC -XX:MaxPermSize=128M
XX:+UseParallelGC that's the most awesome option ever!!!
Here's my own setting for my Eclipse running on i7 2630M 16GB RAM laptop, this setting has been using for a week, without a single crashing, and Eclipse 3.7 is running smoothly.
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms1024m
-Xmx4096m
-XX:MaxPermSize=256m
Calculations: For Win 7 x64
You can also try running with JRockit. It's a JVM optimized for servers, but many long running client applications, like IDE's, run very well on JRockit. Eclipse is no exception. JRockit doesn't have a perm-space so you don't need to configure it.
It's possible set a pause time target(ms) to avoid long gc pauses stalling the UI.
-showsplash
org.eclipse.platform
-vm
C:\jrmc-3.1.2-1.6.0\bin\javaw.exe
-vmargs
-XgcPrio:deterministic
-XpauseTarget:20
I usually don't bother setting -Xmx and -Xms and let JRockit grow the heap as it sees necessary. If you launch your Eclipse application with JRockit you can also monitor, profile and find memory leaks in your application using the JRockit Mission Control tools suite. You download the plugins from this update site. Note, only works for Eclipse 3.3 and Eclipse 3.4
If you're going with jdk6 update 14, I'd suggest using using the G1 garbage collector which seems to help performance.
To do so, remove these settings:
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
and replace them with these:
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
Settings for Sun/Oracle java version "1.6.0_31" and Eclipse 3.7 running on x86-64 Linux:
-nosplash
-vmargs
-Xincgc
-Xss500k
-Dosgi.requiredJavaVersion=1.6
-Xms64m
-Xmx200m
-XX:NewSize=8m
-XX:PermSize=80m
-XX:MaxPermSize=150m
-XX:MaxPermHeapExpansion=10m
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseParNewGC
-XX:+CMSConcurrentMTEnabled
-XX:ConcGCThreads=2
-XX:ParallelGCThreads=2
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=0
-XX:CMSIncrementalDutyCycle=5
-XX:GCTimeRatio=49
-XX:MaxGCPauseMillis=20
-XX:GCPauseIntervalMillis=1000
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSClassUnloadingEnabled
-XX:+DoEscapeAnalysis
-XX:+UseCompressedOops
-XX:+AggressiveOpts
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Note that this uses only 200 MB for the heap and 150 MB for the non-heap. If you're using huge plugins, you might want to increase both the "-Xmx200m" and "-XX:MaxPermSize=150m" limits.
The primary optimization target for these flags has been to minimize latency in all cases and as a secondary optimization target minimize the memory usage.
-showlocation
To make it easier to have eclipse running twice, and know which workspace you're dealing with
Eclipse 3.6 adds a preferences option to specify what to show for the Workspace name (shown in window title)
which works much better than -showlocation
for three reasons:
Eclipse likes lots of RAM. Use at least -Xmx512M. More if available.
My own settings (Java 1.7, modify for 1.6):
-vm
C:/Program Files (x86)/Java/jdk1.7.0/bin
-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20100628
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-server
-Dosgi.requiredJavaVersion=1.7
-Xmn100m
-Xss1m
-XgcPrio:deterministic
-XpauseTarget:20
-XX:PermSize=400M
-XX:MaxPermSize=500M
-XX:CompileThreshold=10
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UnlockExperimentalVMOptions
-XX:+DoEscapeAnalysis
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
-XX:+AggressiveOpts
-Xms512m
-Xmx512m
-vm
C:\Program Files\Java\jdk1.6.0_07\jre\bin\client\jvm.dll
To specify which java version you are using, and use the dll instead of launching a javaw process
If youre like me and had problems with the current Oracle release of 1.6 then you might want to update your JDK or set
-XX:MaxPermSize. More information is available here: http://java.dzone.com/articles/latest-java-update-fixes
For more recent settings, see Eclipse Galileo 3.5 settings above.
The best JVM setting always, in my opinion, includes the latest JDK you can find (so for now, jdk1.6.0_b07 up to b16, except b14 and b15)
Even with those pretty low memory settings, I can run large java projects (along with a web server) on my old (2002) desktop with 2Go RAM.
-showlocation
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256M
-framework
plugins\org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar
-vm
jdk1.6.0_10\jre\bin\client\jvm.dll
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms128m
-Xmx384m
-Xss2m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:CompileThreshold=5
-Dcom.sun.management.jmxremote
See GKelly's SO answer and Piotr Gabryanczyk's blog entry for more details about the new options.
You can also consider launching:
C:\[jdk1.6.0_0x path]\bin\jconsole.exe
As said in a previous question about memory consumption.
If you are using Linux + Sun JDK/JRE 32bits, change the "-vm" to:
-vm
[your_jdk_folder]/jre/lib/i386/client/libjvm.so
If you are using Linux + Sun JDK/JRE 64bits, change the "-vm" to:
-vm
[your_jdk_folder]/jre/lib/amd64/server/libjvm.so
That's working fine for me on Ubuntu 8.10 and 9.04
Currently (November 2009), I am testing with jdk6 update 17 the following configuration set of options (with Galileo -- eclipse 3.5.x, see below for 3.4 or above for Helios 3.6.x):
(of course, adapt the relative paths present in this eclipse.ini to the correct paths for your setup)
Note: for eclipse3.5, replace startup
and launcher.library
lines by:
-startup
plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-data
../../workspace
-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
../../../../program files/Java/jdk1.6.0_17/jre/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:/jv/eclipse/mydropins
See also my original answer above for more information.
org.eclipse.equinox.p2.reconciler.dropins.directory
option.There was a bug with ignored breakpoints actually related to the JDK.
Do use JDK6u16 or more recent for launching eclipse (You can then define as many JDKs you want to compile within eclipse: it is not because you launch an eclipse with JDK6 that you will have to compile with that same JDK).
Note the usage of:
--launcher.XXMaxPermSize
384m
-vmargs
-XX:MaxPermSize=128m
As documented in the Eclipse Wiki,
Eclipse 3.3 supports a new argument to the launcher:
--launcher.XXMaxPermSize
.
If the VM being used is a Sun VM and there is not already a-XX:MaxPermSize=
VM argument, then the launcher will automatically add-XX:MaxPermSize=256m
to the list of VM arguments being used.
The 3.3 launcher is only capable of identifying Sun VMs on Windows.
As detailed in this entry:
Not all vms accept the
-XX:MaxPermSize
argument which is why it is passed in this manner. There may (or may not) exist problems with identifying sun vms.
Note: Eclipse 3.3.1 has a bug where the launcher cannot detect a Sun VM, and therefore does not use the correct PermGen size. It seems this may have been a known bug on Mac OS X for 3.3.0 as well.
If you are using either of these platform combination, add the-XX
flag to theeclipse.ini
as described above.Notes:
- the "
384m
" line translates to the "=384m
" part of the VM argument, if the VM is case sensitive on the "m
", then the so is this argument.- the "
--launcher.
" prefix, this specifies that the argument is consumed by the launcher itself and was added to launcher specific arguments to avoid name collisions with application arguments. (Other examples are--launcher.library
,--launcher.suppressErrors
)The
-vmargs -XX:MaxPermSize=384m
part is the argument passed directly to the VM, bypassing the launcher entirely and no check on the VM vendor is used.
-startup
../../../plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.1.100.v20110502
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Xms128m
-Xmx512m
-XX:MaxPermSize=256m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Dcom.sun.management.jmxremote
-Declipse.p2.unsignedPolicy=allow
And these setting have worked like a charm for me. I am running OS X10.6 , Eclipse 3.7 Indigo , JDK1.6.0_24
If you are using Linux + Sun JDK/JRE 32bits, change the "-vm" to:
-vm
[your_jdk_folder]/jre/lib/i386/client/libjvm.so
If you are using Linux + Sun JDK/JRE 64bits, change the "-vm" to:
-vm
[your_jdk_folder]/jre/lib/amd64/server/libjvm.so
That's working fine for me on Ubuntu 8.10 and 9.04
Source: Stackoverflow.com