days
-3
-6
hours
-2
-2
minutes
-4
-1
seconds
-1
-4
search
A glimpse into the future of Java

JEP 364: ZGC on macOS

Chris Stewart
JEP 364
© Shutterstock / turkkub (modified)

The Z Garbage Collector or ZGC is a scalable low latency garbage collector that’s included in the JDK. Until now, it has not been compatible with macOS, but JEP 364 wants to change that. Let’s take a closer look.

JEP 364 is one of two Java Enhancement Proposals (the other being JEP 365) that want to make the Z Garbage Collector or ZGC more accessible for more development setups. Currently, the platforms supported by ZGC are Linux/x64 and Linux/AArch64, but in JEP 364’s Motivation, the JEP’s author Erik Österlund notes that, “it is not uncommon that developers use Macs for local development and testing, before deploying applications. There are also users who wish to run desktop applications such as IDEs with ZGC.”

JEP 364: ZGC on macOS

There are two main parts that are the crux of porting ZGC to macOS. The first is getting colored pointers to work on macOS, and the second is support for discontiguous memory reservations.

Support for multi-mapping memory

Erik Österlund writes the following:

The ZGC design makes intensive use of colored pointers, so we need a way on macOS to map multiple virtual addresses (comprising different colors in the algorithm) to the same physical memory. We will use the mach microkernel mach_vm_remap API for this. The physical memory of the heap is maintained in a separate address view, conceptually similar to a file descriptor, but residing in a (mostly) contiguous virtual address instead. This memory is remapped into the various ZGC views of memory, representing the different pointer colors of the algorithm.

Support for discontiguous memory reservations

The other point for consideration is that on macOS the memory allocation would have to work slightly differently due to differences with Linux. Österlund writes:

On Linux, we reserve 16TB of virtual address space during initialization. For that to work, we assume that no shared libraries will be mapped into the desired address space. On a default Linux configuration, that is a safe assumption to make. However, on macOS, the ASLR mechanism intrudes into our address space, so ZGC must allow the heap reservation to be discontiguous. The shared VM code must also stop assuming that a single contiguous memory reservation is used by a GC implementation. As a result, GC APIs such as is_in_reserved(), reserved_region() and base() will be removed from CollectedHeap.

In addition to these two main points, there are a handful of dependencies that the Java team will be taking into consideration to rid the JVM of the assumption that garbage collectors have one discontiguous memory reservation.

JEP 364 is targeted to JDK 14, so we should see a macOS-compatible ZGC in March 2020.

Read the original JEP in all its glory here.

Author
Chris Stewart
Chris Stewart is an Online Editor for JAXenter.com. He studied French at Somerville College, Oxford before moving to Germany in 2011. He speaks too many languages, writes a blog, and dabbles in card tricks.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of