Java Advent Calendar 2017 This is the article on the 21st day. Java 9 was released this year and the default GC for the HotSpot JVM is now G1, so I'll post it for a review.

GC type

Four GC algorithms are implemented in the HotSpot VM.

--Serial type --Parallel type (throughput type)

Serial type

This is the default GC for single core CPU machines. GC processing is executed in a single thread. All applications are stopped in minor garbage collection and full garbage collection.

Parallel type (throughput type)

This is the default GC on multi-core CPU machines. Since GC processing is executed in multiple threads, GC is executed faster than the serial type. In Java7u4 or earlier, only the processing of the young area is multithreaded, and when using multithreading for the processing of the old area, it is necessary to specify the -XX: + UseParallelOldGC option. Since Java7u4, multithreaded GC is the default for both young and old areas.

CMS(Concurrent Mark Sweep) This GC is designed to avoid long-term application outages associated with full garbage collection. In minor garbage collection, application threads are stopped as in serial and parallel types. Full garbage collection does not stop the application thread, but uses one or more threads to search the old area in the background and discard unused objects. As a result, the total time that the application thread is stopped is shorter than that of the throughput type.

What is G1GC?

G1(Garbage 1st) --The same concurrent type as CMS because GC processing is performed in parallel with the application thread. ――It is the same as the previous GC in terms of generational GC --Suitable for apps with a large heap size (approximately 4G or more) --Implemented from Java6. However, up to Java7u4, Java8 or later is recommended for trial implementation and for production use.

Heap management

Traditional (serial, parallel, CMS) heap management

G1 heap management

The heap is divided into regions and managed.

Region size

In the default setting, the region size is determined by the heap size.

Heap size	Region size
Less than 4GB	1MB
4GB or more and less than 8GB	2MB
8GB or more and less than 16GB	4MB
16GB or more and less than 32GB	8MB
32GB or more and less than 64GB	16MB
64GB or more	32MB

You can also specify the size yourself using the -XX: G1HeapRegionSize = N flag. 0 is the default value. N must be a power of 2, and if any other value is specified, it is rounded down to the nearest power of 2.

In most cases, the default value is OK, but tuning is required in the following cases. For example, if the fluctuation range of the heap is large (-Xms4G -Xmx16G), the region size is 1MB by default, and when the heap is expanded, the number of regions becomes 16,000. Since G1GC is designed on the assumption that the number of regions is about 2,048, GC efficiency will deteriorate. In such a case, the size is adjusted so that the number of regions is around 2,048 by specifying the above option.

G1GC algorithm

In G1, four main processes are performed.

GC to the young region

When the eden space is full, GC to the young area occurs. When the GC is complete, the eden space will be empty and the region will be freed. At least one survivor space is allocated and some objects are moved to the Old area.

Concurrent cycle

In the concurrent cycle, the main thing is to put a mark (X in the figure) on the region where the old area is not used. Perform a GC to the young area before marking.

The concurrent cycle is divided into several phases.

initial-mark
root-region-scan
Concurrent-mark
Remark
Clean up
Concurrent-cleanup

Of these, application threads stop at 1, 4, and 5.

Mixed GC

As well as completely emptying the eden space, the survivors space is also adjusted. In the old area, a part of the region marked by the concurrent cycle is released. It also reduces heap fragmentation by moving data in use in the marked region to another region. Prevent concurrent mode failure by repeating mixed GCs instead of releasing all marked regions in a single GC.

Full garbage collection

This is the usual full garbage collection. Full garbage collection should be avoided in G1. If it does occur, you need to tune it. There are four main causes of full garbage collection: --Concurrent mode failure occurs --Promotion failure --Movement failure --Failure to allocate huge object

I will write the cause of these occurrences and the tuning method someday.

Where to use

Which GC to use should be considered based on the performance target value and the current CPU usage.

Web system

--Concurrent type is recommended to minimize the impact on some requests due to full garbage collection. --If you place importance on the average response time value excluding outliers (requests affected by full garbage collection), the throughput type will give good results. --If it is a concurrent type, long outages can be avoided, but CPU usage will increase.

Batch system

--If you can afford the CPU usage, the concurrent type is good. You can avoid full garbage collection and finish the process quickly. --If you use the concurrent type when there is not enough CPU usage, the processing completion will be delayed.

Finally

GC is the heart of Java (JVM). Memory-related performance issues are unavoidable in any Java version of any system. I'd like to understand a little about this new but default G1GC.

* Notice *

January 20, 2018 (Saturday) "JavaOne 2017 briefing session in OKINAWA" will be held! ** Luxury guests are coming! ** ** Please come to Okinawa during the off-season. https://java-kuche.doorkeeper.jp/events/68540 https://java-kuche.doorkeeper.jp/events/68542

[JAVA] G1 Garbage Collection in 3 Minutes