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

[Stefan Karlsson]

> 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 new single placeholder.
> //
> // The destroy and shrink callbacks are called when virtua...

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  More feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24443/files
  - new: https://git.openjdk.org/jdk/pull/24443/files/754bce11..8066c900

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24443&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24443&range=00-01

  Stats: 55 lines in 4 files changed: 10 ins; 6 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/24443.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24443/head:pull/24443

PR: https://git.openjdk.org/jdk/pull/24443