Tuning Java's memory manager for high performance server applications

The idea

Java runs the data centre, and the memory manager is one of the few components of a JVM an administrator can genuinely tune. Both major virtual machines offered a choice of collectors and a long list of parameters — and enough complexity that the tuning was usually done by guesswork. The paper measures what those choices are worth on an application server workload.

What it did

• Assessed the garbage collection strategies of two popular virtual machines (Sun's 1.5 and IBM's), using both synthetic benchmarks and a real-world J2EE application benchmark.
• Reported heap occupancy and collection time across default, incremental and parallel collector configurations for each.
• Distilled the results into a checklist of generally applicable tuning guidelines.

What it found

Tuning is worth a great deal and does not transfer: the throughput configuration outperformed the default by 38% in raw transactions per second, with a faster mean response time, a lower error rate and 25% less total collection time — but the paper is emphatic that no recipe applies equally to all applications, and that the only valid tuning target is the application you actually care about. The incremental collector delivered what it promises, pauses under two seconds throughout, at the cost of throughput and considerably more memory.

The guidelines that follow are practical to the point of bluntness: understand the collector before touching it, use a synthetic benchmark only for hints, give the VM as much memory as you can and never let it swap, and measure your application's allocation rate and object size distribution before choosing a strategy.