JEP draft: ZGC: Support for macOS

OwnerErik Österlund
TypeFeature
ScopeImplementation
StatusDraft
Componenthotspot / gc
Discussionhotspot dash gc dash dev at openjdk dot java dot net
EffortS
DurationS
Reviewed byPer Liden
Created2019/08/09 13:06
Updated2019/08/12 08:15
Issue8229358

Summary

Implement the necessary support so that Mac users may use ZGC.

Goals

Apart from the expected functionality of being able to run ZGC on macOS, it is worth mentioning that support for uncommitting unused memory is intended to be included in this JEP.

Non-Goals

Support for large pages is not a goal right now. However, no other GC supports large pages on macOS either, so that seems fine.

Motivation

While we expect users that require the scalability of ZGC to use Linux based environments, it is not uncommon that developers use Macs to perform local development and testing, before deploying applications. There are also users that wish to run desktop applications such as IDEs with ZGC. Therefore we wish to expand the support matrix by adding Mac support.

Description

The Mac implementation of ZGC consists of the following parts.

  1. Support for multi-mapping memory on macOS. Due to the ZGC design making intensive use of coloured pointers, an underlying mechanism is required on macOS that maps multiple virtual addresses (comprising different colours in the algorithm) to the same physical memory. The chosen approach is to use POSIX shared memory objects (shm_open) for that.

  2. Support in ZGC for discontiguous memory reservations. On Linux, we reserve 16 TB virtual address space during initialization. For that to work, we implicitly rely on no shared libraries accidentally being mapped in to 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 support is required for dealing with the heap reservation being discontiguous. The implication is also that shared VM code has to stop assuming there is a single contiguous memory reservation used by a GC implementation. As a result, GC APIs such as is_in_reserved(), reserved_region() and base() are being removed from CollectedHeap.

Alternatives

An alternative prototype using the Mach microkernel VM system for multi-mapped memory was attempted. It used vm_remap() to map the same memory multiple times, and could trivially support large pages. The reason this approach was not chosen was because of bad interactions with the mmap API that we still had to use to reserve virtual address space. One can not vm_map memory over mmap:ed memory, despite the mapping using MAP_NORESERVE. So the mmap:ed VA reservation has to be unmapped first, before mapping in the committed memory using the Mach APIs. But during that time, a race is exposed where another mmap user in the same process may hijack that memory first. Dealing with the consequences of that is extremely awkward, which is why POSIX shared memory objects were chosen instead.

Testing

The tests that usually run for ZGC on Linux, will be run for macOS too.

Dependencies

The work to clean the VM from the assumption that GCs have one discontiguous memory reservation is required to pave way for the mac port. The dependencies are sent out as preparative JBS enhancements to make reviewing easier, listed below: