JEP 365: ZGC on Windows (Experimental)JEP 365: ZGC on Windows (Experimental)OwnerStefan KarlssonTypeFeatureScopeImplementationStatusClosed / DeliveredRelease14Componenthotspot / gcDiscussionhotspot dash gc dash dev at openjdk dot java dot netEffortSDurationSDependsJEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)Relates toJEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production)Reviewed byMikael Vidstedt, Per LidenEndorsed byMikael VidstedtCreated2019/10/16 11:00Updated2021/08/28 00:16Issue8232364Summary
Port the ZGC garbage collector to Windows.
Non-Goals
It is not a goal to support Windows 10 and Windows Server older than version 1803, since older versions lack the required API for placeholder memory reservations.
Description
Most of the ZGC code base is platform independent and requires no Windows-specific changes. The existing load barrier support for x64 is operating-system agnostic and can also be used on Windows. The platform specific code that needs to be ported relates to how address space is reserved and how physical memory is mapped into a reserved address space. The Windows API for memory management differs from the POSIX API and is less flexible in some ways.
The Windows implementation of ZGC requires the following work:


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.


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.


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).


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.


Testing
The tests that usually run for ZGC on Linux will be run for Windows too.
Dependencies
The following changes to shared code are prerequisites:

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

InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
