JEP 230: Microbenchmark Suite

Аннотация

Добавить в исходный код JDK базовый набор микробенчмарков и сделать так, чтобы разработчики могли легко запускать существующие микробенчмарки и создавать новые.

Цели

• Основан на [Java Microbenchmark Harness (JMH)][1]
• Стабильные и настроенные бенчмарки, предназначенные для непрерывного тестирования производительности
  • Стабильный и неизменный набор после вехи Feature Complete в Feature Release (функциональный выпуск), а также для выпусков, не являющихся функциональными
  • Поддержка сравнения с предыдущими выпусками JDK для тестов, где это применимо
• Простота
  • Новые бенчмарки легко добавлять
  • Тесты легко обновлять, когда API и параметры меняются, объявляются Deprecated (устаревший) или удаляются в ходе разработки
  • Набор легко собрать
  • Бенчмарк легко найти и запустить
• Поддержка обновлений JMH
• Включить в набор начальный комплект примерно из ста бенчмарков

Что не является целью

• Предоставлять бенчмарки для новых возможностей JDK не является целью. Бенчмарки для новых возможностей будут добавляться в рамках соответствующих проектов.

• Создавать полный набор бенчмарков, покрывающий всё в JDK, не является целью. Со временем набор будет расширяться за счёт новых бенчмарков или работ, специально направленных на расширение его покрытия.

• Предлагать решение для работы с бинарными зависимостями в микробенчмарках не является целью. Поддержка этого может быть добавлена позже.

Описание

Набор микробенчмарков будет размещён вместе с исходным кодом JDK в одном каталоге, а при сборке будет создавать один JAR-файл. Совместное размещение упростит добавление и поиск бенчмарков во время разработки. При запуске бенчмарков JMH предоставляет мощные возможности фильтрации, так что пользователь может запускать только те бенчмарки, которые ему сейчас интересны. Точное расположение ещё предстоит определить.

Для бенчмаркинга обычно нужны сравнения с более ранней сборкой или даже выпуском, поэтому микробенчмарки должны поддерживать JDK(N) — для бенчмарков, нацеленных на возможности нового JDK, и JDK(N-1) — для бенчмарков, нацеленных на возможности, существующие в более раннем выпуске. Для JDK 12 это означает, что структура и скрипты сборки должны поддерживать компиляцию бенчмарков как для JDK 12, так и для JDK 11. Кроме того, бенчмарки будут разделены по именам пакетов Java, описывающим область JDK, которую они тестируют.

Предлагается следующая структура каталогов:

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] Это комплект настроенных и протестированных микробенчмарков, который уже используется внутри компании. Открытым остаётся вопрос, перенести ли этот отдельный проект целиком в совместно размещённый набор или сохранить его как стабилизационный лес (stabilization forest) для более долгоживущих регрессионных тестов.

Тем не менее от любого пользователя по-прежнему ожидается, что при анализе он убедится, что другие параметры, например машина, на которой выполняется запуск, и 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/