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 platforms. Implementation of colored points needs virtual address masking, which could be accomplished either in the hardware, operating system, or software. 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

The first 18 bits are reserved for future use. The 42 bits can address up to 4 TB of address space. Now comes the remaining, intriguing, 4 bits. 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 into the relocation set. The last 1-bit for finalizing relates to concurrent reference processing. It marks that an object can only be reachable through a finalizer.

When you run ZGC on a system, you'll notice that it uses a lot of virtual memory space, which, as you know, is not the same as the physical memory space. This is due to heap multi-mapping. It specifies how the objects with the colored pointers are stored in the virtual memory.

As an example, for a colorless pointer, say, 0x0000000011111111, its colored pointers would be 0x0000100011111111 (remapped bit set), 0x0000080011111111 (Marked1 bit set), and 0x0000040011111111 (Marked0 bit set). The same physical heap memory would map to three different locations in address space, each corresponding to the colored pointer. This would be implemented differently when the mapping is handled differently.

Let's explore other important JVM runtime parameters, which you can use to tune ZGC.