compact object headers по умолчанию: JDK 27 отдаёт обратно пятую часть кучи
Сервис на Spring держит в памяти десятки миллионов мелких объектов: элементы кеша, DTO из очереди, узлы деревьев. Куча упирается в четыре гигабайта, хотя полезных данных там заметно меньше. Разница уходит в заголовки: каждый объект на 64-битной JVM несёт 96 бит служебной информации, а без сжатых указателей на класс все 128.
Заголовок собран из двух слов. В mark word лежат сведения о блокировке, возраст для сборщика и вычисленный identity hash, в class word лежит указатель на метаданные класса. Для объекта с парой полей сопоставимы с размером самих данных.
JEP 534 в JDK 27, вышедшей 15 сентября 2026, делает компактную раскладку значением по умолчанию: оба слова сливаются в одно 64-битное, а указатель на класс сжимается до 22 бит. Путь у фичи долгий: эксперимент в JDK 24, продуктовая настройка в JDK 25, теперь поведение по умолчанию. Заявленная экономия составляет 10–20% живых данных. То, что раскладка включилась, видно прямо на старте:
$ java -XX:+PrintFlagsFinal -version | grep -i UseCompactObjectHeaders
bool UseCompactObjectHeaders = true {product lp64_product} {default}
➡️ Размер конкретного класса можно глянуть через JOL, он печатает раскладку полей вместе с выравниванием:
System.out.println(ClassLayout.parseClass(CacheEntry.class).toPrintable());
На классе с двумя ссылочными полями заголовок падает с 12 байт до 8, и экземпляр укладывается в 16 байт вместо 24: выравнивание по 8 байт добавляет к экономии ещё четыре.
Ограничение вытекает из тех самых 22 бит: в них помещается около четырёх миллионов классов.
Приложение, которое плодит классы на лету (динамические прокси, скриптовые движки, тяжёлая кодогенерация), способно упереться в предел, и тогда загрузка класса завершится OutOfMemoryError без автоматического отката на старую раскладку.
Сюрпризы приходят и со стороны агентов и нативного кода, если те читают заголовок по фиксированному смещению.
Отключается всё флагом -XX:-UseCompactObjectHeaders, но рассчитывать на него вдолгую не стоит: старую раскладку планируют объявить устаревшей и со временем убрать. В том же релизе поменялся и сборщик по умолчанию: JEP 523 назначает G1 стандартом во всех окружениях, включая маленькие контейнеры, где раньше выбирался Serial.
Сервисам на 25-й ту же экономию даёт -XX:+UseCompactObjectHeaders без смены мажорной версии. Перед включением на проде стоит посмотреть счётчик загруженных классов (jcmd VM.class_hierarchy или метрика jvm_classes_loaded) и прогнать нагрузочный тест с теми агентами, которые реально работают в бою. Если счётчик держится в десятках тысяч, потолок в четыре миллиона вас не касается.
А вы уже мерили, сколько кучи у вас занимают заголовки объектов?
#backendvkhub #jdk #java
Сервис на Spring держит в памяти десятки миллионов мелких объектов: элементы кеша, DTO из очереди, узлы деревьев. Куча упирается в четыре гигабайта, хотя полезных данных там заметно меньше. Разница уходит в заголовки: каждый объект на 64-битной JVM несёт 96 бит служебной информации, а без сжатых указателей на класс все 128.
Заголовок собран из двух слов. В mark word лежат сведения о блокировке, возраст для сборщика и вычисленный identity hash, в class word лежит указатель на метаданные класса. Для объекта с парой полей сопоставимы с размером самих данных.
JEP 534 в JDK 27, вышедшей 15 сентября 2026, делает компактную раскладку значением по умолчанию: оба слова сливаются в одно 64-битное, а указатель на класс сжимается до 22 бит. Путь у фичи долгий: эксперимент в JDK 24, продуктовая настройка в JDK 25, теперь поведение по умолчанию. Заявленная экономия составляет 10–20% живых данных. То, что раскладка включилась, видно прямо на старте:
$ java -XX:+PrintFlagsFinal -version | grep -i UseCompactObjectHeaders
bool UseCompactObjectHeaders = true {product lp64_product} {default}
➡️ Размер конкретного класса можно глянуть через JOL, он печатает раскладку полей вместе с выравниванием:
System.out.println(ClassLayout.parseClass(CacheEntry.class).toPrintable());
На классе с двумя ссылочными полями заголовок падает с 12 байт до 8, и экземпляр укладывается в 16 байт вместо 24: выравнивание по 8 байт добавляет к экономии ещё четыре.
Ограничение вытекает из тех самых 22 бит: в них помещается около четырёх миллионов классов.
Приложение, которое плодит классы на лету (динамические прокси, скриптовые движки, тяжёлая кодогенерация), способно упереться в предел, и тогда загрузка класса завершится OutOfMemoryError без автоматического отката на старую раскладку.
Сюрпризы приходят и со стороны агентов и нативного кода, если те читают заголовок по фиксированному смещению.
Отключается всё флагом -XX:-UseCompactObjectHeaders, но рассчитывать на него вдолгую не стоит: старую раскладку планируют объявить устаревшей и со временем убрать. В том же релизе поменялся и сборщик по умолчанию: JEP 523 назначает G1 стандартом во всех окружениях, включая маленькие контейнеры, где раньше выбирался Serial.
Сервисам на 25-й ту же экономию даёт -XX:+UseCompactObjectHeaders без смены мажорной версии. Перед включением на проде стоит посмотреть счётчик загруженных классов (jcmd VM.class_hierarchy или метрика jvm_classes_loaded) и прогнать нагрузочный тест с теми агентами, которые реально работают в бою. Если счётчик держится в десятках тысяч, потолок в четыре миллиона вас не касается.
А вы уже мерили, сколько кучи у вас занимают заголовки объектов?
#backendvkhub #jdk #java