> The main reason to set Xms=Xmx is so mlockall can tag the entire heap > as "don't swap this out" on startup. Secondarily whenever the heap > resizes upwards the JVM does a stop-the-world gc, but no, not really a > big deal when your uptime is in days or weeks.
I'm not sure where this is coming from, assuming you mean a *full* stw GC. I cannot remember ever observing this in "all my hears of heap growth ;)", and I don't see why it would be the case. Heap *shrinkage* on the other hand is another matter and for both CMS and G1, shrinkage never happens except on Full GC, unfortunately. I'm hoping G1 will eventually improve here since its compacting design should fundamentally make it feasible to implement efficiently. Disregarding the mlockall issue which is pretty specific to Cassandra, the typical reason, as I have understood it, for setting Xms=Xmx on machine dedicatedly running some particular JVM is that if you have to reserve Xmx amount of memory anyway, and perhaps even expect that to be reached, it is generally more efficiency to just let the JVM use it all from the start - due to the usual effect of GC being more efficient with larger heap sizes and in order to avoid bad policy decisions of the GC causing excessive GC activity rather than just growing the heap which you're fine with anyway. -- / Peter Schuller
