A garbage collector is responsible for
- Allocating memory
- Ensuring that any referenced objects remain in memory
- Recovering memory used by objects that are no longer reachable from references in executing code.
The process of locating and removing those dead objects can stall your Java application while consuming as much as 25 percent of throughput.
GC provided by Hotspot VM is a generational GC[9,16,18]—memory is divided into generations, that is, separate pools holding objects of different ages. The design is based on the Weak Generational Hypothesis:
This separation into generations has proven effective at reducing garbage collection pause times and overall costs in a wide range of applications. Hotspot VM divides its heap space into three generational spaces:
- Young Generation
- When a Java application allocates Java objects, those objects are allocated in the young generation space
- Is typically small and collected frequently
- The garbage collection algorithm chosen for a young generation typically puts a premium on speed, since young generation collections are frequent.
- Old Generationn
- Objects that are longer-lived are eventually promoted, or tenured, to the old generation
- Is typically larger than the young generation, and its occupancy grows more slowly
- The old generation is typically managed by an algorithm that is more space efficient, because the old generation takes up most of the heap and old generation algorithms have to work well with low garbage densities.
- Permanent Generation
- Holds VM and Java class metadata as well as interned Strings and class static variables
- Note that PermGen will be removed from Java heap in JDK 8.
Minor vs Full GC
A garbage collection occurs when any one of those three generational spaces is considered full and there is some request for additional space that is not available. There are two types of garbage collection activities: minor and full. young generation fills up, it triggers a minor collection in which the surviving objects are moved to the old generation. When the old generation fills up, it triggers a full collection which involves the entire object heap.When the
- Occurs when the young generation space does not have enough room
- Tends to be short in duration relative to full garbage collections
- When the old or permanent generation fills up, a full collection is typically done.
- A Full GC can
also be started explicitly by the application using System.gc()
- Takes a longer time depending upon the heap size. However, if it takes longer than 3 to 5 seconds, then it's too long.
- From the system side
- You should use as large a heap size as possible without causing your system to "swap" pages to disk. Typically, you should use 80 percent of the available RAM (not taken by the operating system or other processes) for your JVM.
- The larger the Java heap space, the better the garbage collector and application perform when it comes to throughput and latency.
- From the application side
- A reduction in object allocations, more importantly, object retention helps reduce the live data size, which in turn helps the GC and application to perform.
- Read this article -- Java Performance Tips .
The dreaded OutOfMemoryError is something that no Java programmer ever wishes to see. Yet it can happen, particularly if your application involves a large amount of data processing, or is long lived.
The total memory size of an application includes:
- Java heap size
- Thread stacks
- I/O buffers
- Memory allocated by native libraries
If an application runs out of memory and JVM GC fails to reclaim more object spaces, an OutOfMemoryError exception will be thrown. An OutOfMemoryError does not necessarily imply a memory leak. The issue might simply be a configuration issue, for example if the specified heap size (or the default size if not specified) is insufficient for the application.
JVM Command Options
Whether running a client or server application, if your system is running low on heap and spending a lot of time with garbage collection you'll want to investigate adjusting your heap size. You also don't want to set your heap size too large and impact other applications running on the system.
GC tuning is non-trivial. Finding the optimal generation space sizes involves an iterative process[3,10,12]. Here we assume you have successfully identified the optimal heap space sizes for your application. Then you can use the following JVM command options to set them:
|GC Command Line Options||Description|
|Sets the maximum|
As a final note, ergonomics for servers was first introduced in Java SE 5.0. It has greatly reduced application tuning time for server applications, particularly with heap sizing and advanced GC tuning. In many cases no tuning options when running on a server is the best tuning you can do.
- Tuning Java Virtual Machines (JVMs)
- Diagnosing Java.lang.OutOfMemoryError
- Java Performance by Charlie Hunt and Binu John
- Java HotSpot VM Options
- GCViewer (a free open source tool)
- Comparison Between Sun JDK And Oracle JRockit
- Java SE 6 Performance White Paper
- F&Q about Garbage Collection
- Hotspot Glossary of Terms
- Memory Management in the Java HotSpot Virtual Machine White Paper
- Java Hotspot Garbage Collection
- FAQ about GC in the Hotspot JVM (with good details)
- Java Heap Sizing: How do I size my Java heap correctly?
- Java Tuning White Paper
- JRockit JVM Heap Size Options
- Pick up performance with generational garbage collection
- Which JVM?
- Memory Management in the Java HotSpot™ Virtual Machine
- Java Performance Tips
- A Case Study of java.lang.OutOfMemoryError: GC overhead limit exceeded
- HotSpot—java.lang.OutOfMemoryError: PermGen space