Eclipse eclipse.ini memory params

I noticed a slight lag in my Eclipse (Juno) instance while working on some simple tutorials.  It could be: artificially low heap space in the eclipse.ini file, actual starvation due to too many user processes, or some bug in the way Eclipse handles project files. Realizing that I have dozens of links open in Chrome, some word docs, pdfs, photoshop, etc, it's probably the first two.  I'm not downloading or copy/pasting anything, so it can't be the OSX Spotlight indexing service (which has creeped up in the past after the completion of torrents with many files).  I'm using an i7 MacBook with 16 GB RAM, so I'm thinking Eclipse really shouldn't be lagging.  Time to investigate.

Like at work before, I thought of modifying the JVM args for Eclipse: Eclipse startup memory settings (Mac), specifically these:-
XX:MaxPermSize=512m
-Xms256m
-Xmx2048m
-XX:+UseParallelGC

Before saving it and moving on with life, I looked up Parallel GC, and found that it is one of a just a few garbage collectors, all of which behave slightly differently (how often they kick in [pause your application] and for how long) based on what part of JVM memory (generations: "memory pools holding objects of different ages") and how they collect it (internal algorithm), as listed on this (Jon Masamitsu's) Oracle blog article: Our Collectors:

• Serial" is a stop-the-world, copying collector which uses a single GC thread.
• "ParNew" is a stop-the-world, copying collector which uses multiple GC threads. It differs from "Parallel Scavenge" in that it has enhancements that make it usable with CMS. For example, "ParNew" does the synchronization needed so that it can run during the concurrent phases of CMS.
• "Parallel Scavenge" is a stop-the-world, copying collector which uses multiple GC threads.
• "Serial Old" is a stop-the-world, mark-sweep-compact collector that uses a single GC thread.
• "CMS" is a mostly concurrent, low-pause collector.
• "Parallel Old" is a compacting collector that uses multiple GC threads. Using the -XX flags for our collectors for jdk6,
  
• UseSerialGC is "Serial" + "Serial Old"
• UseParNewGC is "ParNew" + "Serial Old"
• UseConcMarkSweepGC is "ParNew" + "CMS" + "Serial Old". "CMS" is used most of the time to collect the tenured generation. "Serial Old" is used when a concurrent mode failure occurs.
• UseParallelGC is "Parallel Scavenge" + "Serial Old"
• UseParallelOldGC is "Parallel Scavenge" + "Parallel Old"

The article also mentioned that if you want to use "GC Ergonomics" (further tuning params, mostly for large heaps spread accross many processors), then you should use UseParallelGC and UseParallelOldG, and that it will not work with useConcMarkSweepGC.

Quickly reading the list of GCs and their usable combinations (on Masamitsu's blog) leads me to believe that UseConcMarkSweepGC is a good general purpose candidate as it causes smaller pauses in your application, where as other concurrent collectors cause longer pauses after longer times (also mentioned here).

These are the params I went with:
-XX:MaxPermSize=512m
-Xms256m
-Xmx2048m
-XX:+UseConcMarkSweepGC

In activity monitor, double clicking Eclipse shows:

Note, the actual allocated VM to the Eclipse process is higher than 2048m. This was consistent when I increased Xmx to 4096m, observing 7.05GB allocated. In retrospect, the lag was likely due to 'too many windows open', though, with 16GB of RAM, I wonder why such lag would occur at all anymore. Its not like I'm working on a giant project in eclipse with some large amount of in-memory data. So far so good, though I did close many tabs in Chrome.

Links
Eclipse startup memory settings (Mac) - Finding eclipse.ini on OSX
Our Collectors - Jon masamitsu's blog at Oracle
GC Ergonomics - Oracle tutorial on fine tuning GCs
Java SE 6 HotSpot[tm] Virtual Machine Garbage Collection Tuning - Oracle's primer on GC; good read
FAQ How do I run Eclipse?
FAQ How do I increase the permgen size available to Eclipse?

Stackoverflow questions:
Java Concurrent and Parallel GC
Difference between -XX:UseParallelGC and -XX:+UseParNewGC