Understanding JVM Garbage Collection Performance Goals: Latency, Throughput, and Footprint
👨💻 Associate Software Engineer at Motadata ⭐ CodeChef 4★ | Java, JavaScript, Golang 🌐 Network Monitoring & Observability ⚡ Reactive Java (Vert.x) | 🎓 DDIT Graduate
Garbage Collection (GC) is one of the most important components of the Java Virtual Machine (JVM). It automatically manages memory by reclaiming objects that are no longer in use. While GC simplifies memory management for developers, it also has a significant impact on application performance.
When tuning GC for production systems, engineers usually focus on three major performance goals:
Latency
Throughput
Footprint
However, it is practically impossible to optimize all three at the same time. Understanding their trade-offs is essential for building high-performance Java applications.
1. Latency — Pause Time of Your Application
Latency in GC refers to the pause time introduced by garbage collection. When GC runs, application threads are paused (Stop-The-World) so that memory can be safely reclaimed.
Latency has two important dimensions:
Mean Pause Time
This is the average duration of GC pauses over time.
Example:
If GC runs 100 times and the total pause time is 500 ms,
then the mean pause time is 5 ms.
Lower mean pause time keeps the application responsive and smooth.
Maximum Pause Time
This is the longest single pause caused by GC.
Even if most pauses are short, a single long pause can:
Cause API timeouts
Break real-time systems
Violate SLAs
In production systems, maximum pause time matters more than average pause time.
2. Throughput — Useful Work Done by the JVM
Throughput measures how much time the JVM spends doing useful application work versus garbage collection.
It is usually expressed as a percentage:
Throughput = (Application Time / Total Time) × 100
Example:
If your application runs for 100 seconds and GC consumes 5 seconds,
your throughput is 95%.
High throughput means:
More requests processed per second
Better CPU utilization
Faster batch processing
However, high throughput collectors may allow longer GC pauses.
3. Footprint — Memory Consumption
Footprint refers to how much memory the JVM needs to run your application efficiently.
A smaller footprint:
Uses less RAM
Reduces infrastructure cost
Improves startup time
But smaller heaps lead to:
More frequent GC cycles
Lower throughput
Higher CPU overhead
The Two-Out-Of-Three Principle
In practice, you can only optimize two out of three goals:
| Priority | Result | Trade-off |
| Latency + Throughput | Fast and responsive system | Higher memory usage |
| Latency + Footprint | Low memory and fast pauses | Lower system capacity |
| Throughput + Footprint | High capacity with small heap | Longer pauses |
This is known as the GC Performance Triangle.
Real-World Scenarios
Backend APIs and Microservices
These systems require:
Low latency for fast responses
High throughput for scale
Memory is relatively cheap, so footprint is less critical.
Best choice: Latency + Throughput
Embedded Systems and IoT Devices
These environments are memory constrained and require quick responses.
Best choice: Latency + Footprint
Batch Processing and ETL Jobs
These systems focus on processing massive volumes of data efficiently.
Best choice: Throughput + Footprint
Latency is less important.
Common Garbage Collectors and Their Focus
| Collector | Primary Goal |
| Parallel GC | Maximum throughput |
| G1 GC | Balanced |
| ZGC | Ultra-low latency |
| Shenandoah | Ultra-low latency |
Conclusion
Garbage Collection tuning is a balancing act. You cannot maximize latency, throughput, and footprint at the same time. Instead, you must understand your application’s workload and prioritize the two goals that matter most.
For most production backend systems, the ideal balance is:
High throughput with low latency, using memory as a trade-off.
Choosing the right GC and tuning strategy can dramatically improve system stability, scalability, and performance.
