This chapter describes the tuning options available to reduce the memory footprint of the JVM.
If you are running on a system with limited memory resources, consider tuning the Oracle JRockit JVM for a small memory footprint.
This chapter includes information about the following topics:
The memory footprint of an application can be measured by using some of the tools available in the operating system (for example, the top shell command or the Task Manager in Windows).
To determine how the memory usage of the JVM process is distributed, request a memory analysis by using the jrcmd command to print the memory usage of the JVM. For more information, see Oracle JRockit JDK Tools.
After you get information about the memory usage of the JVM, you can start tuning the JVM to reduce the memory footprint within the areas that use the most memory.
The most obvious place to start tuning the memory footprint is the Java heap size. If you reduce the Java heap size, you reduce the memory footprint of the Java process by the same amount. You cannot reduce the heap size beyond a point; the heap should be large enough for all objects that are live at the same time. Preferably, the heap must be at least twice the size of the total amount of live objects, or large enough so that the JVM spends less time garbage collecting the heap than running Java code.
You can set the heap size by using the -Xms (initial heap size) and -Xmx (maximum heap size) options.
Example:
java -Xms:100m -Xmx:100m myApplication
To let the heap to grow and shrink depending on the amount of free memory in your system, set the-Xms command lower than the -Xmx command. For more information about setting the heap size, see Section 4.4, "Optimizing Memory Allocation Performance."
The choice of a garbage collection mode or static strategy does not in itself affect the memory footprint noticeably, but if you choose the right garbage collection strategy, you reduce the heap size without a major performance degradation.
If your application uses a lot of temporary objects, consider using a generational garbage collection strategy. A nursery reduces fragmentation and allows for a smaller heap.
The concurrent garbage collector must start garbage collections before the heap is entirely full, to allow Java threads to continue allocating objects during the garbage collection. This means that the concurrent garbage collector requires a larger heap than the parallel garbage collector, and thus your primary choice for a small memory footprint is a parallel garbage collector.
The default garbage collection mode is a generational parallel garbage collection strategy. This means that the default garbage collector is a good choice when you want to minimize the memory footprint.
To change the garbage collection mode, specify the mode by using the -Xgc option.
Example:
java -Xgc:genpar myApplication
For more information about selecting a garbage collector, see Section 4.2, "Selecting and Tuning a Garbage Collector."
Using a small heap increases the possibility of fragmentation on the heap. Fragmentation can have a severe effect on application performance, both by lowering the throughput and by causing occasional long garbage collections when the garbage collector is forced to compact the entire heap at once.
If you experience problems with fragmentation on the heap, increase the compaction ratio by using the -XXcompaction:percentage option.
Example:
java -XXcompaction:percentage=20 myApplication
If your application is not sensitive to long latencies, consider using full compaction. Full compaction enables you to use a smaller heap, because all fragmentation is eliminated at each garbage collection. You can enable full compaction by using the -XXcompaction:full option.
Example:
java -XXcompaction:full myApplication
Compaction uses memory outside of the heap for bookkeeping. As an alternative to increasing the compaction, use a generational garbage collector, which also reduces the fragmentation.
You can tune the object allocation to allow smaller chunks of free memory to be used for allocation. This reduces the negative effects of fragmentation, and allows you to run with a smaller heap. The smallest chunk of memory used for object allocation is a thread local area. Free chunks smaller than the minimum thread local area size are ignored by the garbage collector and become dark matter until a later garbage collection frees some adjacent memory or compacts the area to create larger free chunks.
You can reduce the minimum thread local area size by using the -XXtlaSize:min=size option.
Example:
java -XXtlaSize:min=1k myApplication
For more information about how to set the thread local area size, see the documentation on -XXtlaSize and Section 4.4, "Optimizing Memory Allocation Performance."