RFR: 8350441: ZGC: Overhaul Page Allocation [v2]

[Stefan Karlsson]

On Thu, 10 Apr 2025 09:16:56 GMT, Joel Sikström <jsikstro at 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 vir...
>
> 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 <xmas1915 at gmail.com>

Looks good!

Marked as reviewed by stefank (Reviewer).

-------------

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24547#pullrequestreview-2755953546
PR Review: https://git.openjdk.org/jdk/pull/24547#pullrequestreview-2755957917