Есть ли различия в производительности между OpenJDK и Oracle?
Oracle недавно решила начать взимать плату за коммерческое использование своей JVM.
Наша команда вместо этого начала переключаться на использование OpenJDK и обнаруживает, что все работает нормально, за исключением того, что у нас снижается производительность.
Наши серверы являются серверами Linux, и согласно нашей команде производительности,
Мы наблюдали значительную медлительность на большинстве вызовов Java. Мы просмотрели журналы и исследовали несколько звонков, и мы не видим никаких исключений или ошибок, только медлительность.
У кого-нибудь еще есть данные о том, правда ли это, что OpenJDK в среднем медленнее, чем Oracle JVM?
ОТВЕТ: Для нас проблема была определена как-то haproxy на Ubuntu и OpenJDK. Если бы эти 3 вещи были объединены, мы бы увидели дополнительную задержку в 5 мс на каждом сокетном соединении. Измените любой из этих 3 факторов, и производительность будет восстановлена.
Я также опубликую это как ответ, так что это может быть замечено в обоих местах
3 ответа
Вы найдете интересную выдержку из сообщения в блоге Oracle:
Вопрос: В чем разница между исходным кодом, найденным в репозитории OpenJDK, и кодом, который вы используете для сборки Oracle JDK?
A: Это очень близко - наш процесс сборки для Oracle JDK выпускает сборку на OpenJDK 7, добавив всего лишь пару частей, таких как код развертывания, который включает в себя реализацию Oracle надстройки Java и Java WebStart, а также некоторые третьи с закрытым исходным кодом. сторонние компоненты, такие как графический растеризатор, некоторые сторонние компоненты с открытым исходным кодом, такие как Rhino, и несколько кусочков, вроде дополнительной документации или сторонних шрифтов. В дальнейшем мы намереваемся открыть все части Oracle JDK с открытым исходным кодом, кроме тех, которые мы рассматриваем как коммерческие функции, такие как JRockit Mission Control (пока недоступно в Oracle JDK), и заменить обремененные сторонние компоненты альтернативами с открытым исходным кодом, чтобы добиться более четного паритета. между базами кода.
Поскольку Oracle отвечает за создание обоих, ясно, что она будет гарантировать, что у ее клиентов будут веские причины для оплаты, а производительность - очевидное средство.
Я считаю, что OpenJDK - JVM только для интерпретатора. Это проще портировать, так как у него нет специфичного для архитектуры кода сборки, но, к сожалению, он менее производительный.
OracleJDK Я думаю, что использует преимущества платформы ABI с плавающей запятой (Soft Float на RP1 и Hard Float на RP2). В нем также может быть некоторое количество специфичного для платформы кода, чтобы сделать его быстрее.
JIT (Just-in-Time) компилятор был когда-то включен в оба, с именем Shark, но я не знаю, включен ли он в OpenJDK. В Википедии OpenJDK не упоминается JIT, и я нашел эту старую и волнующую проблему - компилятор Remove Shark. Тем не менее, история версий Java в Википедии включает JIT.
Если OracleJDK сегодня включает JIT-компилятор для конкретной платформы, а OpenJDK - нет, это вполне может объяснить разницу в производительности,
Что касается Java 11, различия в основном заключаются в установщике, поставщиках шифрования (подписанные и неподписанные) и нескольких параметрах командной строки для расширенного управления и перехода с более ранних версий, как описано в этом сообщении в блоге Oracle: https: // blogs.oracle.com / Java-платформы группа / оракул-JDK-релизы-для-Java-11-и-потом
Более ранние версии имели несколько дополнительных отличий: у них были другие 2D-библиотеки, рендеринг шрифтов, средства обслуживания / управления и криптографические библиотеки, которые могли вызвать различия в производительности, как описано здесь: https://www.thegeekdiary.com/openjdk-v-s-oracle-jdk-differences-between-openjdk-and-oracle-jdk/. Управление памятью и совместное использование данных классов также могут быть причиной разных характеристик производительности.
Для нас проблема была решена как-то связана с haproxy на Ubuntu, а также OpenJDK,
Если бы эти 3 вещи были объединены, мы бы увидели дополнительную задержку в 5 мс на каждом сокетном соединении.
Измените любой из этих 3 факторов, и производительность будет восстановлена.
Нашим конкретным решением было изменить наши балансировщики нагрузки haproxy, чтобы использовать Centos вместо Ubuntu.