3 ms·
Jacob Kessler knows quite a bit about garbage collection :) Understanding the gc logs can be difficult. gcviewer is pretty good though at figuring it out. Alwa
by joshhart 14y ago
Jacob Kessler knows quite a bit about garbage collection :)
Understanding the gc logs can be difficult. gcviewer is pretty good though at figuring it out. Always remember that garbage collection is slowest whenever the JVM has to copy objects from one generation to another or between survivor spaces. The logs print the sizes of the young gen, old gen, and survivor spaces. Sometimes after a collection you can see the sizes of these change dramatically - that means a big object has moved around. You can either change your code to use big objects less often or hold onto them for a shorter time or try to increase your survivor space size or new gen size.
A major, major, major thing you are missing is -XX:+UseParNewGC. With the CMS collector, your new gen collection can be done in parallel, and the parallelization scales very well with the number of cores. Without ParNewGC, the service I work on would take over 1 second to garbage collect. With ParNewGC, it only takes 50ms.
- cagenut 14y agoAccording to my notes from when I first put that together -XX:+UseParNewGC is automatically implied by +UseConcMarkSweepGC, for which my source was this very old web page about a very old jvm version (again, dark art): http://cybergav.in/2010/01/11/tuning-hotspot-jvm-1-4-2-with-cms-low-pause-garbage-collector/ http://cybergav.in/2010/01/11/tuning-hotspot-jvm-1-4-2-with-... Also, more concretely, this is the most frequent type of entry in my gc log: http://pastie.org/pastes/7142036/text?key=dkwvlvaaysk63rcajbp2na http://pastie.org/pastes/7142036/text?key=dkwvlvaaysk63rcajb... I (perhaps wrongly?) interpret the ParNew there to imply that's the young gen collector in use.