Не совсем понял, что считать годной реализацией? JNI много где есть. Например, в нашем проекте one-nio, часто его в докладах упоминаем. Изначально он ant'ом собирался, и в maven поэтому используется maven-antrun-plugin для вызова gcc. Максимально просто. Если хочется чего-то более масштабного, можно взглянуть на netty.
Так и есть: кто пользовался JNI, освоит JVM TI без труда. По функциональности JNI более прикладной, JVM TI ближе к системному, но они отлично дополняют друг друга.
А в вашем получившемся образе, смотрю, отсутствуют даже самые базовые диагностические утилиты вроде jstack и jmap. Или вы не мониторите и не профилируете приложения в продакшне?
А что libc? Его в Ubuntu надо отдельно устанавливать? Давайте пойдём дальше и скажем, что сборки не самодостаточны хотя бы потому, что требуют наличия операционной системы и совместимого железа.
Я говорил, что на свежеустановленной Ubuntu 18.04 apt install предложил поставить пакетов на 666 MB (либо 637 MB с --no-install-recommends), в то время как другая сборка, занимающая 96 MB, без проблем запускала все те же Java приложения.
Кроме того, в дефолтном пакете openjdk-11-jdk из бинарников удалены debug символы, из-за чего нормально не работает профайлер в IntelliJ IDEA. Чтобы это исправить, требуется дополнительно установить пакет openjdk-11-dbg ещё примерно на 200 MB.
Тем не менее, я полностью согласен, что установка одной командой через apt install — это огромное преимущество, и большинству юзеров даже не нужно знать про существование каких-то альтернативных сборок.
Спасибо, я в курсе про зависимости. Только я про то и говорю, что другие сборки самодостаточны и отлично работают без сотен мегабайт зависимостей, в том числе, с графикой, аудио и т. д.
Затем, что дефолтные пакеты в Ubuntu, Debian, RHEL и CentOS далеко не самые удачные. Во-первых, они слишком жирные:
$ sudo apt install openjdk-11-jdk
...
Need to get 270 MB of archives.
After this operation, 666 MB of additional disk space will be used.
Для сравнения, Liberica JDK 11 lite в установленном виде занимает менее 100 MB.
Во-вторых, при всей своей объёмности в этих пакетах не хватает нужных символов для продвинутых Java профайлеров вроде async-profiler или perf-map-agent (на мой взгляд, обязательных для современного Java разработчика). Символы эти авторы решили вынести в отдельный пакет с кучей другого отладочного барахла, которое занимает ещё 200+ MB. Кстати, можете с ходу вспомнить, как этот пакет называется?
Я уж не говорю о том, что убунтовские сборки не сертифицированы и формально не могут называться Java compatible.
Не совсем. Например, в первом случае есть переменная sb, которую можно найти по имени и посмотреть значение в дебаггере на середине выражения. А ещё код StringBuilder может быть инструментирован и вернуть внезапно не this.
Для меня остаётся непонятным, почему интринсик не сработал при обращении к StringBuilder.append(String)
А это и не интринсик. По крайней мере, сам по себе. Только лишь в составе выражений вида new StringBuilder().append()...append().toString();
JIT компилятор распознаёт подобные цепочки и транслирует их как единое целое. Называется OptimizeStringConcat. Про это уже писали и на Stack Overflow, и на Хабре.
Скорее всего это OpenJDK от Redhat — но как проверить?
Да, именно так. java -Xinternalversion скажет: OpenJDK 64-Bit Server VM (25.191-b12) for linux-amd64 JRE (1.8.0_191-b12), built on Nov 19 2018 16:07:16 by "mockbuild" with gcc 4.8.5 20150623 (Red Hat 4.8.5-36)
Ещё тому подтверждение, что в JDK от Red Hat есть сборщик мусора Shenandoah. Можно проверить флагом java -XX:+UseShenandoahGC.
Плохо, что в статье так и не раскрыто, чем же всё-таки сборки отличаются друг от друга. Вот, в Red Hat как раз Shenandoah GC. А, например, в Amazon Coretto по сравнению со стоковой OpenJDK такой список патчей.
как проверить что эта реализация от Oracle?
Все производные от OpenJDK в той или иной степени «от Oracle». На самом деле, в Ubuntu своя собственная сборка от Canonical.
Не отличается на уровне архитектуры — в том смысле, что используется точно такая же mov инструкция, — но на уровне компилятора, естественно, отличается. Два чтения volatile поля всегда будут двумя операциями чтения из памяти, и компилятор не имеет права это оптимизировать. В случае с не-volatile полем второе чтение может быть оптимизировано.
Отличный вопрос! Да, есть проблема с лямбдами, что нельзя менять их порядок в исходниках. Автоматического обнаружения таких ситуаций у нас нет. Однако у ошибки мало шансов попасть в продакшн: даже если её не заметят на code review, дальше тестового сервера она вряд ли уйдёт.
Комментарием выше я как раз на это ответил. Мы ровно так и делаем при плановых релизах. А патчинг мы используем не для выкладки новой версии, а для небольших оперативных исправлений. Перевести трафик на один «чистый» сервер — не проблема. А когда сервис работает на 600 хостах — процедура сложнее и, главное, дольше.
патчить на продакшне через интерфейс, предназначенный для дебага — это странное решение
Это необычно, согласен. Поэтому и удостоилось статьи. Ключевая особенность фиксов через HCR — что это происходит без даунтайма и без потери состояния. Все текущие соединения, запросы, накопленные данные, кеши, значения переменных — всё остаётся. Не требуется никакой активации/деактивации модулей и никакой миграции со старой версии на новую. OSGi в данном случае не поможет.
а если патчуемый код уже заинструменчен каким-нибудь фреймворком в рантайме? Будет ли повторно вызываться инструментация фреймворка или нет?
Смотря как фреймворк работает. Если он регистрирует инструментацию через Instrumentation.addTransformer, то после патчинга трансформация будет выполнена повторно.
а как вы тестируете сам процесс патчинга?
Зависит от сложности патча. В общем случае применяем сначала на тестовом сервере, потом на одном продакшн сервере, проверяем функциональность руками и/или автотестами, затем применяем на группе хостов, смотрим графики, и, наконец, на всём продакшне. Если патч сломался, его можно отменить применением обратного патча, либо уже традиционной процедурой апдейта. На практике до откатывания патча ни разу дело не доходило.
перезагрузка одного сервиса никак не должна влиять на общую работу
Перезагрузка одного сервера — да. А если надо рестартануть кластер из 600 инстансов? Это надо делать частями, с выводом трафика и плавным заводом, при этом старт и прогрев приложения может занимать десятки минут. Именно так и делается при плановых апдейтах, но это занимает время. Патчинг не заменяет апдейты. Он для простых, но срочных фиксов.
А в вашем получившемся образе, смотрю, отсутствуют даже самые базовые диагностические утилиты вроде
jstackиjmap. Или вы не мониторите и не профилируете приложения в продакшне?Я говорил, что на свежеустановленной Ubuntu 18.04 apt install предложил поставить пакетов на 666 MB (либо 637 MB с --no-install-recommends), в то время как другая сборка, занимающая 96 MB, без проблем запускала все те же Java приложения.
Кроме того, в дефолтном пакете openjdk-11-jdk из бинарников удалены debug символы, из-за чего нормально не работает профайлер в IntelliJ IDEA. Чтобы это исправить, требуется дополнительно установить пакет openjdk-11-dbg ещё примерно на 200 MB.
Тем не менее, я полностью согласен, что установка одной командой через apt install — это огромное преимущество, и большинству юзеров даже не нужно знать про существование каких-то альтернативных сборок.
Для сравнения, Liberica JDK 11 lite в установленном виде занимает менее 100 MB.
Во-вторых, при всей своей объёмности в этих пакетах не хватает нужных символов для продвинутых Java профайлеров вроде async-profiler или perf-map-agent (на мой взгляд, обязательных для современного Java разработчика). Символы эти авторы решили вынести в отдельный пакет с кучей другого отладочного барахла, которое занимает ещё 200+ MB. Кстати, можете с ходу вспомнить, как этот пакет называется?
Я уж не говорю о том, что убунтовские сборки не сертифицированы и формально не могут называться Java compatible.
new StringBuilder().append()...append().toString();JIT компилятор распознаёт подобные цепочки и транслирует их как единое целое. Называется OptimizeStringConcat. Про это уже писали и на Stack Overflow, и на Хабре.
OpenJDK 64-Bit Server VM (25.191-b12) for linux-amd64 JRE (1.8.0_191-b12), built on Nov 19 2018 16:07:16 by "mockbuild" with gcc 4.8.5 20150623 (Red Hat 4.8.5-36)Ещё тому подтверждение, что в JDK от Red Hat есть сборщик мусора Shenandoah. Можно проверить флагом
java -XX:+UseShenandoahGC.Плохо, что в статье так и не раскрыто, чем же всё-таки сборки отличаются друг от друга. Вот, в Red Hat как раз Shenandoah GC. А, например, в Amazon Coretto по сравнению со стоковой OpenJDK такой список патчей.
Все производные от OpenJDK в той или иной степени «от Oracle». На самом деле, в Ubuntu своя собственная сборка от Canonical.
Зависит от сложности патча. В общем случае применяем сначала на тестовом сервере, потом на одном продакшн сервере, проверяем функциональность руками и/или автотестами, затем применяем на группе хостов, смотрим графики, и, наконец, на всём продакшне. Если патч сломался, его можно отменить применением обратного патча, либо уже традиционной процедурой апдейта. На практике до откатывания патча ни разу дело не доходило.
Перезагрузка одного сервера — да. А если надо рестартануть кластер из 600 инстансов? Это надо делать частями, с выводом трафика и плавным заводом, при этом старт и прогрев приложения может занимать десятки минут. Именно так и делается при плановых апдейтах, но это занимает время. Патчинг не заменяет апдейты. Он для простых, но срочных фиксов.