JEP 365: ZGC on Windows (Experimental)
| Owner | Stefan Karlsson |
| 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/10/16 11:00 |
| Updated | 2021/08/28 00:16 |
| Issue | 8232364 |
Summary
Port the ZGC garbage collector to Windows.
Non-Goals
It is not a goal to support Windows 10 and Windows Server older than version 1803, since older versions lack the required API for placeholder memory reservations.
Description
Most of the ZGC code base is platform independent and requires no Windows-specific changes. The existing load barrier support for x64 is operating-system agnostic and can also be used on Windows. The platform specific code that needs to be ported relates to how address space is reserved and how physical memory is mapped into a reserved address space. The Windows API for memory management differs from the POSIX API and is less flexible in some ways.
The Windows implementation of ZGC requires the following work:
-
Support for multi-mapping memory. ZGC's use of colored pointers requires support for heap multi-mapping, so that the same physical memory can be accessed from multiple different locations in the process address space. On Windows, paging-file backed memory provides physical memory with an identity (a handle), which is unrelated to the virtual address where it is mapped. Using this identity allows ZGC to map the same physical memory into multiple locations.
-
Support for mapping paging-file backed memory into a reserved address space. The Windows memory management API is not as flexible as POSIX's mmap/munmap, especially when it comes to mapping file backed memory into a previously reserved address space region. To do this, ZGC will use the Windows concept of address space placeholders. The placeholder concept was introduced in version 1803 of Windows 10 and Windows Server. ZGC support for older versions of Windows will not be implemented.
-
Support for mapping and unmapping arbitrary parts of the heap. ZGC's heap layout in combination with its dynamic sizing (and re-sizing) of heap pages requires support for mapping and unmapping arbitrary heap granules. This requirement in combination with Windows address space placeholders requires special attention, since placeholders must be explicitly split/coalesced by the program, as opposed to being automatically split/coalesced by the operating system (as on Linux).
-
Support for committing and uncommitting arbitrary parts of the heap. ZGC can commit and uncommit physical memory dynamically while the Java program is running. To support these operations the physical memory will be divided into, and backed by, multiple paging-file segments. Each paging-file segment corresponds to a ZGC heap granule, and can be committed and uncommitted independently of other segments.
Testing
The tests that usually run for ZGC on Linux will be run for Windows too.
Dependencies
The following changes to shared code are prerequisites:
- 8232601: ZGC: Parameterize the ZGranuleMap table size
- 8232602: ZGC: Make ZGranuleMap ZAddress agnostic
- 8232604: ZGC: Make ZVerifyViews mapping and unmapping precise
- 8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations
- 8232649: ZGC: Add callbacks to ZMemoryManager
- 8232650: ZGC: Add initialization hooks for OS specific code
- 8232651: Add implementation of os::processor_id() for Windows
