This document is a summary or outline of Sun's document: Tuning Garbage collection with the 1.4.2 Hotspot JVM located here: http://java.sun.com/docs/hotspot/gc1.4.2/
1.0 Introduction
- For many applications garbage collection performance is not significant
- Default collector should be first choice
2.0 Generations
- Most straightforward GC will just iterate over every object in the heap and determine if any other objects reference it.
- This gets really slow as the number of objects in the heap increase
- GC's therefor make assumptions about how your application runs.
- Most common assumption is that an object is most likely to die shortly after it was created: called infant mortality
- This assumes that an object that has been around for a while, will likely stay around for a while.
- GC organizes objects into generations (young, tenured, and perm) This is important!
2.1 Performance Considerations
- Ways to measure GC Performance
- Throughput – % of time not spent in GC over a long period of time.
- Pauses – app unresponsive because of GC
- Footprint – overall memory a process takes to execute
- Promptness – time between object death, and time when memory becomes available
- There is no one right way to size generations, make the call based on your applications usage.
2.2 Measurement
- Throughput and footprint are best measured using metrics particular to the application.
- Command line argument -verbose:gc output
[GC 325407K->83000K(776768K), 0.2300771 secs] - GC – Indicates that it was a minor collection (young generation). If it had said Full GC then that indicates that it was a major collection (tenured generation).
- 325407K – The combined size of live objects before garbage collection.
- 83000K – The combined size of live objects after garbage collection.
- (776768K) – the total available space, not counting the space in the permanent generation, which is the total heap minus one of the survivor spaces.
- 0.2300771 secs – time it took for garbage collection to occur.
- You can get more detailed output using -XX:+PrintGCDetails and -XX:+PrintGCTimeStamps
3 Sizing the Generations
- The -Xmx value determines the size of the heap to reserve at JVM initialization.
- The -Xms value is the space in memory that is committed to the VM at init. The JVM can grow to the size of -Xmx.
- The difference between -Xmx and -Xms is virtual memory (virtually committed)
3.1 Total Heap
- Total available memory is the most important factor affecting GC performance
- By default the JVM grows or shrinks the heap at each GC to keep the ratio of free space to live objects at each collection within a specified range.
- -XX:MinHeapFreeRatio – when the percentage of free space in a generation falls below this value the generation will be expanded to meet this percentage. Default is 40
- -XX:MaxHeapFreeRatio – when the percentage of free space in a generation exceeded this value the generation will shrink to meet this value. Default is 70
- For server applications
- Unless you have problems with pauses grant as much memory as possible to the JVM
- Set -Xms and -Xmx close to each other or equal for a faster startup (removes constant resizing of JVM). But if you make a poor choice the JVM can't compensate for it.
- Increase memory sa you increase # of processors because memory allocation can be parallelized.
3.2 The Young Generation
- The bigger the young generation the less minor GC's, but this implies a smaller tenured generation which increases the frequency of major collections.
- You need to look at your application and determine how long your objects live for to tune this.
- -XX:NewRatio=3 – the young generation will occupy 1/4 the overall heap
- -XX:NewSize – Size of the young generation at JVM init. Calculated automatically if you specify -XX:NewRatio
- -XX:MaxNewSize – The largest size the young generation can grow to (unlimited if this value is not specified at command line)
3.2.1 Young Generation Guarantee
- The -XX:SurvivorRatio option can be used to tune the number of survivor spaces.
- Not often important for performance
- -XX:SurvivorRatio=6 – each survivor space will be 1/8 the young generation
- If survivor spaces are too small copying collection overflows directly into the tenured generation.
- Survivor spaces too large uselessly empty
- -XX:+PrintTenuringDistribution – shows the threshold chosen by JVM to keep survivors half full, and the ages of objects in the new generation.
- Server Applications
- First decide the total amount of memory you can afford to give the virtual machine. Then graph your own performance metric against young generation sizes to find the best setting.
- Unless you find problems with excessive major collection or pause times, grant plenty of memory to the young generation.
- Increasing the young generation becomes counterproductive at half the total heap or less (whenever the young generation guarantee cannot be met).
- Be sure to increase the young generation as you increase the number of processors, since allocation can be parallelized.
4 Types of Collectors
- Everything to this point talks about the default garbage collector, there are other GC's you can use
- Throughput Collector – Uses a parallel version of the young generation collector
- -XX:+UseParallelGC
- Tenured collector is the same as in default
- Concurrent Low Pause Collector
- Collects tenured collection concurrently with the execution of the app.
- The app is paused for short periods during collection
- -XX:+UseConcMarkSweepGC
- To enable a parallel young generation GC with the concurrent GC add -XX:+UseParNewGC to the startup. Don't add -XX:+UseParallelGC with this option.
- Incremental Low Pause Collector
- Sometimes called Train Collector
- Collects a portion of the tenured generation at each minor collection.
- Tries to minimize large pause of major collections
- Slower than the default collector when considering overall throughput
- Good for client apps (my observation)
- -Xincgc
- Don't mix these options, JVM may not behave as expected.
4.1 When to use Throughput Collector
- Large number of processors
- Reduces serial execution time of app, by using multiple threads for GC
- App with lots of threads allocating objects should use this with a large young generation
- Server Applications (my observation)
4.2 The Throughput collector
- By default the throughput collector uses the number of CPU's as its value for number of GC threads.
- On a computer with one CPU it will not perform as well as the default collector
- Overhead from parallel execution (synchronization costs)
- With 2 CPU's the throughput collector performs as well as the default garbage collector.
- With more then 2 CPU's you can expect to see a reduction in minor GC pause times
- You can control the number of threads with -XX:ParallelGCThreads=n
- Fragmentation can occur
- Reduce GC threads
- Increase Tenured Generation size
4.2.1 Adaptive Sizing
- Keeps stats about GC times, allocation rates, and free space then sizes young and tenured generation to best fit the app.
- J2SE 1.4.1 and later
- -XX:+UseAdaptiveSizePolicy (on by default)
4.2.2 Aggressive Heap
- Attempts to make maximum use of physical memory for the heap
- Inspects computer resources (memory, num processors) and sets params optimal for long running memory allocation intensive jobs.
- Must have at least 256MB of RAM
- For lots of CPU's and RAM, but 1.4.1+ has shown improvements on 4-Way machines.
- -XX:+AggressiveHeap
4.3 When to use the Concurrent Low Pause Collector
- Apps that benefit from shorter GC pauses, and can share resources with GC during execution.
- Apps with large sets of long living data (tenured generation)
- Two or more processors
- Interactive apps with modest tenured generation size, and one CPU
4.4 The Concurrent Low Pause Collector
- Uses a separate GC thread to do parts of the major collection concurrently with the app threads.
- Pauses App threads in the beginning of a collection and toward the middle (longer pause in middle)
- The rest of the GC is in a single thread that runs at the same time as the app
4.4.1 Overhead of Concurrency
- Doesn't provide much of an advantage on single processor machines.
- Fragmentation can occur.
- Two processor machine eliminates pauses due to the GC thread.
- The more CPU's the advantages of concurrent collector increase.
4.4.2 Young Generation Guarantee
- There has to be enough contiguous space available in the tenured generation for all objects in the eden and one survivor space.
- A larger heap is needed compared to the default collector.
- Add the size of the young generation to the tenured generation.
4.4.3 Full Collections
- If the concurrent collector is unable to finish collecting the tenured generation before the tenured generation fills up, the application is paused and the collection is completed.
- When this happens you should make some adjustments to your GC params
4.4.4 Floating Garbage
- Floating Garbage – Objects that die while the GC is running (after they have been checked).
- Increase the tenured generation by 20% to reduce floating garbage.
4.4.5 Pauses
- First Pause – marks live objects – initial marking
- Second Pause – remarking phase – checks objects that were missed during the concurrent marking phase due to the concurrent execution of the app threads.
4.4.6 Concurrent Phases
- Concurrent Marking phase occurs between initial mark and remarking phase.
- Concurrent sweeping phase collects dead objects after the remarking phase.
4.4.7 Measurements with the Concurrent Collector
- Use -verbose:gc with -XX:+PrintGCDetails
- vCMS-initial-mark shows GC stats for the initial marking phase
- CMS-concurrent-mark – shows GC stats for concurrent marking phase.
- CMS-concurrent-sweep – shows stats for concurrent sweeping phase
- CMS-concurrent-preclean – stats for determining work that can be done concurrently
- CMS-remark – stats for the remarking phase.
- CMS-concurrent-reset – concurrent stuff is done, ready for next collection.
4.4.8 Parallel Minor Collection Options with Concurrent Collector
- -XX:+UseParNewGC – for multiprocessor machines, enables multi threaded young generation collection.
- -XX:+CMSParallelRemarkEnabled – reduce remark pauses
4.5 When to use the Incremental Low Pause Collector
- Use when you can afford to tradeoff longer and more frequent young generation GC pauses for shorter tenured generation pauses
- You have a large tenured generation
- Single Processor
4.6 The Incremental Low Pause Collector
- Minor collections same as default collector.
- Don't use try to use parallel GC with this collector
- Incrementally Collects parts of the tenured generation at each young collection.
- Tries to avoid long major collections by doing small chunks each minor collection.
- Can cause fragmentation of the heap. Sometimes need to increase tenured generation size compared to the default.
- There is some overhead required to maintain the position of the incremental collector. Less overhead than is required by the default collector.
- First try the default collector, and adjust heap sizing. If major pauses are too long try incremental.
- If the incremental collector can't collect the tenured generation fast enough you will run out of memory, try reducing the young generation.
- If young generation collections do not free any space, could be because of fragmentation. Increase tenured generation size.
4.6.1 Measurements with the Incremental Collector
- -verbose:gc and -XX:+PrintGCDetails
- Look for the Train: to see the stats for the incremental collection.
5 Other Considerations
- The permanent generation may be a factor on apps that dynamically generate and load many classes (JSP, CFM application servers)
- You may need to increase the MaxPermSize, eg: -XX:MaxPermSize=128m
- Apps that rely on finalization (finalize method, or finally clauses) will cause lag in garbage collection. This is a bad idea, use only for errorious situations.
- Explicit garbage collection calls (System.gc()) force a major collection. You can measure the effectiveness of these calls by disabling them with -XX:+DisableExplicitGC
- RMI garbage collection intervals can be controlled with
- -Dsun.rmi.dgc.client.gcInteraval=3600000
- -Dsun.rmi.dgc.server.gcInterval=3600000
- On Solaris 8+ you can enable libthreads, lightweight thread processes, these may increase thread performance.
- To enable add /usr/lib/lwp to LD_LIBRARY_PATH
- Soft References cleared less aggressively in server.
- -XX:SoftRefLRUPolicyMSPerMB=10000
- Default value is 1000, or one second per MB
6 Conclusion
- GC can be bottleneck in your app.
More Information