JEP 365 is one of two Java Enhancement Proposals (the other being JEP 364) 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. However, as Erik Österlund notes in JEP 364: ZGC on macOS, that some users want to use their workstations “for local development and testing, before deploying applications. There are also users who wish to run desktop applications such as IDEs with ZGC.”
The keen eyed will already have noticed that there’s a slight gap between the creation of JEP 364 and JEP 365, but the important thing is that both of them are proposed to target JDK 14 and so neither macOS users nor Windows users will be left out in the cold. Let’s take a closer look at the specifics.
JEP 365: ZGC on Windows
Stefan Karlsson, author of this proposal, makes it clear from the outset that the goal is to support only Windows 10 and Windows Server versions 1803 and beyond. This is because older versions do not have the necessary API for placeholder memory reservations.
Karlsson notes that the majority of the Z Garbage Collector code base is platform agnostic and does not need any Windows-specific changes. The changes necessary relate to how Windows and Windows Server reserve address space and how physical memory is mapped into that reserved address space. He also notes that the memory management API in Windows is a bit different and less flexible than the POSIX API used by Linux.
In order to port ZGC to Windows, there are four main points that require work.
Support for multi-mapping memory
The first of the four points involves adding 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 second of the four involves the aforementioned differences between the POSIX API and the Windows API:
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.
In addition to these four main points, there are a handful of dependencies that the Java team will be taking into consideration when making ZGC Windows compatible.
JEP 365 is targeted to JDK 14, so we should see a Windows-compatible ZGC in March 2020.
Read the original JEP in all its glory here.