Методология использования AI в JMH(AMBER)

Продолжая искать интересные статейки для программистов наткнулся на интересный научный труд коллег из Италии - AMBER: AI-Enabled Java Microbenchmark Harness.

JMH делает warm-up — несколько прогонов, чтобы JIT, кэш и другие штуки JVM «устаканились». Если прогревов мало — получаем неверные измерения. Если много — тратим время (особенно в CI, где каждая минута стоит денег и нервов). Традиционно разработчик вручную ставит @Warmup(iterations = N) — и надеется на лучшее

AMBER предлагает другое: он режет поток измерений на окна, обучает классификатор (stable / unstable) и во время прогрева спрашивает модель: «стабильно ли сейчас?» — и автоматически прекращает warm-up, когда пора. Это экономит время и повышает качество измерений.

CI/CD с кучей бенчмарков - У вас в пайплайне сотни JMH-задач. Статический @Warmup(500) — это 500× как-то многовато. AMBER может остановить прогрев раньше, если поведение уже стабильно, экономя минуты/часы.
Автодетекция регрессий - Если производительность «прыгает», AMBER выявить, что ряд измерений нестабилен или вовсе не вошёл в steady-state: нельзя доверять этим метрикам.
Исследования/лаборатории производительности - Экономия времени + автоматическое логирование реального числа прогретых итераций = удобнее для массовых измерений и репликации экспериментов.

AMBER — комбинирует 3 вещи

Ключевая идея простая и мощная: вместо жёсткого количества итераций — интеллектуальная остановка.

Предобработка: измерения времени (последовательность) режут на перекрывающиеся окна фиксированного размера и маркируют как stable/unstable в обучающей выборке.
Модель-TSC (Time Series Classification): авторы пробовали несколько подходов — сверточную FCN, расширенную OSCNN и быстрый метод ROCKET. Каждая модель имеет свои плюсы/минусы (точность/ложные срабатывания/скорость).
Рантайм-интеграция: во время выполнения AMBER берёт последнее окно данных, спрашивает модель через локальный сервис (jpt-service — Flask в Docker) и либо продолжает warm-up, либо переключается на measurement.

Стандартная реализация

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS) @Fork(1) @BenchmarkMode(Mode.AverageTime) public class MyBench { @Benchmark public void test(Blackhole bh) { // код, который мерим } }

Вариант предложенный исследователями из статьи

@DynamicHalt(model = "OSCNN") public class FlattenRangePerf { @Benchmark public void observable(Blackhole bh) { // код } }

@DynamicHalt(model="OSCNN") говорит AMBER: при warm-up спрашивать модель OSCNN (через jpt-service) и автоматически остановить прогрев, когда модель скажет stable.

JMH запускает бенчмарк с аннотацией @DynamicHalt.
После каждой итерации AMBER собирает окно последних измерений.
AMBER вызывает jpt-service (REST) → модель (FCN/OSCNN/ROCKET) отвечает stable/unstable.
AMBER либо переходит к @Measurement, либо делает ещё итерацию warm-up.

Проведены эксперементы на 586 микробенчмарках из 30 проектов.

FCN/OSCNN/ROCKET для задачи классификации окон дают F1 ≈ 0.75–0.87.
В практическом сравнении с ручными SOP и SOTA-методами AMBER (особенно с OSCNN) дал net-улучшение для значимой доли бенчмарков (в статье — до ~27% «выигранных» сценариев по времени/качеству).
ROCKET был быстрым, но давал больше ложных срабатываний; OSCNN показал лучший баланс.

Собираете образ с jpt-service (Flask) и предобученной моделью (OSCNN) — контейнер в CI.
В проекте заменяете @Warmup на @DynamicHalt(model = "OSCNN").
При запуске бенчмарков Jenkins/GitLab CI стартует контейнер jpt-service и вызывает mvn -DskipTests package → запускает java -jar benchmarks.jar.
AMBER в рантайме решает: закончить прогрев или дать ещё итерацию. В логах JMH получится реальное число прогретых итераций — удобно для анализа регрессий.

Примечание: авторы реализовали jpt-service как внешнюю службу в Docker; полноценный репозиторий с доками — проверяйте в их исходниках / демо (см. ссылки ниже).

AMBER — это аккуратный пример современной моды: берём старую добрую инженерную проблему (когда остановить прогрев), добавляем ML, и получаем «умную» автоматизацию, сокращая ручной труд.
Поискал чуток в сети на пример реализации у наших гигантов подобные штуки, но пока нигде не используется ML именно в таком формате или просто не признаются :)

Методология использования AI в JMH(AMBER)

Предыстория

Кому это нужно

Что внутри

JMH vs AMBER

Как это выглядит в общих чертах

Цифры(кратенько)

Как можно использовать на практике

Итого