This chapter describes how tuning the Oracle JRockit JVM leads to trade-offs among short garbage collection pause times, high application throughput, and low memory footprint.
This chapter contains the following topics:
With the JRockit JVM you can choose between short garbage collection pauses and maximum application throughput. The following sections describe why there is a trade-off.
The trade-off between garbage collection pauses and application throughput is partially caused by the mostly concurrent garbage collection strategy that enables short garbage collection pauses. No matter how efficient the garbage collection algorithm is that stops the Java threads during the entire garbage collection, a garbage collection algorithm that allows the Java threads to continue to run during parts of the garbage collection has shorter individual garbage collection pauses. A concurrent algorithm requires more work, because new objects are created and references between objects change during the garbage collection. All these changes must be kept track of, which causes overhead, and the garbage collector must make all the changes, which adds extra work. The more the garbage collector can do while the Java threads are paused, the less processing it has to do.
The mark and sweep garbage collection model can cause heap fragmentation when chunks of memory too small for allocated objects are freed between blocks of live objects. Compacting the heap reduces this fragmentation. Fragmentation has a negative impact on the overall throughput because it makes object allocation more difficult and garbage collections more frequent. The JRockit JVM does partial compaction of the heap in each garbage collection; this compaction occurs while all Java threads are paused. Moving objects takes time and compaction takes more time the more objects it moves. Reducing the amount of compaction shortens the compaction pause times, but it can reduce the overall throughput by allowing more fragmentation.
A small memory footprint is desirable for applications that run on machines with limited memory resources. There is a trade-off for having a small memory footprint and both application throughput and garbage collection pauses. The following sections describe some of the reasons for this trade-off.
A large heap reduces the garbage collection frequency and fragmentation, improving the throughput of the application; however, 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 uses more advanced bookkeeping to track changes in the heap, references to compacted objects, and so on. All these increase the memory footprint. To tune the memory usage for bookkeeping, you must select a different garbage collection mode or strategy.