By jonthecollector on Nov 01, 2011
When I use the term iCMS, I'm referring to the incremental mode of CMS (-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode). This is a mode of CMS where the concurrent phases (concurrent marking and concurrent sweeping) are run in short increments (does some work, yields and sleeps for a while, then runs again). It was implemented in CMS primarily for use on platforms with a single hardware thread. The concurrent phases are typically long (think seconds and not milliseconds). If CMS hogged the single hardware thread for several seconds, the application would not execute during those several seconds and would in effect experience a stop-the-world pause. With iCMS the application makes progress during concurrent phases. That of course is good. The down side is that there is more overhead to iCMS (e.g., all that stopping and starting), more floating garbage (objects that die during a CMS collection that we can't tell have died until the next collection) and more flags to tune (just what you wanted, right). Also it's just more complex (more things to go wrong). We put quite a bit of effort into teaching iCMS how to do the work in pieces and still finish the collection before the heap fill up, but it's not perfect. Are you using iCMS? Does your platform only have one hardware thread? Ok, maybe two hardware threads is reason enough if you don't want half your cycles eaten by CMS during a long concurrent phases. But, otherwise, I'd suggest you try without the incremental mode. There are exceptions to every rule, but I think you'll be happier. Really.