General Suggestions for Better GC Performance
This section describes some general rules used by JVM to manage memory and get better GC performance.
We know that one strength of JVM (Java Virtual Machine) is that it performs automatic memory
management for us. But this also could also give us headaches when JVM throws OutOfMemoryError at us,
because we don't have much direct control on how memory is managed.
The only thing we can do is to learn how JVM memory management works, write Java code better aligned
with the JVM memory management design, and play with JVM memory management parameters for better result.
Here are my understandings of HotSpot memory management and suggestions on to minimize memory usage and maximize performance
for your Java applications:
- The main challenge of JVM memory management is on the Heap data area,
which dynamically allocates and deallocates data objects (instances of classes and arrays).
Other runtime data areas, Method Area, Direct Memory, PC Registers, JVM Stacks and Native Method Stacks
are very easy to manage.
- When a JVM is started, it will ask the operating system to reserve a chunk of memory
and use it as the Heap data area with a minimum size.
The JVM will use Heap space to store some JVM system objects
and give the rest of the Heap space to your Java application.
- HotSpot supports 2 options to control the minimum size and the
maximum size of the reserved Heap space: "-Xms" and "-Xmx".
In general, reserving more heap space results better performance for the application.
So reserve as much as possible heap space from the Operating System(OS) to run your Java application.
But do not reserve more than what is available from OS RAM.
Otherwise, OS will use virtual memory from hard disk resulting poor performance.
- When a new data object is created each time, the JVM needs to
find enough Heap space and allocate it to the object.
So reuse objects as much as possible to reduce the JVM work load on allocating and removing objects.
This is why some applications use Object Pooling.
- When an object becomes unreferenced or no longer used by the application, it will be a candidate
to be removed by the JVM to free up more memory in the next round of garbage collection process.
So remove references to objects as soon as possible to allow the JVM to remove them sooner.
- "Slow" down the application to reduce the memory usage. This is trading time for memory.
For example, if your application handles work loads with multiple concurrent threads,
use less threads and put work loads into waiting queues will reduce the memory usage.
- Use the G1 collector to get better performance.
- Give larger Young generation size, if your application uses more short-lived objects.
- Give larger Tenured generation size, if your application uses more long-lived objects.
- Play with memory management options provided by the JVM to see the impact on your Java application.
- Using JVM troubleshooting tools to profile, dump, analyze, and
do fine tuning on the memory usage pattern of your Java application.
Table of Contents
About This Book
Heap Memory Area and Size Control
JVM Garbage Collection Logging
Introduction of Garbage Collectors
Serial Collector - "+XX:+UseSerialGC"
Parallel Collector - "+XX:+UseParallelGC"
Concurrent Mark-Sweep (CMS) Collector - "+XX:+UseConcMarkSweepGC"
Garbage First (G1) Collector - "+XX:+UseG1GC"
The Z Garbage Collector (ZGC) - "+XX:+UseZGC"
Object References and Garbage Collection
Garbage Collection Performance Test Program
Performance Tests on Serial Collector
Performance Tests on Parallel collector
Performance Tests on Concurrent collector
Performance Tests on G1 collector
►Garbage Collection Performance Test Summary
►General Suggestions for Better GC Performance
Full Version in PDF/EPUB