|
|
While tuning the Oracle JRockit JVM you will often find a certain trade-off between short garbage collection pause times, high application throughput and low memory footprint. This section describes these trade-offs and the reasons behind them. The following topics are covered:
The JRockit JVM offers a choice between short garbage collection pauses and maximum application throughput. Intuitively it looks like short garbage collection pauses would also maximize the application throughput, which may make you wonder why you have to choose between the two. This section describes the reasons behind this trade-off.
The trade-off between garbage collection pauses and application throughput is partly caused by the mostly concurrent garbage collection strategy that enables short garbage collection pauses. No matter how efficient a garbage collection algorithm that stops the Java threads during the entire garbage collection is, a garbage collection algorithm that allows the Java threads to continue running during parts of the garbage collection will always give you shorter individual garbage collection pauses. Unfortunately a concurrent algorithm requires more bookkeeping and some extra work, since new objects are created and references between objects change during the garbage collection. All these changes must be kept track of, which alone causes some slight overhead, and at some point the garbage collector must handle all the changes, which causes some extra work. Simply put, the more the garbage collector can do while the Java threads are paused, the less it has to work in total.
The mark and sweep garbage collection model can cause fragmentation on the heap when small chunks of memory are freed between blocks of live objects. Compaction of the heap reduces this fragmentation. Fragmentation has a negative impact on the overall throughput as it makes object allocation more difficult and garbage collections more frequent. The JRockit JVM does partial compaction of the heap in each garbage collection, and the compaction is done while all Java threads are paused. Moving objects takes time, and compaction takes more time the more objects it moves. The trade-off is simple - reducing the amount of compaction shortens the compaction pause times but lowers the overall throughput by increasing the fragmentation.
A small memory footprint is desirable for applications that run on machines with limited memory resources. Unfortunately there is a certain trade-off between a small memory footprint and both application throughput and garbage collection pauses. This section describes some of the reasons for this trade-off.
A large heap reduces the garbage collection frequency and the negative impact of fragmentation, thus improving the throughput of the application. On the other hand a large heap increases the memory footprint of the Java process.
When you use a garbage collection mode that optimizes for short pauses, the Oracle JRockit JVM will have to use more advanced book keeping to keep track of changes in the heap, references to objects that are compacted etc. All this increases the memory footprint. You cannot tune the memory usage for book keeping other than by selecting a different garbage collection mode or strategy.
|