>> Note that any reference to pages from here on out refers to the concept of a >> heap region in ZGC, not pages in the operating system (OS), unless stated >> otherwise. > > # Background > > This PR addresses fragmentation by introducing a Mapped Cache that replaces > the Page Cache in ZGC. The largest limitation of the Page Cache is that it is > constrained by the abstraction of what a page is. The proposed Mapped Cache > removes this limitation by decoupling memory from pages, allowing it to merge > and split memory in ways that the Page Cache is not suited for. To facilitate > the transition, much of the Page Allocator has been redesigned to work with > the Mapped Cache. > > In addition to fighting fragmentation, the new approach improves NUMA-support > and simplifies memory unampping. Combined, these changes lay the foundation > for even more improvements in ZGC, like replacing multi-mapped memory with > anonymous memory. > > # Mapped Cache > > The main benefit of the Mapped Cache is that adjacent virtual memory ranges > in the cache can be merged to create larger ranges, enabling larger > allocation requests to succeed more easily. Most notably, it allows > allocations to succeed more often without "harvesting" smaller, discontiguous > ranges. Harvesting negatively impacts both fragmentation and latency, as it > requires remapping memory into a new contiguous virtual address range. > Fragmentation becomes especially problematic in long-running programs and in > environments with limited address space, where finding large contiguous > regions can be difficult and may lead to premature Out Of Memory Errors > (OOME). > > The Mapped Cache uses a self-balancing binary search tree to store memory > ranges. Since the ranges are unused when inside the cache, the tree can use > this memory to store metadata about itself, referred to as intrusive storage. > This approach eliminates the need for dynamic memory allocation (e.g., > malloc), which could otherwise introduce a latency overhead. > > # Fragmentation > > Currently, ZGC has multiple strategies for dealing with fragmentation. In > some edge cases, these strategies are not as efficient as we would like. By > addressing fragmentation differently with the Mapped Cache, ZGC is in a > better position to avoid edge cases, which are bad even if they occur only > once. This is especially impactful for programs running with a large heap. > > ## Virtual Memory Shuffling > > In addition to the Mapped Cache, we have made some adjustments in how ZGC > deals with virtual memory. When harvesting memory, whic...
Joel Sikström has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/gc/z/zVirtualMemoryManager.hpp Co-authored-by: Axel Boldt-Christmas <xmas1...@gmail.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24547/files - new: https://git.openjdk.org/jdk/pull/24547/files/5f9caa7a..ea2b5f97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24547&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24547&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24547/head:pull/24547 PR: https://git.openjdk.org/jdk/pull/24547
