RFR: 8353637: ZGC: Discontiguous memory reservation is broken on Windows [v2]

[Erik Österlund]

On Fri, 4 Apr 2025 12:23:15 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> While working on [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) I realized that the current Windows implementation to use placeholders for reservations are broken if we ever fallback to using the part that performs discontiguous heap reservation.
>> 
>> To understand this bug you first need to understand how and why we use the placeholder mechanism. From zMapper_windows.cpp:
>> 
>> 
>> // Memory reservation, commit, views, and placeholders.
>> //
>> // To be able to up-front reserve address space for the heap views, and later
>> // multi-map the heap views to the same physical memory, without ever losing the
>> // reservation of the reserved address space, we use "placeholders".
>> //
>> // These placeholders block out the address space from being used by other parts
>> // of the process. To commit memory in this address space, the placeholder must
>> // be replaced by anonymous memory, or replaced by mapping a view against a
>> // paging file mapping. We use the later to support multi-mapping.
>> //
>> // We want to be able to dynamically commit and uncommit the physical memory of
>> // the heap (and also unmap ZPages), in granules of ZGranuleSize bytes. There is
>> // no way to grow and shrink the committed memory of a paging file mapping.
>> // Therefore, we create multiple granule-sized page file mappings. The memory is
>> // committed by creating a page file mapping, map a view against it, commit the
>> // memory, unmap the view. The memory will stay committed until all views are
>> // unmapped, and the paging file mapping handle is closed.
>> //
>> // When replacing a placeholder address space reservation with a mapped view
>> // against a paging file mapping, the virtual address space must exactly match
>> // an existing placeholder's address and size. Therefore we only deal with
>> // granule-sized placeholders at this layer. Higher layers that keep track of
>> // reserved available address space can (and will) coalesce placeholders, but
>> // they will be split before being used.
>> 
>> And the way we implement this is through the callbacks in zVirtualMemory_windows.cpp:
>> 
>> 
>> // Each reserved virtual memory address area registered in _manager is
>> // exactly covered by a single placeholder. Callbacks are installed so
>> // that whenever a memory area changes, the corresponding placeholder
>> // is adjusted.
>> //
>> // The create and grow callbacks are called when virtual memory is
>> // returned to the memory manager. The new memory area is then covered
>> // by a n...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More feedback

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24443#pullrequestreview-2746486259