Eclipse Zone is brought to you in partnership with:

Michael has posted 1 posts at DZone. View Full User Profile

Turbo Charging Eclipse

  • submit to reddit

I primarily use CFEclipse, Mylyn, and Subclipse but started using Flex and getting an OutOfMemoryException.  I am not a JVM options expert, but I referenced several articles.  These settings are suggestions and you may need adjust them. I changed my eclipse.ini file around after researching some JVM option settings.

Before modifying the eclipse.ini file please back it up.  The ini file can be error prone with returns and spaces.  My simple test shows an improvement in times. I would note the ThreadPriortyPolicy as stated in the desciption in might cause performance degragation so do some testing with it.

If someone knows how to test and benchmark Eclipse startup and performance better I would be interested in learning how.


What the options/settings do?

These explainations are from the articles listed below

  • -XX:+AggressiveHeap

    The -XX:+AggressiveHeap option inspects the machine resources (size of memory and number of processors) and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs. It was originally intended for machines with large amounts of memory and a large number of CPUs, but in the J2SE platform, version 1.4.1 and later it has shown itself to be useful even on four processor machines. With this option the throughput collector (-XX:+UseParallelGC) is used along with adaptive sizing (-XX:+UseAdaptiveSizePolicy). The physical memory on the machines must be at least 256MB before AggressiveHeap can be used. The size of the initial heap is calculated based on the size of the physical memory and attempts to make maximal use of the physical memory for the heap (i.e., the algorithms attempt to use heaps nearly as large as the total physical memory).

  • UseAdaptiveSizePolicy

    A feature available with the throughput collector in the J2SE platform, version 1.4.1 and later releases is the use of adaptive sizing (-XX:+UseAdaptiveSizePolicy), which is on by default. Adaptive sizing keeps statistics about garbage collection times, allocation rates, and the free space in the heap after a collection. These statistics are used to make decisions regarding changes to the sizes of the young generation and tenured generation so as to best fit the behavior of the application. Use the command line option -verbose:gc to see the resulting sizes of the heap.

  • UseParallelGC    

    Use the Parallel Scavenge garbage collector

  • UseParallelOldGC

    Use the Parallel Old garbage collector

  • -XX:+AggressiveOpts

    Turns on point performance optimizations that are expected to be on by default in upcoming releases. The changes grouped by this flag are minor changes to JVM runtime compiled code and not distinct performance features (such as BiasedLocking and ParallelOldGC). This is a good flag to try the JVM engineering team's latest performance tweaks for upcoming releases. Note: this option is experimental! The specific optimizations enabled by this option can change from release to release and even build to build. You should reevaluate the effects of this option with prior to deploying a new release of Java.

  • ParallelGCThreads

    Number of parallel threads parallel gc will use

  • ThreadPriorityPolicy

    0 : Normal. VM chooses priorities that are appropriate for normal applications. On Solaris NORM_PRIORITY and above are mapped to normal native priority. Java priorities below NORM_PRIORITY" map to lower native priority values. On Windows applications" are allowed to use higher native priorities. However, with ThreadPriorityPolicy=0, VM will not use the highest possible" native priority, THREAD_PRIORITY_TIME_CRITICAL, as it may interfere with system threads. On Linux thread priorities are ignored because the OS does not support static priority in SCHED_OTHER scheduling class which is the only choice for" non-root, non-realtime applications. 1 : Aggressive. Java thread priorities map over to the entire range of native thread priorities. Higher Java thread priorities map to higher native thread priorities. This policy should be used with care, as sometimes it can cause performance degradation in the application and/or the entire system. On Linux this policy requires root privilege.


I am using a crude benchmark test against my Windows XP laptop using eclipse java -jar startup.jar -debug

 turbo-charged eclipse.ini eclipse-SDK-3.3.2-win32  eclipse.ini 
Time to load bundles15161615
Starting application6406251094938
Application Started56405641103288245







I did this test on my Ubuntu laptop with similiar improvements. You might find it useful look at the Tuning Eclipse Performance and Avoiding OutOfMemoryExceptions on EclipseZone for further reference.

Links used for gathering information on the settings



Published at DZone with permission of its author, Michael Henke. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Christopher Brind replied on Thu, 2008/05/01 - 2:31am

I use the same version of Eclipse, Flex Builder 3 Professional, Subclipse, WTP and a couple of plugins I've written myself. I have Mylyn installed but to be honest I don't use it so I doubt those plugins even get loaded. My workstation is a Dell Precision M4300 laptop with 2gb of RAM.

My workspace has about 30 projects open at any one time; a mix of OSGi Bundles/Eclipse Plugins/Flex Projects.

I've never had any OutOfMemory problems and never had to tweak my eclipse.ini. I will be now though, just to see if it's any faster, but I've never had any perceived speed problems either so it will be a nice bonus if it does appear faster.

I'd be interested to know what other plugins you're using.

Did you do a completely fresh install before installing the Flex Builder 3 Profession plugin?

Are you on 32bit XP? I had loads of problems with Eclipse on 64bit XP at my previous employer.

Christopher Brind replied on Thu, 2008/05/01 - 8:14am in response to: Christopher Brind

I tried your eclipse.ini and if anything I found Eclipse started slower - plus I couldn't actually be sure it was starting without using TaskManager since there was no splash.

After running Eclipse for about 3 hours I also observed a sudden and significant increase in CPU usage by Eclipse and usage of about 650mb of memory before eventually Eclipse bombed out without any warning.

Here's my eclipse.ini:


As far as I'm aware, that's the default and I've never had any problems.


Michael Henke replied on Thu, 2008/05/01 - 5:25pm

I didn't do a fresh install/clean option before installing Flex Builder but have after did a clean after.  The out of memory issue would occur when I was building/running a flex file.  I have tweaked my ini file before but never knew where to set the memory size so I like the AggresiveHeap.  It will be trial and error to see what works best.  The version of Java running will have an affect also.

Michael Henke replied on Tue, 2008/05/13 - 11:05am

I experienced the same unstableness, I isolated it to XX:+ AggressiveHeap.  I run aggressiveheap first then grab the max value. Remove the aggressheap option and set the max and min size.  Example -Xmx900m -Xms128m

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.