RFR: 8233299: Implementation: JEP 365: ZGC on Windows

[Per Liden]

Looks good!

/Per

On 10/31/19 11:18 AM, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to add ZGC support on Windows.
> 
> https://cr.openjdk.java.net/~stefank/8233299/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8233299
> 
> As mentioned in the JEP (https://openjdk.java.net/jeps/365), there were 
> some preparation patches that needed to go in to pave the way for this 
> patch:
> 
>      8232601: ZGC: Parameterize the ZGranuleMap table size
>      8232602: ZGC: Make ZGranuleMap ZAddress agnostic
>      8232604: ZGC: Make ZVerifyViews mapping and unmapping precise
>      8232648: ZGC: Move ATTRIBUTE_ALIGNED to the front of declarations
>      8232649: ZGC: Add callbacks to ZMemoryManager
>      8232650: ZGC: Add initialization hooks for OS specific code
>      8232651: Add implementation of os::processor_id() for Windows
> 
> ... they have all been pushed now.
> 
> One important key-point to this implementation is to use the new Windows 
> APIs that support reservation and mapping of memory through 
> "placeholders":  VirtualAlloc2, VirtualFreeEx, MapViewOfFile3, and 
> UnmapViewOfFile2. These functions are available starting from version 
> 1803 of Windows 10 and Windows Server. ZGC will lookup these symbols to 
> determine if the Windows version supports these functions.
> 
> 
> Correlating the text in the JEP with the code:
> 
> * '"Support for multi-mapping memory". ZGC's use of colored pointers 
> requires support for heap multi-mapping, so that the same physical 
> memory can be accessed from multiple different locations in the process 
> address space. On Windows, paging-file backed memory provides physical 
> memory with an identity (a handle), which is unrelated to the virtual 
> address where it is mapped. Using this identity allows ZGC to map the 
> same physical memory into multiple locations.'
> 
> We commit memory via paging file mappings and map views into that memory.
> 
> The function ZMapper::create_and_commit_paging_file_mapping uses 
> CreateFileMappingW with SEC_RESERVE to create this mapping, 
> MapViewOfFile3 to map a temporary view into the mapping, VirtualAlloc2 
> to commit the memory, and then UnmapViewOfFile2 to unmap the view.
> 
> The reason to use SEC_RESERVE and the extra VirtualAlloc2, instead of 
> SEC_COMMIT, is to ensure that the later multi-mappings of committed file 
> mappings don't fail under low-memory situations. Earlier prototypes used 
> SEC_COMMIT and saw these kind of OOME errors when mapping new views to 
> already committed memory. The current platform-independent ZGC code 
> isn't prepared to handle OOME errors when mapping views, so we chose 
> this solution.
> 
> MapViewOfFile3 is then used to multi-map into the committed memory.
> 
> * '"Support for mapping paging-file backed memory into a reserved 
> address space". The Windows memory management API is not as flexible as 
> POSIX's mmap/munmap, especially when it comes to mapping file backed 
> memory into a previously reserved address space region. To do this, ZGC 
> will use the Windows concept of address space placeholders. The 
> placeholder concept was introduced in version 1803 of Windows 10 and 
> Windows Server. ZGC support for older versions of Windows will not be 
> implemented.'
> 
> Before the placeholder APIs there was no way to first reserve a specific 
> virtual memory range, and then map a view of a committed paging file 
> over that range. The VirtuaAlloc function could be used to first reserve 
> and then commit anonymous memory, but nothing similar existed for mapped 
> views. Now with placeholders, we can create a placeholder reservation of 
> memory with VirtualAlloc2, and then replace that reservation with 
> MapViewOfFile3. When memory is unmapped, we can use UnmapViewOfFile2 to 
> "preserve" the placeholder memory reservation.
> 
> 
> * '"Support for mapping and unmapping arbitrary parts of the heap". 
> ZGC's heap layout in combination with its dynamic sizing (and re-sizing) 
> of heap pages requires support for mapping and unmapping arbitrary heap 
> granules. This requirement in combination with Windows address space 
> placeholders requires special attention, since placeholders must be 
> explicitly split/coalesced by the program, as opposed to being 
> automatically split/coalesced by the operating system (as on Linux).'
> 
> Half of the preparation patches were put in place to support this. When 
> replacing a placeholder with a view of the backing file, we need to 
> exactly match the address and size of a placeholder. Also, when 
> unmapping a view, we need to exactly match the address and size of the 
> view, and replace it with a placeholder.
> 
> To make it easier to map and unmap arbitrary parts of the heap, we split 
> reserved memory into ZGranuleSize-sized placeholders. So, whenever we 
> perform any of these operations, we know that any given memory range 
> could be dealt with as a number of granules.
> 
> When memory is reserved, but not mapped, it is registered in the 
> ZVirtualMemoryManager. It splits memory into granule-sized placholders 
> when reserved memory is fetched, and coalesces placeholders when 
> reserved memory is handed back.
> 
> 
> * '"Support for committing and uncommitting arbitrary parts of the 
> heap". ZGC can commit and uncommit physical memory dynamically while the 
> Java program is running. To support these operations the physical memory 
> will be divided into, and backed by, multiple paging-file segments. Each 
> paging-file segment corresponds to a ZGC heap granule, and can be 
> committed and uncommitted independently of other segments.'
> 
> Just like we can map and unmap in granules, we want to be able to commit 
> and uncommit memory in granules. You can see how memory is committed and 
> uncommitted in granules in ZBackingFile::commit_from_paging_file and 
> ZBackingFile::uncommit_from_paging_file. Each committed granule is 
> associated with one registered handle. When memory for a granule is 
> uncommitted, the handle is closed. At this point, no views exist to the 
> mapping and the memory is handed back to the OS.
> 
> 
> Final point about ZPhysicalMemoryBacking. We've tried to make this file 
> similar on all OSes, with the hope to be able to combine them when both 
> the Windows and macOS ports have been merged.
> 
> Thanks,
> StefanK