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 Heap space: "-Xms" and "-Xmx".
So configure the JVM with as much as possible memory from the operating system to run your Java application if needed.
For example, on a 32-bit Windows system, we can run a JVM with up to about 1.5 GB heap memory: "-Xmx1400m".
- 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 a 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.
Last update: 2018.
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"
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
Best Garbage Collector and Configuration
►General Suggestions for Better GC Performance
Full Version in PDF/EPUB