On Wed, 9 Apr 2025 13:37:16 GMT, Joel Sikström <jsiks...@openjdk.org> wrote:
>> 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... This pull request has now been integrated. Changeset: 7e69b98e Author: Joel Sikström <jsiks...@openjdk.org> URL: https://git.openjdk.org/jdk/commit/7e69b98e0548803b85b04b518929c073f8ffaf8c Stats: 12052 lines in 118 files changed: 7936 ins; 3218 del; 898 mod 8350441: ZGC: Overhaul Page Allocation Co-authored-by: Axel Boldt-Christmas <abold...@openjdk.org> Co-authored-by: Erik Österlund <eosterl...@openjdk.org> Co-authored-by: Stefan Karlsson <stef...@openjdk.org> Co-authored-by: Stefan Johansson <sjoha...@openjdk.org> Reviewed-by: stefank, aboldtch, eosterlund ------------- PR: https://git.openjdk.org/jdk/pull/24547
