JIT deopt, цикл fix-and-verify и PR-time профилирование

Node-сервис имеет широкий leaf, который flame graph показывает как интерпретатор V8 (InterpreterCallStub), а не TurboFan. Функция горячая. JIT её не оптимизирует. Каждый вызов платит накладные расходы интерпретатора. Переключение на более быстрый алгоритм ничего не даст, пока не исправлен deopt. Понять, почему JIT вышел из игры, — это и есть диагноз.

JIT деоптимизация: шестая форма

JIT-рантаймы (V8, JVM HotSpot, .NET, PyPy) компилируют горячий код в нативный машинный код под типовые предположения. Если предположения нарушаются — функция получает неожиданный тип, происходит переход скрытого класса, megamorphic call-site разветвляется — JIT уходит в интерпретатор или в более медленный уровень компиляции.

Сигнатура во flame graph: функция показывает широкий, но широкий фрейм — это интерпретатор (Interpreter::execute, InterpreterCallStub) или baseline JIT-фрейм (V8 Sparkplug), а не фрейм оптимизирующего компилятора (V8 TurboFan, HotSpot C2).

Цена: один deopt — микросекунды. Deopt-петля (deopt → recompile → deopt) может тихо умножить per-call цену в 10–100 раз. Латентные всплески без корреляции с трафиком, периодические паузы без работы GC и baseline-tier фреймы, периодически доминирующие во flame graph — всё это симптомы deopt-петли.

Правка: стабилизировать типы.

• V8: держать hot object shapes не более ≤4 hidden classes; не добавлять поздние свойства в JS внутри горячих циклов.
• HotSpot: мониторить -XX:+PrintCompilation на повторные deopt’ы; избегать boxing в горячем коде.
• PyPy: следить за jit-summary на guard failures; писать type-stable циклы.

Верификация: пере-профилировать и убедиться, что фрейм оптимизирующего компилятора (TurboFan, C2) вернулся в горячий стек.

Цикл fix-and-verify

У каждой performance-правки пять обязательных шагов:

1. Назвать hotspot и классифицировать его (одна из шести форм, включая JIT deopt).
2. Выбрать категориальное семейство правок, соответствующее классификации.
3. Написать правку без scope creep — только то изменение, которое предсказано на шаге 2.
4. Снять профиль под той же нагрузкой и сравнить с baseline.
5. Верифицировать оба условия: локальный фрейм сжался И headline-метрика улучшилась (p99, throughput, CPU%, что именует SLO).

Если фрейм сжался, а метрика не сдвинулась: посмотри, куда ушло время — часто открывается вторая bottleneck, маскированная первой. Это не провал; это следующая итерация.

Если метрика сдвинулась, а фрейм не сжался: правка сработала через side effect, который ты не предсказывал. Разбирайся; возможно, задели что-то ортогональное. Оба исхода требуют доказательств и определяют следующий шаг.

Цикл — сеньорная performance-привычка: исправил одно, доказал, что приземлилось, нашёл следующее.

Микробенчмарк-driven vs production-profile-driven правки

Микробенчмарк в изоляции может сказать, что новый алгоритм в 5 раз быстрее. Production-профиль может показать, что алгоритм теперь 8% общего времени вместо 15%, но другие пути замедлились, потому что новый алгоритм больше аллоцирует и поднял GC-pressure.

Цикл fix-and-verify ловит это: захват production-профиля после изменения говорит о whole-system эффекте, не только о локальном. Микробенчмарк-утверждения — предсказания; production-profile diff — приговор.

Production-grade команды требуют оба: микробенчмарк, показывающий, что локальное изменение делает заявленное, И production-profile diff, показывающий, что system-wide эффект положителен. PR’ы с одним из двух релизуют регрессии, выглядящие как победы.

PR-time vs incident-time профилирование

Два режима применения hot-path методологии:

Incident-time: сервис горит, on-call ловит hotspot за минуты, чинит, верифицирует, релизит. Реактивный режим — методология та же, но clock тикает.

PR-time: до релиза CI снимает профиль PR против baseline main и флагает регрессии до того, как они попадают в production. Проактивный режим — методология та же, без давления.

Сеньорные команды инвестируют в оба: incident-time runbook’и для on-call, PR-time CI гейты для предотвращения. Каждая incident retro добавляет одно правило в PR-time гейт: если ровно эта регрессия могла быть поймана в CI, добавляем сигнатуру. Со временем PR-time гейт ловит большую часть регрессий до релиза; incident-time runbook’и ловят остаток.