JEP 364: ZGC on macOS (Experimental) (original) (raw)
| Owner | Erik Österlund |
|---|---|
| Type | Feature |
| Scope | Implementation |
| Status | Closed / Delivered |
| Release | 14 |
| Component | hotspot / gc |
| Discussion | hotspot dash gc dash dev at openjdk dot java dot net |
| Effort | S |
| Duration | S |
| Depends | JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) |
| Relates to | JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) |
| Reviewed by | Mikael Vidstedt, Per Liden |
| Endorsed by | Mikael Vidstedt |
| Created | 2019/08/09 13:06 |
| Updated | 2021/08/28 00:16 |
| Issue | 8229358 |
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()andbase()will be removed fromCollectedHeap.
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: Improve how JNIHandleBlock::oops_do distinguishes oops from non-oops
- 8229278: Improve hs_err location printing to assume less about GC internals
- 8229189: Improve JFR leak profiler tracing to deal with discontiguous heaps
- 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved()
- 8224820: ZGC: Support discontiguous heap reservations