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... src/hotspot/share/gc/z/zVirtualMemoryManager.hpp line 89: > 87: ZVirtualMemoryManager(size_t max_capacity); > 88: > 89: void initialize_partitions(ZVirtualMemoryReserver* reserver, size_t > reserved); Suggestion: void initialize_partitions(ZVirtualMemoryReserver* reserver, size_t size_for_partitions); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24547#discussion_r2036582513
