On Thu, 10 Apr 2025 09:20:58 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 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 <xmas1...@gmail.com> Thank you to everyone who contributed to, helped out, and reviewed this patch. I am really happy with how this turned out and all the things I've learned along the way :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24547#issuecomment-2792450995
