9 The Z Garbage Collector
The Z Garbage Collector (ZGC) is a scalable low latency garbage collector. ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB.
ZGC has been designed to be adaptive and to require minimal manual configuration. During the execution of the Java program, ZGC dynamically adapts to the workload by resizing generations, scaling the number of GC threads, and adjusting tenuring thresholds. The main tuning knob is to increase the maximum heap size.
ZGC comes in two versions: The new, generational version and the legacy, non-generational version. The Non-generational ZGC is the older version of ZGC, which doesn't take advantage of generations (see Generations) to optimize its runtime characteristics. It is encouraged that users transition to use the newer Generational ZGC.
The Generational ZGC is enabled with the command-line options
-XX:+UseZGC -XX:+ZGenerational
.
The Non-generational ZGC is enabled with the command-line option
-XX:+UseZGC
.
Setting the Heap Size
The most important tuning option for ZGC is setting the maximum heap size,
which you can set with the -Xmx
command-line option.
Because ZGC is a concurrent collector, you must select a maximum heap size
such that the heap can accommodate the live-set of your application and
there is enough headroom in the heap to allow allocations to be serviced
while the GC is running. How much headroom is needed very much depends on
the allocation rate and the live-set size of the application. In general,
the more memory you give to ZGC the better. But at the same time, wasting
memory is undesirable, so it’s all about finding a balance between memory
usage and how often the GC needs to run.
ZGC has another command-line option related to the heap size named
-XX:SoftMaxHeapSize
. It can be used to set a soft
limit on how large the Java heap can grow. ZGC will strive to not grow
beyond this limit, but is still allowed to grow beyond this limit up to the
maximum heap size. ZGC will only use more than the soft limit if that is
needed to prevent the Java application from stalling and waiting for the GC
to reclaim memory. For example, with the command-line options
-Xmx5g
-XX:SoftMaxHeapSize=4g
ZGC will use 4GB as the limit for
its heuristics, but if it can't keep the heap size below 4GB it is still
allowed to temporarily use up to 5GB.
Returning Unused Memory to the Operating System
By default, ZGC uncommits unused memory, returning it to the operating system. This
is useful for applications and environments where memory footprint is a
concern, but might have a negative impact on the latency of Java threads.
You can disable this feature with the command-line option
-XX:-ZUncommit
. Furthermore, memory will not be
uncommitted so that the heap size shrinks below the minimum heap size
(-Xms)
. This means this feature will be implicitly
disabled if the minimum heap size (-Xms)
is configured to
be equal to the maximum heap size (-Xmx)
.
You can configure an uncommit delay using
-XX:ZUncommitDelay=<seconds>
(default is 300
seconds). This delay specifies for how long memory should have been unused
before it's eligible for uncommit.
Note:
Allowing the GC to commit and uncommit memory while the
application is running could have a negative impact on the latency
of Java threads. If extremely low latency is the main reason for
running with ZGC, consider running with the same value for
-Xmx
and -Xms
, and use
-XX:+AlwaysPreTouch
to page in memory
before the application starts.
Using Large Pages
Configuring ZGC to use large pages will generally yield better performance (in terms of throughput, latency and start up time) and comes with no real disadvantage, except that it's slightly more complicated to setup. The setup process typically requires root privileges, which is why it's not enabled by default.
Enabling Large Pages On Linux
On Linux x86, large pages (also known as "huge pages") have a size of 2MB.
Let's assume you want a 16GB Java heap. That means you need 16GB / 2MB = 8192 huge pages.
The heap requires at least 16GB (8192 pages) of memory to the pool of huge pages. The heap along with other parts of the JVM will use large pages for various internal data structures (such as code heap and marking bitmaps). In this example you will reserve 9216 pages (18GB) to allow for 2GB of non-Java heap allocations to use large pages.
Configure the system's huge page pool to have the required number of pages (requires root privileges):
$ echo 9216 >
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
Note that the above command is not guaranteed to be successful if the kernel cannot find enough free huge pages to satisfy the request. Also note that it might take some time for the kernel to process the request. Before proceeding, check the number of huge pages assigned to the pool to make sure the request was successful and has completed.
$ cat
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
9216
Enabling Transparent Huge Pages On Linux
Note:
On Linux, using ZGC with transparent huge pages enabled requires kernel >= 4.7.Use the following options to enable transparent huge pages in the VM:
-XX:+UseLargePages -XX:+UseTransparentHugePages
These options tell the JVM to issue madvise(...,
MADV_HUGEPAGE) calls for memory it maps, which is useful when using
transparent huge pages in madvise
mode.
To enable transparent huge pages, you also need to configure the kernel by
enabling madvise
mode.
$ echo madvise >
/sys/kernel/mm/transparent_hugepage/enabled
ZGC uses shmem
huge pages for the heap, so the following
kernel setting also needs to be configured:
$ echo advise >
/sys/kernel/mm/transparent_hugepage/shmem_enabled
It is important to check these kernel settings when comparing the performance of
different GCs. Some Linux distributions forcefully enable transparent huge pages for
private pages by configuring
/sys/kernel/mm/transparent_hugepage/enabled
to be set to
always
, while leaving
/sys/kernel/mm/transparent_hugepage/shmem_enabled
at the default
never
. In this case all GCs but ZGC will make use of transparent
huge pages for the heap. See Transparent Hugepage Support for more
information.