jep122
JEP 365是两个Java增强提案(另一个是JEP 364 )之一,该提案希望使Z Garbage Collector或ZGC更易于访问,以进行更多开发设置。 当前,ZGC支持的平台是Linux / x64和Linux / AArch64。 但是,正如ErikÖsterlund在macOS上的JEP 364: ZGC中指出的那样,某些用户希望在部署应用程序之前将其工作站用于本地开发和测试。 还有一些用户希望运行桌面应用程序,例如带有ZGC的IDE。”
敏锐的眼睛已经注意到,JEP 364和JEP 365的创建之间存在细微的差距,但是重要的是,这两个提议都针对JDK 14,因此macOS用户和Windows用户都不会被排除在外。寒冷。 让我们仔细看一下细节。
Windows上的JEP 365:ZGC
该提案的作者Stefan Karlsson从一开始就明确指出,目标是仅支持Windows 10和Windows Server 1803及更高版本。 这是因为较旧的版本没有预留占位符所需的API。
Karlsson指出,大多数Z Garbage Collector代码库都是平台无关的,不需要任何Windows特定的更改。 必要的更改与Windows和Windows Server如何保留地址空间以及如何将物理内存映射到该保留的地址空间有关。 他还指出,与Linux使用的POSIX API相比,Windows中的内存管理API有所不同,并且灵活性较差。
还请参见:
为了将ZGC移植到Windows,有四个要点。
支持多映射内存
这四点中的第一点涉及添加对多映射内存的支持:
ZGC使用彩色指针需要支持堆多重映射,以便可以从进程地址空间中的多个不同位置访问同一物理内存。 在Windows上,分页文件支持的内存为物理内存提供了一个标识(句柄),该标识与映射它的虚拟地址无关。 使用此标识,ZGC可以将同一物理内存映射到多个位置。
支持将分页文件支持的内存映射到保留的地址空间
四个中的第二个涉及POSIX API和Windows API之间的上述区别:
Windows内存管理API不如POSIX的mmap / munmap灵活,尤其是在将文件支持的内存映射到以前保留的地址空间区域中时。 为此,ZGC将使用Windows概念的地址空间占位符。 Windows 10和Windows Server版本1803中引入了占位符概念。 不会实现对Windows的较早版本的ZGC支持。
支持映射和取消映射堆的任意部分
ZGC的堆布局与其动态调整堆页面大小(以及重新调整大小)相结合,需要支持映射和取消映射任意堆粒子。 此要求与Windows地址空间占位符结合使用时,需要特别注意,因为占位符必须由程序显式拆分/合并,而不是由操作系统自动拆分/合并(如Linux)。
支持提交和取消提交堆的任意部分
ZGC可以在Java程序运行时动态地提交和取消提交物理内存。 为了支持这些操作,物理内存将被划分为多个分页文件段并由其支持。 每个分页文件段都对应于ZGC堆粒度,并且可以独立于其他段进行提交和取消提交。
除了这四个要点外,在使ZGC Windows兼容时,Java团队还将考虑一些依赖性。
JEP 365针对JDK 14,因此我们应该在2020年3月看到兼容Windows的ZGC。
在这里阅读所有原始的JEP荣耀 。
翻译自: https://jaxenter.com/jep-365-zgc-windows-garbage-collector-164057.html
jep122