JDK-8229358 : JEP 364: ZGC on macOS (Experimental)
  • Type: JEP
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 14
  • Submitted: 2019-08-09
  • Updated: 2021-08-28
  • Resolved: 2020-02-27
Related Reports
Blocks :  
Relates :  
Relates :  
Sub Tasks
JDK-8234346 :  
Description
Summary
-------

Port the ZGC garbage collector to macOS.

Motivation
----------

While we expect users that require the scalability of ZGC to use Linux-based environments, 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.

Description
-----------

The macOS implementation of ZGC consists of two parts:

- Support for multi-mapping memory on macOS. 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 in ZGC for discontiguous memory reservations. 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`.

Alternatives
------------

We attempted an alternative prototype using POSIX shared memory objects. It used a file descriptor approach, for multi mapped memory. We abandoned this approach because, a) it did not support large pages, and b) the macOS implementation of ftruncate may only be called once to set the size of a file, which made uncommitting memory impossible.

Testing
-------

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

Dependencies
-----------

The work to purge the VM of the assumption that GCs have one discontiguous memory reservation is required to pave the way for the macOS port. These changes are described in preparatory  enhancements, to make reviewing easier:

  - [8229027](https://bugs.openjdk.java.net/browse/JDK-8229027): Improve how JNIHandleBlock::oops_do distinguishes oops from non-oops

  - [8229278](https://bugs.openjdk.java.net/browse/JDK-8229278): Improve hs_err location printing to assume less about GC internals

  - [8229189](https://bugs.openjdk.java.net/browse/JDK-8229189): Improve JFR leak profiler tracing to deal with discontiguous heaps

  - [8224815](https://bugs.openjdk.java.net/browse/JDK-8224815): Remove non-GC uses of CollectedHeap::is_in_reserved()

  - [8224820](https://bugs.openjdk.java.net/browse/JDK-8224820): ZGC: Support discontiguous heap reservations

Comments
Thank you for improving the description. It looks good to me; you may move it to Candidate.
04-10-2019

I’ve done a light copy-editing pass to remove uses of the passive voice and streamline the text. Let me know if this looks okay to you and I’ll move it to Candidate.
03-10-2019