JEP 341: Default CDS Archives

Аннотация

Доработать процесс сборки JDK так, чтобы на 64-битных платформах он создавал архив class data-sharing (CDS, совместное использование данных классов) по списку классов по умолчанию.

Цели

• Сократить время запуска без дополнительной настройки
• Избавить пользователей от необходимости запускать -Xshare:dump, чтобы получить преимущества CDS

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

• Мы будем создавать архив по умолчанию только при нативной сборке, но не при кросс-компиляции.
• Мы будем создавать архив по умолчанию только для 64-битных сборок. Поддержка 32-битных сборок может быть добавлена позже.

Мотивация

Начиная с JDK 8u40 базовая возможность CDS получила множество улучшений. Выигрыш во времени запуска и в совместном использовании памяти при включённом CDS значительно вырос. Измерения на Linux/x64 со сборкой 14 JDK 11 Early Access (ранний доступ) показывают сокращение времени запуска на 32% при выполнении HelloWorld. На других 64-битных платформах наблюдался такой же или больший выигрыш в скорости запуска.

Сейчас образ JDK содержит список классов по умолчанию, который создаётся во время сборки и находится в каталоге lib. Пользователи, которые хотят воспользоваться CDS, даже только со списком классов по умолчанию из JDK, должны отдельным шагом запустить java -Xshare:dump. Этот параметр описан в документации, но многие пользователи о нём не знают.

Описание

Изменить сборку JDK так, чтобы после компоновки образа запускалась команда java -Xshare:dump. (Можно добавить дополнительные параметры командной строки, чтобы подобрать размер кучи GC и т. п. и получить более удачное размещение в памяти для типичных случаев.) Оставить полученный архив CDS в каталоге lib/server, чтобы он входил в итоговый образ.

Пользователи будут получать преимущества CDS автоматически, поскольку в JDK 11 параметр -Xshare:auto включён по умолчанию для серверной VM (JDK-8197967). Чтобы отключить CDS, запускайте с -Xshare:off.

Пользователи с более сложными требованиями (например, со своими списками классов, включающими классы приложения, с другими конфигурациями GC и т. п.) по-прежнему могут создать собственный архив CDS, как и раньше.

Альтернативы

Собирать архив CDS по умолчанию, но отключить -Xshare:auto.

Такой подход был бы безопаснее. В Windows CDS включён по умолчанию уже во многих выпусках, поскольку архив CDS по умолчанию создавал установщик JDK для Windows, но на других платформах это не так. Если внезапно включить CDS без осознанного выбора со стороны пользователей, это может затронуть существующие приложения, например если они зависят от недокументированных особенностей последовательности запуска JVM.

Если -Xshare:auto отключён (то есть мы откатим JDK-8197967), то даже при наличии архива CDS по умолчанию в JDK пользователям придётся явно указывать -Xshare:auto в командной строке, чтобы использовать CDS. Так у пользователей появился бы период привыкания к архиву CDS по умолчанию, после которого мы могли бы вернуть JDK-8197967 в одном из будущих выпусков.

Преимущества этого подхода:

• Поведение по умолчанию не меняется сразу.
• Удобство использования CDS с архивом по умолчанию повышается, поскольку в типичных случаях не нужен шаг java -Xshare:dump.
• Возможность получает больше тестирования: пользователи получают архив по умолчанию без риска немедленного изменения поведения по умолчанию.

Недостатки этого подхода:

• Мы то включали бы, то отключали -Xshare:auto, что вызывало бы путаницу.
• Он основан на ошибочном допущении, что включение архива CDS сопряжено с высоким риском. Архив CDS по умолчанию включён в Windows (client) уже более десяти лет, и проблемы возникают редко.
• Пользователи смогут протестировать эту возможность, только если явно включат параметр -Xshare:auto. Однако пользователи, которым важен CDS (или которые о нём знают), уже создали архивы CDS и изменили свои командные строки для прошлых выпусков, то есть они уже тестируют CDS без поставляемого нами архива по умолчанию. Сомнительно, что этот подход действительно дал бы больше тестирования.

Напротив, при подходе, предложенном в этом JEP, многие разработчики будут неявно тестировать CDS, когда собирают JDK или используют выпуск Early Access, что явно даст больше тестирования.

Тестирование

Существующего автоматического тестирования с включённым CDS достаточно.