GC Errata 2
By jonthecollector on Jan 10, 2008
Some users have reported occasional long pauses which occur at the time of a GC but cannot be accounted for by GC times. Such long pauses may be a symptom of a known latency in the use of (Linux's) mprotect() which is used by the JVM while steering application threads to so-called safepoints. A known workaround at the JVM level to step around the Linux mprotect() issue is the use of JVM option -XX:+UseMembar.
The real fix, unfortunately, lies in the Linux kernel; see http://bugzilla.kernel.org/show_bug.cgi?id=5493. You might wish to pursue this with your Linux support engineer and see if a patch is available for the problem.
To avoid running into this bug, make sure there is plenty of physical memory free in your system so that the Linux pager does not start evicting pages for any process from memory to swap.
If you're seeing large variations in your minor GC pauses and are using UseParNewGC (which is on by default with the low pause collector), you might be running into 6433335. A large variation is a factor of a 100. This is a bug that has to do with large objects (or large free blocks) in the heap. If you turn off UseParNewGC and see larger pauses (by a multiplier that is on the order of the number of cpu's) but more regular pauses, then 6433335 is a likely candidate. It's been fixed in jdk 1.4.2 update 14, jdk 5 update 10 and jdk 6 update 1.
I've heard of more than one report recently of crashes with the low-pause collector that were caused by bug
6558100 - CMS crash following parallel work queue overflow
This bug is fixed in 1.4.2u18, 5.0u14 and 6u4. You can workaround the bug with the flag -XX:-ParallelRemarkEnabled. You could also run into this bug if you explicitly enable ParallelRefProcEnabled, so if you include -XX:+ParallelRefProcEnabled, remove it. ParallelRefProcEnabled is off by default so if you don't explicitly turn it on, don't worry about it.
Starting in jdk6 the biased locking optimization is "on" by default (command line option UseBiasedLocking). This optimization reduces the cost of uncontended locks by treating the thread that owns the lock preferentially. It's a nice optimization but could increase the memory usage of the JVM.
If you move from jdk5 to jdk6 and start seeing messages such as
you could try turning off biased locking and see if it helps. Improvements in
biased locking were made in 6u1 to make this much less of a problem.
you could try turning off biased locking and see if it helps. Improvements in biased locking were made in 6u1 to make this much less of a problem.