JEP 341: Default CDS Archives | 默认 CDS 归档
摘要
在 64 位平台上，通过使用默认类列表来增强 JDK 构建过程，以生成类数据共享（CDS）存档。
目标
- 改善开箱即用的启动时间
- 消除用户需要运行
-Xshare:dump来享受 CDS 好处的需求
非目标
- 我们仅为原生构建生成默认存档，不为交叉编译构建生成。
- 我们仅为 64 位构建生成默认存档；对 32 位构建的支持可能会在后续添加。
动机
自从 JDK 8u40 以来，基础 CDS（类数据共享）功能已经添加了许多增强。启用 CDS 提供的启动时间和内存共享优势已经显著增加。在 Linux/x64 上使用 JDK 11 早期访问版本 14 进行的测量显示，运行 HelloWorld 的启动时间减少了 32%。在其他 64 位平台上，也观察到了类似或更高的启动性能提升。
目前，JDK 映像在构建时包含一个默认的类列表，该列表位于 lib 目录中。即使只使用 JDK 中提供的默认类列表，想要利用 CDS 功能的用户也必须运行 java -Xshare:dump 作为额外步骤。虽然该选项已被文档化，但许多用户并不了解它。
描述
修改 JDK 构建过程，在链接映像后运行 java -Xshare:dump。（可能会包含额外的命令行选项来微调 GC 堆大小等，以便为常见情况获得更好的内存布局。）将生成的 CDS 存档留在 lib/server 目录中，使其成为最终映像的一部分。
由于 JDK 11 中服务器 VM 默认启用了 -Xshare:auto（JDK-8197967），因此用户将自动受益于 CDS 功能。要禁用 CDS，请使用 -Xshare:off 运行。
对于有更高要求的用户（例如，使用包含应用程序类的自定义类列表、不同的 GC 配置等），仍然可以像以前一样创建自定义 CDS 存档。
替代方案
构建默认的 CDS 存档但禁用 -Xshare:auto。
这种方法会更安全。CDS 在 Windows 上的许多版本中已被默认启用，因为默认的 CDS 存档是由 JDK Windows 安装程序创建的，但其他平台并非如此。如果我们突然启用 CDS 而不让用户做出有意识的选择，那么现有应用程序可能会受到影响，例如，如果它们依赖于 JVM 启动序列的未文档化方面。
如果禁用 -Xshare:auto（即，我们撤销 JDK-8197967），那么即使默认 CDS 存档包含在 JDK 中，用户也需要在命令行上明确指定 -Xshare:auto 才能使用 CDS。这将为用户提供一个使用默认 CDS 存档的适应期，之后我们可以在未来的版本中重新启用 JDK-8197967。
这种方法的优势在于：
- 它不会立即改变默认行为。
- 通过消除
java -Xshare:dump步骤，它提高了默认存档的 CDS 可用性，适用于常见情况。 - 它通过为用户提供默认存档而不立即改变默认行为的风险，提供了更多的测试曝光度。
这种方法的缺点是：
- 我们将不断切换
-Xshare:auto选项，造成混淆。 - 它基于一个错误的假设，即包含 CDS 存档具有高风险。CDS 默认存档在 Windows（客户端）上启用已经超过十年，并且很少出现问题。
- 用户只有在明确打开
-Xshare:auto选项的情况下才能测试此功能。然而，关心（或了解）CDS 的用户已经在过去的版本中为 CDS 创建了存档并修改了他们的命令行，这意味着他们已经在没有我们提供默认存档的情况下测试了 CDS。这种方法是否真的会导致更多的测试是值得怀疑的。
相比之下，按照本 JEP 中提出的方案，许多开发者在构建 JDK 或使用早期访问版本时会隐式地测试 CDS，这显然会导致更多的测试。
测试
现有的启用 CDS 的自动化测试已经足够。