Usage:
You can set the percentage of the heap size to use as default minimum young generation size with:
-XX:G1NewSizePercent=percent , where percent is the desired value in %.
Since:
Starting from JDK 7.
Examples:
This will instruct JVM to use 50% of heap for the young generation:
-XX:G1NewSizePercent=50
Description:
Garbage Collector is a way of the JVM to clean the memory and makes the java memory more efficient. It tracks (Mark step) and removes (sweep step) every unused object available in the JVM heap space. An object is considered unused when it’s referenced by null, assigned to another reference or by anonymous object …. There are 5 type of GC implementations:
- Serial Garbage Collector
- Parallel Garbage Collector
- CMS Garbage Collector
- G1 Garbage Collector
- Z Garbage Collector
Young Generation is a place where all new objects start out and aged. It’s divided into two spaces:
- Eden Space: New object initiated with the keyword “new” are allocated in this memory space.
- Survivor Space: When the Eden space is filled. A minor garbage collection event occurs. Objects that are referenced are marked and some are not. The ones which are marked will move to Survivor Space S0 and the one unmarked are removed by GC. When The space S0 filled, the cycle repeat itself but instead of moving them to S0, they will be moved to Survivor Space S1.
Old Generation is a place where objects that lived for a long time lie. If an object reaches an age threshold after surviving multiple GC events in the Young Generation, the object gets moved to the Old Generation.
G1 (Garbage First) GC is designed for apps in multi-processor environments with large memory space (more than 4GB). It is available from the JDK7 Update 4. Unlike other collectors, the G1 collector partitions the heap into a set of equal-sized heap regions (usually 1MB to 32MB) chunks, prioritizes them, and then performs the garbage collection on those chunks based on the priority. The G1 collector is designed for applications that:
- Can operate concurrently with applications threads like the CMS collector.
- Compact free space without lengthy GC induced pause times.
- Need more predictable GC pause durations.
- Do not want to sacrifice a lot of throughput performance.
- Do not require a much larger Java heap.
G1 divides the entire heap into regions of equal size, each region is a continuous virtual memory, and a region is the basic unit of memory allocation and reclamation. As shown below:
When G1 is paused, the entire eden region can be reclaimed. The objects of the eden region are either copied to the survivor region or copied to the old region. At the same time, each pause can reclaim a part of the memory of the old generation and copy the old generation from one region to another.
Large objects refer to objects whose size is more than half of the region. Large objects can span multiple regions. When allocating memory to large objects, they will be directly allocated in the old age, and will not be allocated in the eden area.
As shown in the figure below, the object “C” occupies one and a half regions. When allocating memory to a large object, it is necessary to allocate consecutive regions from one region. Before the large object is reclaimed, the last region cannot be allocated to other objects.
Usually, the dead large object will be collected only in the GC pause phase or FullGC after the mark ends. However, there is an exception for array large objects of primitive types (such as bool arrays, all integer arrays, float arrays, etc.), and G1 will collect these dead large objects at any GC pause. When allocating large objects, GC pauses may occur prematurely due to the large footprint. G1 will check whether the current heap memory usage exceeds the initial heap occupancy threshold IHOP (The Initiating Heap Occupancy Percent) every time a large object is allocated. If the current heap occupancy rate exceeds the IHOP threshold, the initial mark will be triggered immediately.
Even during FullGC, large objects are never moved. This can lead to premature FullGC or unexpected OutOfMemory exception, because there is still a lot of free memory at this time, but these memories are all memory fragments in the region.
The time spent by young GC is generally proportional to the size of the young area, more precisely, it is related to the number of live objects to be copied in the collection set of the young area. If this time is too long, decrease “-XX:G1NewSizePercent” if the object copy time is long. This will reduce the minimum size of the young area, which will reduce the pause time.
Default Value:
Default is 5% of your Java heap.
Note:
By setting manually the size of the young area with the flag “-XX:G1NewSizePercent”, you might encounter other problems, if the performance of the application, especially the number of surviving objects suddenly changes, this will cause glitches in the pause time. By setting “-XX:G1MaxNewSizePercent” to reduce the size of the largest young area can be effectively alleviate this problem. This parameter limits the maximum size of the young area and therefore the number of objects that need to be processed during the pause time.
This is an experimental flag. This setting replaces the “-XX:DefaultMinNewGenPercent” setting.
This flag isn’t available in Java HotSpot VM build 23 or earlier.
Errors:
The value should be between 0 and 100.
Arguments related:
G1MaxNewSizePercent, UseG1GC, MinHeapFreeRatio, MaxHeapFreeRatio, DefaultMinNewGenPercent, G1ReservePercent, G1HeapWastePercent, G1MixedGCCountTarget, G1OldCSetRegionThresholdPercent, G1MixedGCLiveThresholdPercent.
Related Posts:
- Part 1: Introduction to the G1 Garbage Collector
- Garbage collection (computer science)
- 5 Available Collectors
- Java Oracle
- Java Garbage Collection Basics
Edit your Comment