ZGC Garbage Collector: Low Latency and Scalable

In this article, we will see how ZGC works. If you also wanted to learn about G1GC you can go through this link. This will give a better understanding of how Garbage collections work.

• JAVA-11 has a lot of improvements and changes in GC. Z Garbage Collector (ZGC) is introduced in JAVA-11 as an experimental GC.
• Completely new GC.
• Work with heap memory, ranging from KBs to a large TB memory.
• Never exceed application latency by 10 millisecond

What is ZGC?

It 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

Properties:

• Concurrent
• Region-based
• Compacting
• NUMA-aware
• Using colored pointers
• Using load barriers

Working of ZGC:

ZGC divides memory into regions, also called ZPages. ZPages are dynamically sized (unlike the G1 GC), which are multiples of 2 MB can be dynamically created and destroyed.

Here are the size groups of heap regions:

• Small(2MB),
• Medium(32MB)
• Large(N * 2 MB)

Important Points:

• ZGC heap can have multiple occurrences of these heap regions.
• After ZGC compaction, ZPages are freed up and inserted into a page cache called as ZPageCache.
• ZPages in the page cache are ready to be reused to satisfy new heap allocations.
• The page cache is critical for performance, as committing and uncommitting memory are expensive operations.
• ZPages in the page cache represents the unused parts of the heap that could be uncommitted and returned to the operating system.

Phases of Z Garbage Collection:

A GC cycle of ZGC includes multiple phases:

Pause Mark Start:

• In this phase objects that have been pointed to roots. This includes walking through the live set of objects and then finding and marking them.
• It starts with a scanning thread stack which gives the reference objects in heap.
• After getting reference it will walk through all the graphs of objects(which are reachable).
• It also remaps the live data after the end of the last phase(Pause Relocate Phase).

Pause Mark End:

• This phase with a short pause of 1ms.
• The pause time involved here depends only on the number of roots and the ratio of the sizes of the relocation set and total live set of objects
• This starts after completion of the first phase.
• This starts with preparing concurrent relocation of objects and marks the regions it wants to compact.
• Now we have all the information which objects are live so it starts with reference processing and moves to week-root cleaning.

Pause Relocate Start:

• It triggers the actual region compaction.
• It begins with root scanning pointing into the location set, followed by the concurrent reallocation of objects in the relocation set.

Colored pointers Working in ZGC:

• Colored pointers are one of the core concepts of ZGC.
• It enables ZGC to find, mark, locate, and remap the objects.
• It doesn’t support x32 or 32 bits operating systems.
• Load Barrier uses this to detect whether the object is bad color then do the corresponding action (like remap means object is remapped to a different address). It is injected by the JIT compiler when the object is fetched from the heap.

The following diagram shows the 64-bit pointer layout:

As shown in the preceding diagram, the 64-bit object reference is divided as follows:

• 18 bits: Unused bits
• 1-bit: Finalizable
• 1-bit: Remapped
• 1-bit: Marked1
• 1-bit: Marked0
• 42 bits: Object Address

Explanations:

• The first 18 bits are reserved for future use.
• 42 bits can address up to 4 TB of address space.
• The Marked1 and Marked0 bits are used to mark objects for garbage collection. By setting the single bit for Remapped, an object can be marked not pointing to the relocation set.
• The last 1-bit for finalizing relates to concurrent reference processing.

That’s It

Happy Learning