JEP 148: Small VM

Аннотация

Поддержать создание компактной VM размером не более 3 МБ.

Цели

Внести необходимые изменения, чтобы при желании можно было собрать компактную VM размером не более 3 МБ. (Для сравнения: клиентская и серверная VM сейчас занимают около 6 и 9 МБ соответственно.)

Этого мы добьёмся, позволив исключать некоторые возможности на этапе сборки и по возможности оптимизируя скомпилированный код на C++ по размеру. Снижение производительности компактной VM до 5 % допустимо. У обычных (не компактных) сборок производительность снижаться не должна.

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

Сохранять все возможности не планируется. Делать функциональность необязательной во время выполнения не планируется.

Критерии успеха

Размер libjvm.so меньше 3 МБ, а производительность снижается не более чем на 5 %.

Мотивация

У небольших устройств очень строгие требования к статическому и динамическому объёму занимаемой памяти. Чтобы Java хорошо работала на таких устройствах, нам нужно уменьшить общий статический и динамический объём памяти, занимаемый JRE.

Описание

Ранее попытка уменьшить размер libjvm.so предпринималась при реализации Java Kernel. В kernel VM были удалены многие крупные компоненты, например дополнительные сборщики мусора, JIT-компилятор C2 и бо́льшая часть JVMTI.

Kernel VM не поддерживалась и так и не была реализована для Linux. Первый шаг этого проекта — возродить аналог этой VM для Linux.

В kernel VM файлы makefile и связанные с ними файлы сборки изменялись так, чтобы исключить файлы, не нужные для требуемой функциональности. Мы выбираем немного другой подход и планируем изменять исходные файлы с помощью условной компиляции, а не файлы сборки. Существующий условный символ KERNEL станет MINIMAL_JVM, а исходные файлы, которые исключались в kernel VM, будут обёрнуты в #ifndef MINIMAL_JVM. Кроме того, для более точного управления тем, что входит в минимальную VM, будут определяться символы вроде INCLUDE_\<something>, подключающие функциональность, которая иначе была бы исключена. Для минимальной VM эти символы определяться не будут.

Когда минимальная VM станет стабильной на нужных платформах, другая ненужная функциональность будет сделана необязательной. Основной способ, которым, как мы считаем, это можно сделать, — удалить из минимальной VM JVMTI, поддержку java.lang.instrument (реализованную в sun.instrument), sun.management и мониторинг (часть PerfDataManager).

Бо́льшая часть JVMTI уже удалена из kernel VM. Оставшийся код JVMTI будет включаться условно на этапе сборки с помощью #ifdef.

Публичные API удалённой функциональности, возможно, придётся изменить так, чтобы они выбрасывали соответствующие исключения, если функциональность не реализована.

Другая часть этого проекта — найти файлы, которые можно оптимизировать по размеру без потери производительности. Для этого нужно изменить процесс сборки так, чтобы было легко указать, какие файлы оптимизировать по размеру. Для оптимизации по размеру большинства файлов мы будем использовать опцию gcc -Os. На некоторых платформах могут быть и другие опции для уменьшения размера. Если производительность заметно снизится, с помощью профилирования будет определено, какие файлы можно компилировать с -O3 для ускорения. Для этого, возможно, придётся переносить функции в другие файлы, чтобы так компилировались только функции, важные для производительности.

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

API должны вести себя корректно, если код нижележащей реализации отсутствует. Изменения должны проходить Java SE 8 TCK. Потребуется тестирование производительности, чтобы измерить влияние работы по уменьшению размера.

Риски и допущения

Возможно, в VM есть зависимости от удалённой функциональности, о которых мы не знаем.

Возможно, хотя и маловероятно, что необязательной функциональности, которую можно удалить, окажется недостаточно для достижения нашей цели.

Предполагается, что в JDK 8 размер libjvm.so существенно не увеличится.

Влияние

• Другие компоненты JDK: некоторые инструменты могут зависеть от отсутствующего кода.

• Совместимость: JVMTI не будет поддерживаться в минимальной бинарной сборке.

• Производительность и масштабируемость: при сборке этой конфигурации может быть заметно небольшое влияние на производительность.

• Документация: нужно задокументировать, что не поддерживается в этой бинарной сборке и что происходит, если пользователь или инструменты пытаются обратиться к отсутствующей функциональности.

• TCK: для поддержки изменений API, вызванных удалением возможностей, могут потребоваться изменения в TCK.

• QA: потребуется дополнительное тестирование, чтобы убедиться, что компактная бинарная сборка работает корректно. Возможно, тесты придётся обновить с учётом необязательной функциональности.

• Опыт пользователей: пользователи могут ожидать полной функциональности во всех VM, но часть функциональности в компактной VM будет отсутствовать.