Как вы все знаете, вчера прошел первый день долгожданного JavaOne. Стоить заметить, что в Москве данное мероприятие проходит впервые, чему я несказанно рад. Было много разных интересных и полезных докладов, но всех больше мне понравилась секция про слияние HotSpot и JRockit. Во-первых, я мало что знал про JRocket, во-вторых, эту новость я слышал впервые, а в докладе было довольно много подробностей. Презентации выложат на официальном сайте мероприятия только через две недели, поэтому я все таки решил пересказать услышанное в вольном исполнении. Тем более по комментариям к одному из моих предыдущих постов, я так понял, что на хабре не очень много людей знакомых с JRockit, так что, думаю, топик будет интересен хабрасообществу.
Данное решение обусловлено сокращением издержек. Oracle заметил, что требования клиентов к обоим JVM в общем-то совпадают и пользователи хотят видеть одинаковые вещи в обоих продуктах. Для достижения этих целей разработчики обеих JVM независимо приходят к реализации одних и тех же идей, например, EscapeAnalysis и предсказуемый сборщик мусора (Garbage First у HotSpot и Deterministic GC у JRockit). Так зачем же спрашивается дублировать работу?
Каждое решение имеет свои сильные и слабые стороны. На данный момент сильными сторонами HotSpot можно считать широкую область использования, большую клиентскую базу, высокую отказоустойчивость и производительность. JRockit же выделятся своей оптимизацией под стек продуктов Oracle на Linux и Windows, наличия soft real-time решения и версии для запуска на голом железе без операционки (конечно же на специальном железе, а не произвольном).
На удивление были долгие дискуссии какую же JVM взять за базу. В итоге было принято решение в пользу HotSpot, но аргументы были не техническими. Причинами послужили существование OpenJDK, сделанной на основе HotSpot, количество инженеров работающих над HotSpot (инженеры работающие на JRockit будут реализовывать фичи своего детища в новой общей JDK), лицензии выданные IBM, HP и другим компаниям на модификацию HotSpot. Есть и грустная новость — не весь мерж попадет в OpenJDK. Первые результаты объединения можно будет уже увидеть в Java 7. Например, там уже планируется перевести PermGen на C-heap. Закончить всю работу по слиянию планируется в течении двух лет.
Какие требования предъявляются к современной виртуальной машине? Первое — масштабируемость. Виртуальная машина должна работать на большом спектре машин — от мобильников до мэйнфреймов, давать возможность работы с большими объемами памяти, эффективно работать на большом количестве аппаратных потоков (~10000) и учитывать топологию памяти. Второе — скорость. Виртуальная машина должна быть высокопроизводительной, предсказуемой (JIT, GC), быстро стартовать и иметь маленькие накладные расходы (footprint).
NUMA аллокация. Позволяет создавать объект в памяти ближе к тому процессору, на котором происходит работа. Так как вероятность, что поток создавший объект и будет с ним работать больше, то профит на лицо. Различные тесты показали прирост производительности от 25 до 300%.
Оптимизация работы со строками. Не для кого не секрет, что различные приложение очень много работают со строками, если и не на прамую, то различные библиотечные методы все равно их создают. Например были сделаны такие оптимизации как слияние строк (-XX:+OptimizeStringConcat), копирование строк, сжатие строк (-XX:+UseCompressedStrings, доступно только в 6u21p, потом отключили), которое позволяет хранить символы в массиве байтов, если возможно, а так же кэширование строк (XX:+UseStringCache).
Сжатые указатели. Включается автоматически, если JVM решит, что это даст профит. Но можно включить и с помощью параметра -XX:+UseCompressedOops. Данное сжатие происходит за счет сдвигов, которые помагают сократить место теряющиеся при выравнивании. С данной опцией можно работать с памятью до 32 Гб. Говорят, что работает даже быстрее чем 32-битная JVM.
Garbage Firts. Начиная с версии 6u14 можно включить параметром -XX:+UseG1GC. Данный сборщик уже работает весьма стабильно, но еще не закончен, так как остались небольшие проблемы с производительностью (случаются спайки).
Ступенчатая компиляция. Для того чтобы иметь быстрый startup, JVM запускается с клиентским JIT компилятором, после некоторого времени компилятор меняется на серверный.
Ну и конечно же уже столько раз обмусоленный EscapeAnalysis и более эффективное копирование массивов.
На фронте JRockit можно выделить надежность и предсказуемость. Использование модели согласованного прерывания потоков. Мощный JIT компилятор. API для тестирования плюс набор хорошо покрывающих тестов (HotSpot этого очень не хватает на сколько я знаю). Сэмплирующий компилятор.
В JRockit присутствует очень мощный инструментарий для поддержки и отладки. Можно выделить наличие так называемого «бортового самописца», который записывает все что происходило с JVM и расшифровка которого поможет разобраться при наступлении нестандартной ситуации. Для мониторинга текущего состояния существует такой тул как Mission Control, который выглядит заметно по-мощнее чем Visual VM для HotSpot. Так же есть возможность отслеживать нативную память и делать тонкую настройку JIT. В режиме сжатия указателей JRockit может адресовать уже 64гб. Сборщик мусора в среднем занимает на 30% меньше чем у HotSpot.
Если вы работаете со стеком Oracle на Linux или Windows, то Oracle рекомендует использовать JRockit. Во всех остальных случаях — HotSpot.
Oracle хочет сделать доступным Mission Control для новой объединённой JVM. Переделать PermGen на нативную память (C-heap). Сделать ввод-вывод без копирования, для чего нужно будет реализовать механизм запрещения перемещения объектов GC находящихся в определенной фазе обработки. Сделать API для управления сборщиком мусора и компилятором. Добавить возможность работы с фрагментированной памятью. Сделать возможность запуска на голом железе. Ну и конечно же улучшение сборщика мусора в плане предсказуемости пауз.
На объединение Oracle останавливаться не намерен, и в некоторой перспективе мы можем надеяться увидеть NUMA extreme, как дальнейшее развитие заботы с NUMA. Еще более предсказуемый G1. Возможность запуска нескольких приложений в одной JVM с опциональной возможностью эффективного взаимодействия. Эргономика на исторических данных и предварительная компиляция. Идея в том чтобы при запуске приложения использовать данные собранные при предыдущих запусках и работы приложения. Еще планируется работа над возможностью эффективного использования JVM в кластере/облаке, когда ресурсы выделяемые JVM могут изменятся. Так же рассматривается возможность поддержки гетерогенных процессоров GPU.
В заключении докладчик показал стандартный слайд на котором говорилось, что все сказанное является текущими планами Oracle, которые могут поменяться, и что они ничего не обещают. А еще порекомендовал ссылку на блог сотрудника Oracle, отвечающего за стратегию развития JVM.
Причина слияния HotSpot и JRockit
Данное решение обусловлено сокращением издержек. Oracle заметил, что требования клиентов к обоим JVM в общем-то совпадают и пользователи хотят видеть одинаковые вещи в обоих продуктах. Для достижения этих целей разработчики обеих JVM независимо приходят к реализации одних и тех же идей, например, EscapeAnalysis и предсказуемый сборщик мусора (Garbage First у HotSpot и Deterministic GC у JRockit). Так зачем же спрашивается дублировать работу?
Какую JVM взять за основу?
Каждое решение имеет свои сильные и слабые стороны. На данный момент сильными сторонами HotSpot можно считать широкую область использования, большую клиентскую базу, высокую отказоустойчивость и производительность. JRockit же выделятся своей оптимизацией под стек продуктов Oracle на Linux и Windows, наличия soft real-time решения и версии для запуска на голом железе без операционки (конечно же на специальном железе, а не произвольном).
На удивление были долгие дискуссии какую же JVM взять за базу. В итоге было принято решение в пользу HotSpot, но аргументы были не техническими. Причинами послужили существование OpenJDK, сделанной на основе HotSpot, количество инженеров работающих над HotSpot (инженеры работающие на JRockit будут реализовывать фичи своего детища в новой общей JDK), лицензии выданные IBM, HP и другим компаниям на модификацию HotSpot. Есть и грустная новость — не весь мерж попадет в OpenJDK. Первые результаты объединения можно будет уже увидеть в Java 7. Например, там уже планируется перевести PermGen на C-heap. Закончить всю работу по слиянию планируется в течении двух лет.
Требования к современной виртуальной машине
Какие требования предъявляются к современной виртуальной машине? Первое — масштабируемость. Виртуальная машина должна работать на большом спектре машин — от мобильников до мэйнфреймов, давать возможность работы с большими объемами памяти, эффективно работать на большом количестве аппаратных потоков (~10000) и учитывать топологию памяти. Второе — скорость. Виртуальная машина должна быть высокопроизводительной, предсказуемой (JIT, GC), быстро стартовать и иметь маленькие накладные расходы (footprint).
Последние новинки и оптимизации HotSpot
NUMA аллокация. Позволяет создавать объект в памяти ближе к тому процессору, на котором происходит работа. Так как вероятность, что поток создавший объект и будет с ним работать больше, то профит на лицо. Различные тесты показали прирост производительности от 25 до 300%.
Оптимизация работы со строками. Не для кого не секрет, что различные приложение очень много работают со строками, если и не на прамую, то различные библиотечные методы все равно их создают. Например были сделаны такие оптимизации как слияние строк (-XX:+OptimizeStringConcat), копирование строк, сжатие строк (-XX:+UseCompressedStrings, доступно только в 6u21p, потом отключили), которое позволяет хранить символы в массиве байтов, если возможно, а так же кэширование строк (XX:+UseStringCache).
Сжатые указатели. Включается автоматически, если JVM решит, что это даст профит. Но можно включить и с помощью параметра -XX:+UseCompressedOops. Данное сжатие происходит за счет сдвигов, которые помагают сократить место теряющиеся при выравнивании. С данной опцией можно работать с памятью до 32 Гб. Говорят, что работает даже быстрее чем 32-битная JVM.
Garbage Firts. Начиная с версии 6u14 можно включить параметром -XX:+UseG1GC. Данный сборщик уже работает весьма стабильно, но еще не закончен, так как остались небольшие проблемы с производительностью (случаются спайки).
Ступенчатая компиляция. Для того чтобы иметь быстрый startup, JVM запускается с клиентским JIT компилятором, после некоторого времени компилятор меняется на серверный.
Ну и конечно же уже столько раз обмусоленный EscapeAnalysis и более эффективное копирование массивов.
Преимущества JRockit
На фронте JRockit можно выделить надежность и предсказуемость. Использование модели согласованного прерывания потоков. Мощный JIT компилятор. API для тестирования плюс набор хорошо покрывающих тестов (HotSpot этого очень не хватает на сколько я знаю). Сэмплирующий компилятор.
В JRockit присутствует очень мощный инструментарий для поддержки и отладки. Можно выделить наличие так называемого «бортового самописца», который записывает все что происходило с JVM и расшифровка которого поможет разобраться при наступлении нестандартной ситуации. Для мониторинга текущего состояния существует такой тул как Mission Control, который выглядит заметно по-мощнее чем Visual VM для HotSpot. Так же есть возможность отслеживать нативную память и делать тонкую настройку JIT. В режиме сжатия указателей JRockit может адресовать уже 64гб. Сборщик мусора в среднем занимает на 30% меньше чем у HotSpot.
Какую из своих JVM Oracle рекомендует использовать сейчас?
Если вы работаете со стеком Oracle на Linux или Windows, то Oracle рекомендует использовать JRockit. Во всех остальных случаях — HotSpot.
Какой функционал будет перенесен?
Oracle хочет сделать доступным Mission Control для новой объединённой JVM. Переделать PermGen на нативную память (C-heap). Сделать ввод-вывод без копирования, для чего нужно будет реализовать механизм запрещения перемещения объектов GC находящихся в определенной фазе обработки. Сделать API для управления сборщиком мусора и компилятором. Добавить возможность работы с фрагментированной памятью. Сделать возможность запуска на голом железе. Ну и конечно же улучшение сборщика мусора в плане предсказуемости пауз.
Перспективы развития объединенной JVM
На объединение Oracle останавливаться не намерен, и в некоторой перспективе мы можем надеяться увидеть NUMA extreme, как дальнейшее развитие заботы с NUMA. Еще более предсказуемый G1. Возможность запуска нескольких приложений в одной JVM с опциональной возможностью эффективного взаимодействия. Эргономика на исторических данных и предварительная компиляция. Идея в том чтобы при запуске приложения использовать данные собранные при предыдущих запусках и работы приложения. Еще планируется работа над возможностью эффективного использования JVM в кластере/облаке, когда ресурсы выделяемые JVM могут изменятся. Так же рассматривается возможность поддержки гетерогенных процессоров GPU.
В заключении докладчик показал стандартный слайд на котором говорилось, что все сказанное является текущими планами Oracle, которые могут поменяться, и что они ничего не обещают. А еще порекомендовал ссылку на блог сотрудника Oracle, отвечающего за стратегию развития JVM.
