Complete guide to the Z Garbage Collector (ZGC)

ZGC is a new elastic scaling and low latency garbage collector introduced in JDK11. ZGC can work in KB to TB of memory. As a concurrent garbage collector, ZGC guarantees that the application latency will not exceed 10 milliseconds (even in large heap memory). Released in JDK11 as an experimental feature, by JDK13, ZGC can support up to 16TB of heap memory and can return uncommitted memory to the operating system.

Why introduce ZGC

Automatic garbage collection by the JVM reduces the work of the developer and reduces the risk of memory leaks to some extent, but because GC is automated, unforeseen events can sometimes have a detrimental effect on the application.

• Increased latency results in throughput and performance of the application

As hardware gets cheaper over time, applications will use more and more memory without increasing latency or throughput

ZGC guarantees that the delay will not exceed 10 milliseconds in any case.

The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:

• Pause times do not exceed 10ms
• Pause times do not increase with the heap or live-set size
• Handle heaps ranging from a few hundred megabytes to multi terabytes in size

ZGC features

The most typical feature of ZGC is that it is a concurrent GC. Other features are as follows:

• It can mark memory, copy and relocate memory, all concurrently, and it has a concurrent reference handler
• All other garbage collectors are usedstore barriersZGC useload barriers, used to track memory
  • The lock – > unlock – > read – > read memory load
  • Use – > assign – > store – > write write memory
• ZGC can be configured with more flexibility in size and policy, and it handles very large object release better than G1
• ZGC only has one generation, no new generation, old generation, etc., but ZGC can support local compression, and ZGC still has high performance when memory is restored and relocated
• ZGC relies on NUMA-aware(disbalanced memory access) and requires our memory to support this feature

Feature schedule

• JDK11, September 2018
  • ZGC release
  • Uninstallation of classes is not supported. – XX: + ClassUnloading not to take effect
• JDK12 2019 March
  • Support for concurrent class uninstallation
  • Pause times are further reduced
• JDK13 2019 September
  • Maximum heap memory from 4TB -> 16TB
  • You can return the unused memory, unresearch unused memory
  • Support for Linux and /AArch64 platforms
  • Reduced Time To a fixed Time point
  • Support – XX: SoftMaxHeapSize, when set this parameter ZGC can as far as possible under the specified memory size, unless in order to avoid memory leaks: reference: bugs.openjdk.java.net/browse/JDK-…
• JDK 14 is scheduled for March 2020
  • Increased stability
  • Support discontinuous address Spaces
  • .

ZGC supports:

How garbage Collection works

Some terms:

• Parallel multiple garbage collection threads working together can cause an application to stop
• The Serial garbage collector has only one thread working
• Stop the World app stops
• Concurrent garbage collector runs in the background and the application runs at the same time
• Incremental stop garbage collection before it’s finished and come back later to finish the rest

ZGC introduces two new concepts, pointer Coloring and Load Barriers.

Point Coloring

This feature allows the ZGC to discover, tag, locate, and remap objects. It only works on 64-bit operating systems, and requires virtual Address Masking to implement Colored Pointer.

• Finalizable objects can be reached by finalizer
• Marked0 and marked1 mark reachable objects
• Remap refers to the address of the current object that may be relocate. This address indicates that the object will be relocate

Load Barrier

A load barrier is a piece of code that is run when a thread loads a reference from the heap. For example, when we access a property of an object that is not a primary type.

In ZGC, the load barrier checks the metadata bit of the reference and does some processing on the referenced object according to the metadata bit. Therefore, the reference of the object may be modified when we obtain the object, but it does not affect our use.

In actual combat

You can download the latest version of the JDK from the official JDK website at:

www.oracle.com/technetwork…

Quick start

The GC log tag format is as follows:

-Xlog:<tag set>,[<tag set>,... ] : <log file>
Copy the code

Just to check if ZGC is in effect:

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc
Copy the code

To view more detailed ZGC log information:

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*
Copy the code

To record more detailed log information in a file:

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*:gc.log
Copy the code

The GC tuning parameter

NUMA Enabled or not Supported:

# enable NUMA
-XX:+UseNUMA 

The discontinuation of the NUMA #
-XX:-UseNUMA 
Copy the code

Adjust the number of concurrent threads:

-XX:ConcGCThreads=
Copy the code

Return uncommitted memory to the operating system, heap memory does not address the set minimum heap memory -xms

# How long will uncommitted memory be returned to the system
-XX:+ZUncommit  -XX:ZUncommitDelay=<seconds>
Copy the code

Turning on large paging generally results in better performance, with improved throughput, latency, and startup times. There are no obvious shortcomings

• Large pages are usually 2MB in size on Linux systems. If you have 16GB of heap memory, that means 16GB/2MB = 8192 large pages. The following commands require Linux kernel >= 4.14

# Configure the number of paging pools in the operating system
echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# Check the current number of pages in the system
cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages


-XX:+UseLargePages
Copy the code

• If the Linux kernel is < 4.14, then do the following

mkdir /hugepages
mount -t hugetlbfs -o uid=123 nodev /hugepages 
java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms16G -Xmx16G -XX:+UseLargePages
Copy the code

Enable transparent pages. Transparent pages may cause delays and are sometimes not recommended. You need the Linux kernel < 4.7 to enable transparent pages

# Open transparent page
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled


-XX:+UseTransparentHugePage
Copy the code

The last

ZGC is still an experimental feature, but with its 10ms latency guarantee and current support for heap memory sizes, it’s worth a try. Let’s hope ZGC becomes a better garbage collector.

reference

• OpenJDK Wiki
• ZGC introduction
• The ZGC JDK11