comments

I have a few observations and heuristics from my experience tuning the Java GC I would like to share, while the topic is fresh in the minds of the  JUG members from this week's great presentation by Mike Richardson on the topic. It would be great if  you can post this note.

I did some GC data collection, analysis, and tuning, on a project that was a typical J2EE architecture, used EJBs in the middle tier, and Struts in the web tier.

My findings and heuristics are as follows:

Objectives of GC analysis and Tuning:

1. Try not to have a major GC at all, or a a major GC every one or two hours only. So you either don't have "stop the world", or have it very infrequently.
2. Decide what your tolerance for a minor GC time is. Can you tolerate 10 seconds, 20, or 30? Less or more? That's one of your NFRs that you have to decide on.

From there you need heuristics and measurements of actual behavior under load. Either do a real load test under realistic conditions, or write a multi-threaded simulator (good job for Groovy!) that simulates the major use cases. You would need to know the behavior of your major use cases well, to simulate memory footprint - without going through the complexities of the application. Either of these would do but you need to determine the application behavior metrics.

The two vital numbers you need are:

1. Object creation rate - to size Eden area
2. Object survival rate  - to size Tenured area