跳到主要内容

JEP 230：微基准套件

概括​

将一套基本的微基准测试添加到 JDK 源代码中，使开发人员可以轻松运行现有的微基准测试并创建新的微基准测试。

目标​

  • 基于[Java Microbenchmark Harness (JMH)][1]
  • 稳定且经过调整的基准，针对持续性能测试
    • 功能发布的功能完成里程碑之后以及非功能版本的稳定且不移动的套件
    • 支持与以前的 JDK 版本进行比较以进行适用的测试
  • 简单
    • 轻松添加新基准
    • 当 API 和选项发生变化、被弃用或在开发过程中被删除时，可以轻松更新测试
    • 易于构建
    • 轻松查找并运行基准测试
  • 支持JMH更新
  • 套件中包含大约一百个基准的初始集合

非目标​

  • 为新的 JDK 功能提供基准测试并不是我们的目标。添加新功能的基准将作为这些项目的一部分完成。

  • 创建一套涵盖 JDK 中所有内容的完整基准测试并不是我们的目标。随着时间的推移，该套件将继续通过新编写的基准进行扩展，或者通过专门针对扩大其覆盖范围的努力来扩展。

  • 提供处理微基准中的二进制依赖关系的解决方案并不是我们的目标。稍后可能会添加对此的支持。

描述​

微基准测试套件将与 JDK 源代码共同位于一个目录中，构建后将生成一个 JAR 文件。共置将简化开发过程中添加和定位基准的过程。运行基准测试时，JMH 提供强大的过滤功能，允许用户仅运行当前感兴趣的基准测试。确切位置仍有待确定。

基准测试通常需要与早期版本甚至版本进行比较，因此微基准测试必须支持 JDK(N)（针对新 JDK 中的功能的基准测试）和 JDK(N-1)（针对早期版本中现有功能的基准测试）。这意味着，对于 JDK 12，结构和构建脚本必须支持 JDK 12 和 JDK 11 的编译基准。基准将通过使用描述它们正在测试的 JDK 区域的 Java 包名称来进一步划分。

建议采用以下目录结构：

jdk/jdk
   .../make/test (Shared folder for Makefiles)
   .../test (Shared folder for functional tests)
      .../micro/org/openjdk/bench
         .../java (subdirectories similar to JDK packages and modules)
         .../vm (subdirectories similar to HotSpot components)

微基准套件的构建将与普通的 JDK 构建系统集成。它将是一个单独的目标，在正常的 JDK 构建期间不会执行，以便为开发人员和其他对构建微基准套件不感兴趣的人缩短构建时间。要构建微基准套件，用户必须专门运行make build-microbenchmark或类似的。此外，make test TEST="micro:regexp"还将支持使用运行基准测试。有关如何设置本地环境的说明将记录在 中docs/testing.md|html。

这些基准测试都依赖于 JMH，就像某些单元测试依赖于 TestNG 或 jtreg 一样，因此虽然对 JMH 的依赖是新的，但构建的其他部分也具有类似的依赖关系。与 jtreg 相比的一个区别是 JMH 既在构建期间使用，又打包为生成的 JAR 文件的一部分。

微基准测试套件中的基准测试集将从 JMH JDK Microbenchmarks 项目导入。[2]这些构成了一组已在内部使用的经过调整和测试的微基准。一个悬而未决的问题是，是否将这个独立项目整个迁移到同一地点的套件，或者将其保留为稳定林以进行更长期的回归测试。

然而，任何用户在进行分析时仍然需要确保其他参数（例如执行机和JDK）稳定且具有可比性。在常见情况下，基准预计能够在一分钟内完成完整的运行。这不是大型或长期运行基准测试的包装框架；目标是提供一套快速且有针对性的基准。在某些特殊情况下，基准测试可能需要更长的预热或运行时间才能获得稳定的结果，但应尽可能避免这种情况。该套件的目标不是充当较大工作负载的通用包装器；而是作为更大工作负载的通用包装器。相反，其目的是从更大的基准中提取关键组件或方法，并仅强调该部分作为微基准。

作为该项目的一部分，将在wiki.openjdk.java.net上创建一个新页面，以帮助解释如何开发新的基准测试并描述添加基准测试的要求。这些要求将强制要求遵守编码标准、可重复的性能以及基准及其测量内容的清晰文档。

备择方案​

继续将微基准套件作为一个单独的项目进行维护[2]。

共置简化了为新功能添加基准的过程，尤其是在大部分新功能开发都是在项目存储库（Valhalla、Amber 等）中完成的世界中。事实证明，在单独的项目模型中特别复杂的一个情况是测试 javac 本身的更改，然后需要使用每个相应的 JDK 显式重建基准测试套件。共置可以更优雅地解决这个特定的用例，同时不禁止使用预构建的基准测试包来在较长时间内跟踪稳定测试的性能。

测试​

作为定期性能测试的一部分，性能团队将验证微基准，以确保仅添加稳定、经过调整且准确的微基准。还将根据具体情况对基准进行评估和分析，以确保测试预期的功能。所有测试必须在所有适用平台上运行多次，以确保其稳定。

风险​

  • JDK 构建将取决于 JMH 的版本。 JDK 构建系统需要能够下载或以其他方式访问 JMH 的二进制版本，并且必须能够在需要时通过合理的努力更新到较新版本的 JMH。这应该是一个很容易解决的问题，因为我们对 TestNG 和其他库有类似的依赖关系。 JMH 依赖项仅对尝试构建微基准套件的人可见；其他构建目标不依赖于 JMH。

  • 构建时间显着增加。常规开发人员 JDK 构建不需要基准套件；它将是一个单独的构建目标。

  • 新基准中潜在的测试不稳定。需要对每个添加的基准进行彻底的审查和测试。

  • 增加源代码存储库大小。顾名思义，微基准测试很小，但随着时间的推移，它们有望成为一大批。主要大小将取决于需要在存储库外部处理的资源。

  • 需要提供二进制存储以允许创建某些类型的基准。某些基准测试依赖于外部库或大型静态资源，例如用作基准测试一部分的 XML 文档和源代码文件。目前我们还没有解决方案，但这只会限制具有此类依赖性的基准测试。小型非二进制资源可能被允许作为微基准源代码的一部分。

依赖关系​

微基准套件将依赖于 Java Microbenchmark Harness 版本 1.12 或更高版本。

[1] http://openjdk.java.net/projects/code-tools/jmh

[2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/