Starting with the assumption that most applications can trust the JVM to automatically pick the right garbage collection and memory pool sizing strategy, Sun engineer Stefan Schneider nevertheless thinks it's still important for developers to have a strong grasp of HotSpot's GC and memory management concepts. Schneider wrote up a short primer on these subjects in A short Primer to Java Memory Pool Sizing and Garbage Collectors.

After describing the various stages of generational GC, Schneider writes that,

The entire tuning of these pools is based on [a few] principles:

• The new generation should be large enough to keep all temporary objects until they are getting dereferenced.
• The old generation should host all permanent objects
• Young generation garbage collections (GC) are unavoidable. Their run time typically grows with the number of objects.
• The young generation GC is typically cheap compared to the old generation GC
• Old generation GC should be avoided. They're needed to clean up objects which aren't permanent, yet they slipped through the young generation GC.

The best way to get a feeling for these decisions is to get a quantitative understanding of the application by attaching visualgc or a jconsole...

Visualgc ... allows me to understand the state of the VM with one look while passing by a monitor. Jconsole or the Netbeans 6.0 profilers are the tools for a deeper understanding.

Scheider then presents a 30-minute screencast of JVM tuning using those two tools, exploring in visual detail scenarios such as:

• An undersized VM with not enough memory
• A VM with an increased old generation and a to small young generation
• A VM setup with parallel new generation and mostly concurrent garbage collections
• A VM sized as before yet with an increased young generation
• A well sized VM with increased threshold levels for survivor space with a short jconsole demo

What are your favorite tools for monitoring JVM GC?