Хабрахабр

«Java-мир больше никогда не будет прежним» — интервью с Александром Белокрыловым и Алексеем Войтыловым из BellSoft

Остаются последние дни перед Joker, и очень хотелось принести на Хабр не обычное интервью, а какой-нибудь мощной дичи. В последнее время люди интересуются серверами на Arm, и так получилось, что у нас есть по этой теме реальные специалисты.

Сейчас компания успешно работает, развивается и уже успела получить известность в Java-мире. Александр (alexbel) Белокрылов и Леша Войтылов, совместно с Григорием Лабзовским, который руководил центром разработки Oracle в Санкт-Петербурге, чуть более года назад основали компанию BellSoft.

По объему коммитов в OpenJDK за прошлый год они вышли на пятое место, и теперь впереди только Oracle, Red Hat, SAP и Google:

Надо понимать, что BellSoft — это не только Arm:

  • Вышла Liberica JDK 11, поддерживаются Linux x86_64, Windows, Linux ARMv8, Linux ARMv7 (включая Raspberry Pi). Будут выкладываться сборки для Mac и Solaris Sparc.
  • Публикуются образы под все архитектуры на Docker Hub для Debian, CentOS, Alpine. Образ для Alpine делается из lite версии с --compress 2 поэтому существенно меньше обычного JDK.

В этом интервью мы коснемся только Arm, а всё остальное оставим на следующий раз.
Итак, сегодня у нас в виртуальной студии:

Александр Белокрылов

Леша Войтылов

Олег Чирухин — редакция JUG.ru Group

Расскажите о компании подробнее?

Все, наверное знают, что компания Oracle в Санкт-Петербурге обладала очень серьезной низкоуровневой экспертизой в разработке Java Runtime, в разработке компиляторов, в разработке систем Cloud-сервисов Oracle. Компания BellSoft занимается несколькими направлениями. Сегодня наша компания занимается разработкой Java Runtime, мы активный OpenJDK contributor, занимаемся разработкой компиляторов gcc и llvm, контрибьютим в стек Apache, Graal. И эта экспертиза из Oracle перекочевала в компанию BellSoft. В какой-то момент мы увидели, что Oracle перестал выпускать дистрибутив Java для Arm-платформ, и мы выпустили свой дистрибутив, который назвали Liberica JDK для Raspberry Pi. Занимаемся построением систем анализа больших данных, рекомендательных систем и построили небольшой проект по IoT, по сбору данных с устройств из реального мира. С тех пор успешно его поддерживаем.

Что такое, например, стек Apache?
Давай разберем подробней.

OpenJDK и большие Apache проекты, пусть и не напрямую, но сильно взаимосвязаны.
Мы начали контрибьютить в Apache Foundation с Hadoop — на определенные части этого проекта многое завязано.

Например, какие-то классы, которые тормозят их, их можно разогнать?
Зачем всё это может быть нужно?

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

Может быть, где-то есть такая же проблема. Когда ты решаешь проблемы с перформансом, имеет смысл посмотреть что-то близкое. Иногда (и очень часто) оптимизации производительности раскладывается на contributions в несколько проектов. Очень часто видишь, что поправив в одном месте, нужно поправить еще в паре мест, чтобы в общем стало лучше. Допустим, это Java. Если хочется улучшить, например, производительность checksum, вы посмотрите в самый низ стека. Обычно поняв, как улучшить одно место, можно понять, как сделать и в другом месте. Если посмотреть чуть выше, это будет Hadoop, Spark или что-то еще. Разумеется, имеет смысл в таком случае пойти и улучшить там тоже.

Все знают, что вы — Liberica 🙂 Давайте поговорим вот об этом.

Liberica начиналась с того, что мы увидели, что нет порта для ARM32, и его срочно нужно сделать, потому что Raspberry Pi осталась без Java 9 и Java 10. Да, мы — Liberica JDK. Теперь Liberica JDK поддерживает много архитектур и операционных систем. Это было в 2017 году, когда вышла Java 9.

Стало понятно, что людям это нужно.
Стало понятно, что Oracle не собирается дальше развивать код для Arm, и мы стали активно контрибьютить и выпускать свой дистрибутив, чтобы закрыть эту брешь.

Получается, сейчас есть несколько дистрибутивов Arm?

В нашем вы получаете фактически то, что раньше было частью дистрибутива порта Oracle. Да, есть несколько дистрибутивов Java для Arm, они отличаются. Это некий пакет, и все это работает с модулями, начиная с JDK 9. В нашем дистрибутиве присутствует JavaFX, device input/output и API для эмбеддеда. Если хотите, можете сделать маленький Runtime размером 16 мегабайт. Используя модульную систему, вы можете собрать Runtime, как вы хотите. Можете получить работающий Runtime под ваши нужды. Если хотите включить больше фич, например, web-сервер, тогда нужно потратить примерно 32 мегабайта статического места.

Не сказать, чтобы ими у нас пользовались массово. Насколько понял, речь пошла об армовых серверах. В реальной жизни они есть вообще?
Расскажи про сервера?

Самый первый Arm-сервер был сделан на основе архитектуры ARMv7, 32-битной. Этой истории уже много лет. Та компания, которая это начинала, Calxeda, со временем закрылась. Это была жутко шумящая коробка, которая практически не работала, потому что там не работал BIOS, Linux, все что угодно через несколько часов отпадало. Arm со временем выпустил новую спецификацию архитектуры ARMv8, которая поддерживает как 32, так и 64 бит. Но идея развития альтернативной архитектуры для серверов была посеяна в общество. Например, Ampere Computing, Cavium, который нынче куплен компанией Marvell, и еще Qualcomm. На основе 64-битной версии этой спецификации сейчас несколько производителей строят свои реализации процессоров для серверов. По-моему, до сих пор продолжают это делать. И есть еще одна компания — AMD несколько лет назад выпускал тоже сервера на основе Arm-архитектуры.

Хороший способ запомнить названия всех этих контор.
Если убрать из Marvell одну букву L, получатся супергерои.

Можно ставить несколько CPU в один сервер, у вас получается монструозная штука с быстрой памятью, которую можно применять для серьезных задач. Супергерои там на самом деле Cavium/Marvell, потому что из всех именно им удалось собрать наиболее производительный чип вплоть до 128 тредов на одном CPU, и сравнимый или лучший по производительности с Xeon Gold и Platinum.

Сколько CPU имеет смысл втыкать в один сервер?
Как растет предел масштабирования для обычного применения?

Разные производители ориентируются на разные ниши, но если мы говорим про Cavium/Marvell, они четко ориентируются на нишу компьютинга, где нужно достаточно быстро прожевать большой объем данных в параллель. Все зависит от того, для какой задачи вы хотите построить сервер. Они не ориентируются на супер большую производительность одной нитки (вместе с тем, она очень неплоха), а именно, чтобы в целом данный CPU показывал большую производительность при низком потреблении стоимости.

Есть у нас замечательные интеловские сервера, зачем придумывать что-то еще?
А почему Arm, а не Intel?

Во-первых, свято место пусто не бывает. На этот вопрос и сложно, и просто ответить. И понятное дело, всегда будет какой-то альтернативный кусок рынка у альтернативных производителей. Мы видим, что и AMD пытается построить какую-то альтернативу Intel для серверных применений.

Никто не хочет жить с одним монополистом.

Все потребители процессоров, а это в в основном, Cloud-провайдеры, хотят иметь возможность альтернативы. Очень верное замечание. Чтобы можно было выбирать, сравнивать стоимость с затратами и под конкретные применения выбирать более выгодную архитектуру.

Насколько это дороже, чем решения от Intel?
А что по затратам?

Во-первых, как Алексей сказал, производителей — достаточно. Сложный вопрос. Занимают немного разные ниши. Понятно, что сейчас производители Arm-процессоров не конкурируют друг с другом, а конкурируют с кем-то другим. Если Cavium — это high performance computing, то Qualcomm — mid-range servers, Ampere — это либо workstations, либо low-end servers.

Cavium чуть дороже. Если правильно помню, цена самого CPU от Ampere Computing — 600-900 долларов, и они конкурируют с Intel, CPU стоимостью около 1500 долларов. Нужно понимать, что цена сервера складывается не только из цены CPU. Опять же, они будут конкурировать с Intel, который существенно дороже. Если вы выигрываете по одному параметру, например, стоимости CPU — это прекрасно, но вы будете лишь чуть-чуть дешевле. Цена сервера — это еще память, диски, поддержка, потребление. А если по трем, например, еще и делать все это при меньшем потреблении электроэнергии, то это уже заявка на победу. Если выигрываете по двум параметрам, например, будучи дешевле, предлагать еще и лучшую производительность, на вас будут смотреть уже более пристально.

Нельзя на Arm запустить всё что у тебя сейчас крутится на Intel.
Кроме железа и его поддержки еще важна поддержка в софте.

Нужно сказать, что Arm-экосистема софта шагнула далеко вперед. Разумеется. Вы просто приходите, и у вас всё работает out of the box. Если пять лет назад были проблемы с тем, чтобы поднять железку, то сейчас таких проблем нет. Работает всё, к чему вы привыкли — Linux, Docker, Kubernetes, Xen, Java, Hadoop, Spark, Kafka, все что угодно.

Расскажите, как она работает, чем отличается от «обычной»?
Что насчет Java?

Она достаточно производительная для того, чтобы справляться с теми задачами, которые возложены на Java для серверов. Ничем не отличается, в этом и есть ее основное преимущество. Недавно вышла статья, где мы сравниваем производительность Arm-сервера с Intel-сервером. Вы переносите свое приложение (надеюсь, что у него нет нативной части, иначе придется его рекомпилировать), на Arm-сервер, проверяете производительность и в большинстве случаев — радуетесь. Статья вышла в Java Magazine.

Серьезно.
Oracle позволили вам, по сути, прорекламироваться в собственном журнале?

Получается, что Java Arm-сервера для Java-ворклоадов вполне хорошо себя показывают. Видимо, есть спрос. Они такие же, или даже лучше по сравнению со своими аналогами у Intel.

Кому стоит прочитать вашу статью?

Попробовать и Java, и те самые Arm-сервера. Тому, кто хочет посмотреть, протестировать новую архитектуру, подходит ли она для его нагрузок. В Google вбиваете Arm Server Cloud, и вам выпадает несколько облачных провайдеров, можно провести карточкой и попробовать то, что вам нужно.

Там уже предустановлена Java?

Обычная OpenJDK.
Да.

Я видел, что там есть ваши коммиты — это оно или что-то другое?
А обычная OpenJDK и ваш дистрибутив Liberica — это одно и то же?

Изначально в Oracle развивали Arm-порт и, когда Arm выпустил архитектуру ARMv8, к этому Arm-порту был добавлен дополнительный порт, который позволял запускать Java на ARMv8. Вообще, история Arm-портов и OpenJDK достаточно интересная и витиеватая. Так получилось, что коммьюнити сосредоточилось именно на порте Red Hat. Параллельно с этим Red Hat тоже работал в этом направлении и в OpenJDK влил свой порт для этой архитектуры. Для этого есть JEP 340. Поэтому сейчас тот довесочек, который был в OpenJDK для порта ARM32, который фактически дублировал функциональность порта aarch64 — мы его волевым решением оттуда уберем в JDK 12.

Сейчас влиты все фичи для Arm, которые делались в Oracle.
Надо сказать, что Oracle влил в OpenJDK все свои наработки от embedded, все Arm-порты перед тем, как прекратить поддержку.

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

Я видел инфографику, на которой нарисованы поразительные цифра о том, что некая компания BellSoft, расположенная в Санкт-Петербурге, залила огромное количество коммитов.

Естественно Oracle вне конкуренции находится, там около 4 тысяч коммитов за год.
Да, мы входим в топ-5 коммитеров OpenJDK.

Мы немножко не дотянулись до Google. Дальше идет Red Hat, SAP, Google и BellSoft. А сразу за нами — IBM.

Какой процент ваших сотрудников раньше работал в Oracle?

BellSoft состоит из бывших сотрудников Oracle.
100 процентов.

Что за комммиты, расскажите? Это нечестная конкуренция, потому что Google не состоит из 100 процентов сотрудников Oracle. Как попасть в топ-5 коммитеров?
Как достичь такого успеха?

Сейчас основное направление, куда идут наши коммиты, — это порт ARM64, который тот самый серверный порт. Мы работаем в нескольких направлениях. Им интересно, чтобы Java быстро работала на их железе, справлялась с нагрузками. Он интересен производителям железа. Третье — это коммиты, направленные на поддержку, исправление и улучшение общего функционала Java. Второе, куда коммитим, — это порт ARM32, который нами поддерживается, это embedded-порт.

Почему 32-битный порт еще живой?
Мы говорили только что о 64 битах на серверах.

Потому что он используется в embedded.

У них на складах лежит большое количество чипов. Потому что очень много компаний реализовало CPU для архитекутры ARMv7 для встроенных применений. Этой архитектуре уже очень много лет, но тем не менее, CPU достаточно дешевые, и производители до сих пор рассматривают создание новых устройств именно на этой архитектуре Если мне не изменяет память, то из всего многообразия этих чипов ARM32, самый популярный — ARMv5.

Может обычный человек себе купить что-нибудь и поэкспериментировать?
О каких суммах мы говорим, когда говорим о встройке?

Один из наших дистрибутивов — тот, который для ARM32, тестируется и работает именно на Raspberry Pi. Самое популярное из платформы ARM32 — это Raspberry Pi, начиная со второй версии — вторая и третья версии, плюс все это поддерживается ARM32-портом. У нас есть более специфические порты для узкоспециализированного железа, но это другая история. Мы видим, что это самая распространенная платформа для широкой аудитории, и поэтому выпускаем порт именно для Raspberry Pi.

Можно посмотреть, что у вас стоит в домашнем роутере. Может, и покупать не надо. Очень вероятно, что там что-нибудь такое.

Насколько там должны скиллы разработчика соответствовать?

Нужно быть Java-разработчиком.

Нужны ли хитрые способы, закон Кирхгофа знать, чтобы закодить?

Никакого умения его прошивать не нужно. У вас просто компьютер, к которому вы можете подключиться по SSH. В этом основной плюс Raspberry Pi по сравнению со всеми другими single board computers. Вы берете MicroSD-карточку с образом линукса для Raspberry Pi, вставляете ее, и все запускается. Простота его настройки, получение работоспособной системы.

Мы же все это ради внешних систем делаем, так?
А как с датчиками работать?

На чем обычно все энтузиасты всякую периферию к Raspberry Pi и подключают.
У Raspberry Pi есть система GPIO и пины, к которым вы можете подключать все что угодно.

Что нужно написать, типа, «получи мне с термостата чиселку»?
Как API выглядит?

Если I2C, вызвать метод для конфигурации, туда передать все параметры. Нужно прочесть даташит термостата, и понять, какие есть регистры, как его инициализировать, как его конфигурировать. Потом сказать ему i2c.open, и работать с ним как с Java-объектом.

Можно сделать так, чтобы не читать больше даташит, закрыть его фасадом?
А можно вокруг термостатов написать красивые объектные оберточки, чтобы потом работать в чисто объектной модели?

Библиотека работает с одним датчиком, библиотека для работы с другим датчиком. Хорошо бы, чтобы производитель этого датчика сделал готовый конфиг, и мы как Java-программисты просто брали его и пользовались. Она развивается сейчас не так бурно, как во времена, когда Oracle двигал Java embedded, но она все равно не умерла, периодически выходят какие-то обновления. Такая библиотека или что-то близкое к этому есть, называется Pi4J. Здесь есть выбор: либо работать с вещью, которая в OpenJDK — GPIO, либо работать с библиотечкой Pi4J.

К вам обратиться? Если я производитель железяки, ничего не знаю о Java, но хотел бы, чтобы Java-программисты могли пользоваться ей, к кому обратиться? Или есть специалисты, которые этим занимаются?

Да, мы и есть такие специалисты.

Помню, что у вас были какие-то свои JEP, да?
Пока мы далеко не убежали.

14 было сделано Oracle, 1— Google, 1 — Red Hat, 1 — BellSoft совместно с Cavium. В 11 версию OpenJDK вошло 17 JEP. JEP, соответственно, называется Improve Aarch64 Intrinsics. Наш JEP — сборная солянка улучшений производительности Java на платформе ARM64 под конкретные ворклоады. Если кратко, то мы улучшили производительность операций со String, с массивами и немного с математикой и тригонометрией.

Не все знают.
Что такое интринсики?

Когда виртуальная машина считает синус, вместо того, чтобы выполнять непосредственный Java-код, может подставить оптимизированную ассемблерную вставку под конкретную архитектуру.

Которая напрямую зовёт процессор, который имеет команду «синус»?

Есть интринсики, которые вызывают какую-то команду ассемблера. Которая вычислит его по сложному алгоритму. Такие ассемблерные инструкции есть практически для всех архитектур. Например, интринсики, связанные с вычислением чексумм. Есть более сложные интринсики, когда для получения хорошего прироста производительности писать много страниц ассемблера.

А шифрование, оно есть в железе?

Иногда — работа с расширениями на тех чипах, где они есть.
Да, обычно это вызов существующих инструкций конкретного процессора.

Возвращаясь к вашему JEP: как определить, какой код является настолько горячим, что его стоит так хардкодить?

Когда мы начали оптимизировать что-то под платформы ARM64, большого количества тулов у нас не было, помимо perf. Отличный вопрос. Реализация JFR для ARM64-порта отсутствовала, Oracle к тому моменту еще не выложила в Open Source. Да и тот работал не везде. Первое, что мы сделали — завели все эти тулы на этой архитектуре. Различные тулы для измерения перформанса, которыми мы привыкли пользоваться, например, async-profiler, honest-profiler — они для платформ ARM64 тоже не работали.

Почему не работают из коробки?

Потому что там есть какая-то CPU-специфичная часть.

Есть простые случаи, когда какие-то ассемблерные вставки под конкретную архитектуру не реализованы. Дальше запускаешь эти тулы на том ворклоаде, который ты пытаешься оптимизировать, долго смотришь в экран, пытаешься понять, какие методы там горячие, какие места в них горячие. Просто реализовав эти ассемблерные вставки можно получить увеличение производительности. В этом случае происходит fallback в Java код. Такая работа. Есть более сложные места, когда нужно понять какую новую ассемблерную вставку нужно в Java создать для всех архитектур.

Выкачать весь гитхаб и запустить под JIT?
Сам датасет откуда взять?

Бенчмарки известные — SpecJBB, SpecJVM. Понятно, что происходит оптимизация каких-то бенчмарков или ворклоадов. Просто запускаете эти ворклоады и смотрите на узкие места. Есть конкретные ворклоады, которые интересуют конкретных заказчиков.

Что насчет новых лямбд, стримов, биг даты?
Все эти SpecJVM — очень старые тесты, да?

Там этого нет.
Ничего.

И где это достать?

Новые ворклоады.

Например, апачевский стек?

У Hadoop есть стандартный бенчмарк TeraSort, которым производители железок любят мериться. Да. Тоже одна из интересных задач для оптимизации.

Например, топ из того самого JEP.
Какой сейчас топ функций, которые стоит оптимизировать?

Там, разумеется, есть еще непаханое поле того, что мы не сделали и что будем продолжать делать. Основные проблемные места для этой архитектуры, которые там были, мы закрыли. Их еще нет, но мы понимаем, что они в скором времени появятся. Будем продолжать работать с тригонометрией, будем смотреть на новые интринсики, которые будут появляться. Придется смотреть в проект Panama, в который сейчас очень активно контрибьюит Intel.

Условно, магическим образом поймет, что ты считаешь какую-то известную формулу и заоптимизирует?
Как компилятор увидит, что ты делаешь?

Если вы вызываете Math.sin, то вместо Java-реализации этого sin вполне возможно подставить ассемблерную вставку.

Там где-то стоит регулярка, которая ищет все sin и заменяет на это?

Это обычно делается даже не в компиляторе, а начиная с интерпретатора.
Да.

Что-то более сложное может ловить, например, операции в счетных циклах?

Обычно такие задачи решаются в рамках C2, и писать и поддерживать специализированные интрински не имеет смысла.

Например, Иванова или Чуйко?
Для этого нужно иметь какого-то специалиста.

Чуйко работает у нас.

Linaro Foundation занимается разработкой экосистемы для Arm-платформ. Он сейчас уехал в Канаду, будет рассказывать на конференции Linaro Connect о наших достижениях в улучшении OpenJDK на архитектуре ARM64.

Откуда у них деньги на это?

И от производителей железа.
От Arm, в первую очередь.

Какие самые сложные или интересные челленджи у вас были?

Пришлось прокачать свои познания в математике немножко. Сложно так сказать. Приходите на Joker, расскажем.

Программистам нужна математика!

Не просто так разобраться с арифметикой floating point. Да, внезапно. Эти ассемблерные вставки — очень сложный и трудоемкий процесс, их потом их сложно поддерживать. Пришлось прокачать способность понимать, какие тут инструкции, какие у них веса, сколько они времени занимают. Но оказывается, что с точки зрения получения мгновенной выгоды это достаточно выгодно. Представьт, что у вас меняется спецификация, у вас появляется новые более оптимальные инструкции — вам приходится их переписывать.

Правильно понимаю, что есть набор оптимизаций, которые запускаются в порядке увеличения веса?
Ты про веса сказал.

Поскольку Arm предоставляет спецификацию… Они делают свои Кортексы, но основной бизнес — это предоставление лицензий на спецификацию. Да. У кого-то инструкция будет сколько-то времени занимать, а другого производителя — другое время. Дальше различные производители делаю, кто во что горазд. Вам нужно очень аккуратно понимать, что для одного типа процессоров будет оптимальна одна последовательность, для другого типа будет оптимальна другая. Вся эта сложность, с который приходится сталкиваться, когда ты пишешь этот ассемблерный код. Разумеется, обычному Java-программисту беспокоиться нечего, за него уже про это побеспокоились.

Что ему нужно сделать?
Допустим, у какого-то корпоративного инженера оптимизации работают немного не так, как хочется.

Контрибьютить в OpenJDK или идти в компанию BellSoft.

Что нужно знать? Расскажите, что нужно сделать, чтобы попасть в вашу компанию в качестве разработчика? Какой набор знаний нужен JVM-инженеру?
Если ты не работник Oracle, тут все понятно.

(смеется)
Наверное, нужно быть контрибьютором в OpenJDK.

Подойдет?
Хорошо, я изменил 250 комментариев и стал контрибьютором.

Так не выйдет.
Ты не станешь значимым контрибьютором, изменив 250 комментариев.

Это же сама виртуальная машина.
А если человек часто меняет библиотеки — это тоже не сильно про то?

Чтобы хорошо разбирался в алгоритмах. Главное, чтобы человек был хороший. Даже необязательно знать какие-то недра. Понимал, как работает процессор — поскольку мы в основном работаем с достаточно низкоуровневыми вещами.

Сколько времени проходит до того, как человек в первый раз может сделать осмысленный комит?

Обычно это несколько месяцев.

И что он делает эти месяцы?

Потом учится понимать. Сначала учится собирать проект. Потом он пытается сделать это изменение, и у него все валится, он бежит к своему соседу, тормошит его. Допустим, ему дали какую-то простую багу, и он учится понимать, в какой области всего этого многообразия ему нужно делать изменения. Затем учится понимать, какие именно тесты нужно запускать. Потом у него что-то начинает работать и он учится запускать тесты. Потом учится общаться, потому что в рамках OpenJDK общение является достаточно важной составляющей. Затем учится понимать, на скольких архитектурах нужно запускать тесты, чтобы этот патч нормально протестировать.

А как вы общаетесь?

Если чего-то нет в mailing list, то его нет.
Mailing list.

А баг-трекер?

В OpenJDK открытая Jira, в которую все люди, которые стали авторами, получают доступ.
Jira.

У вас нет своей Jira для Jira, которая будет джирить, пока джиришь?

Естественно есть другие проекты, в которых у нас есть своя Jira.
Для OpenJDK такого нет.

Я иду по списку, который ты назвал, и все понятно насчет общения, но непонятно, зачем запускать на нескольких архитектурах, если у вас только Arm?
Сколько у вас архитектур?

Но если вы делаете изменение в shared-части, которое даже выглядит абсолютно безобидно, это может аукнуться много где. Если только Arm, то, может, и не надо запускать на других архитектурах. А потом нужно тестировать. Вначале нужно понять, где оно может аукнуться.

Потому что у меня есть подозрение, что она очень большая.
Как выглядит матрица тестов, совместимости.

Мы считали количество комбинаций флажков HotSpot, архитектур, тестов, и получили число десять в пятидесятой. Есть тесты, а есть конфигурации. Понять, где нужно запустить тесты, чтобы что-то протестировать — не такая тривиальная задача.

У вас есть какой-то стандартный набор конфигураций?

В том же HotSpot тесты организованы по tiers. Да. Тестируя различные тиры и получая всю картинку, вы понимаете, как оно выглядит. Начиная с обычных smoke-тестов и заканчивая достаточно серьезными тестами. Разумеется, performance-тестирование, stress-тестирование.

Представь, что вчера случилось ещё одно чудо, и в Питере выпустили не только свою JDK, но и свой процессор. Более общий вопрос. Из каких крупных блоков состоит портирование на новый процессор, кроме тестирования?
Надо на него быстренько спортировать JDK, и вы этим занялись.

JVM можно условно разбить на 4 части: runtime, serviceability, garbage collector, compiler. Основным компонентом JDK, который нужно будет портировать, является JVM. Если у вас будет собственная новая операционная система под этот процессор, то скорее всего нужно будет изменять и runtime. Практически во всех четырех компонентах нужно будет произвести какие-то изменения. Если у вас просто новая архитектура, то в основном это будут JIT, в которые вам нужно будет вкладываться. Если у этого процессора какие-то не очень понятные взаимоотношения с памятью и с out of order execution, то скорее всего, вам придется и в GC залезть. Основной вклад community и производителей железа в OpenJDK — это именно в JIT.

Если посмотреть не на создание, а на поддержку, где больше всего изменений?

Этого не видно извне, но очень много изменений происходит в библиотеках. Все меняется, все течет. Но в компиляторе наибольшее количество изменений. Большая работа проходит по оптимизации библиотек. И новые компиляторы появляются, и старые начинают работать по-другому, и новые архитектуры появляются, для которых нужно писать новые оптимизации.

Десять процентов? Какая часть вашей работы по созданию этой штуки связана именно с поддержкой? Если постоянно все меняется, значит, надо за этим следить и что-то изменять?
Девяносто?

Разумеется, это очень заметный процент.
Сложно посчитать процент работы.

Твой ход.
Александр, я вижу, что ты уже долгое время хочешь что-то интересное рассказать, а мы тут про компиляторы.

Спрашивали, кому стоит прочесть статью Алексея про OpenJDK на Arm. Расскажу про статью. Во-первых, Алексей в статье рассказывает о том ландшафте, который в экосистеме Arm сейчас есть. Я считаю, что ее нужно прочесть всем людям, которые имеют отношение к IT. Дальше Алексей рассказывает о том, что происходит в OpenJDK, в приложении к экосистеме Arm. О том, как эволюционировала спецификация Arm, как Arm дошел до такой жизни, что оказался на серверах. Сравниваются производители Arm процессоров с аналогичными процессорами Intel на SPEC-ах. И показывает, как работают бенчмарки, какие результаты имеются. Мир меняется у нас на глазах прямо сейчас. Поэтому мне кажется, что эта информация должна быть полезна всем. И никто об этом не знает практически!

У меня уши не покраснели, пока Александр рассказывал?

Нет, а почему должны были?

Мне должно быть стать стыдно за то, что я сделал.

Алексей ведет просветительскую работу сообщества. Всё мы делаем правильно. Единицы людей. Кто сегодня знает о том, что выпускается серверы на архитектуре ARM64? А на самом деле у нас есть информация о том, что в штатах на процессорах Arm строятся вычислительные центры и суперкомпьютеры.

Очень большие компании смотрят именно на эту альтернативу.

Вы про это говорите? Но сейчас суперкомпьютеры — это, грубо говоря, некий дата-центр, в котором куча юнитов соединена между собой. Или это какие-то большие блоки, в которых миллиарды ядер Arm?

Из публичных источников можно увидеть, что обычно это суперкластеры.

Какое будущее у этого дела?

Все еще находится в зачаточном состоянии и на широкий рынок пока это не выходит. Сейчас восход Arm на рынке серверов. Это облачные провайдеры. Кто сейчас главный потребитель всей этой истории процессоров, памяти, железа? Они очень серьезно смотрят на эту архитектуру.

То, что они серьезно смотрят, уже является индикатором, что это уже в достаточно серьезном состоянии. Саш, я позволю себе тут с тобой не согласиться. А сейчас все Cloud-провайдеры предоставляют такую возможность. Если бы вам кто-нибудь 10 лет назад сказал, что вы будете на GPU что-нибудь считать, вы бы удивились. Есть нагрузка которую оптимально считать на GPU, есть нагрузка для CPU. Если посмотреть на это чуть более глобально, есть определенные нагрузки, под них производители делаю что-то. Это разные нагрузки, под них нужно разное железо. Есть нагрузка просто ответить в Интернет что-нибудь, HTTP 404. Все эти облачные провайдеры становятся либо более специализированными, либо начинают предлагать продукты под конкретные нагрузки.

Есть ли какие-то индикаторы основные?
Как понять, что какая-то из технологий достаточно зрелая, чтобы на нее был смысл смотреть?

С того, что нужно данному конкретному потребителю. Все начинается с нагрузки. Под все эти разнообразные нагрзуки будет оптимально использовать разное железо. Ему нужно получить ответ за 30 миллисекунд на любой запрос или ему нужно считать тяжелую математическую задачу наиболее быстро или ему нужно посчитать эту математическую задачу наиболее дешево? Просто какое-то решение становится в определенный момент более конкурентоспособным, чем нечто, что было раньше. Нельзя сказать, что под конкретную задачу всё уже готово или нет. Мне кажется, что для серверов на Arm такой момент настал. И вы начинаете по нескольким параметрам перебирать: по этому параметру стало на 20% лучше, по этому тоже на 20%, а по этому — на 10%, дай-ка попробую эту технологию.

Жаль, что рядом с нами нет производителей железа сейчас, чтобы был полный комплект.
То есть у нас есть довольно хорошая технология, у нас есть Java, и у нас есть люди, которые все это поддерживают так или иначе.

Мы контрибьютим во все порты OpenJDK, если у нас возникают какие-то проблемы с портом. Мы все время говорим про Arm и может сложиться впечатление, что BellSoft — это исключительно Arm, но это не так. И еще у нас есть Liberica для Solaris Sparc. И Liberica сегодня уже не только Liberica на Arm 32 и 64, Liberica сегодня доступна на Linux (64 бита), на Windows и в ближайшее время мы выпустим Liberica для Mac. Это для очень специфичных заказчиков.

На нем же нет дата-центров.
Зачем Liberica на Mac?

Сейчас Oracle перестанет выпускать патчи, буквально уже немного времени осталось… До января. Ну ведь на маке джава нужна? И что произойдет?

Что с патчами происходит?

Если совсем коротко, то Java-мир больше никогда не будет прежним.
В другой раз можем рассказать подробно про то, что происходит с патчами в Oracle.

Но зато в Java-мире теперь появятся сборки других производителей.

Чем больше производителей будут работать в одном проекте, тем лучше.
Да, и это хорошо.

Появится конкуренция.

Во-первых, конкуренция будет за support заказчиков. Да. Им важно, чтобы в случае, если возникает какая-то проблема, она была решена в короткие сроки. Кому-то нужна поддержка — банкам, платежным системам, Cloud-провайдерам.

Никто на моей памяти не писал -XX:+UnlockCommercialFeatures. Раньше я работал в банке, многие инженеры поддержки всегда ставили Oracle JDK не из соображений, что там есть дополнительные API. Но люди считают, что только в Oracle точно знают, как правильно это готовить.
Я сейчас не про конкретный банк, а вообще про поддержку на проде.

Ими все пользовались. Так ты абсолютно прав, потому что мы всегда рассчитывали на Oracle и на апдейт-релизы Oracle, которые выходили регулярно. Даже на десктопах Java апдейтилась сама, ничего делать не надо было.

Больше и больше саппорта предоставляется этими котрибьюторами. По статистике, которую мы видим, все больше внешних контрибьюторов приходит в OpenJDK и все больше и больше новых фич разрабатывается внешними контрибьюторами. BellSoft в этом отношении находимся в очень интересном положении, потому что мы тоже знаем, как готовить.

Давайте потом отдельно по каждому направлению поговорим. Мы обсудили много различных направлений и вы, похоже, во всех них разбираетесь. Например, про то, как внутри устроена OpenJDK — это отличная большая тема.

С удовольствием!

Мы приближаемся к концу этого увлекательного разговора, и поэтому — последний вопрос. Хорошо. Можете что-нибудь посоветовать нашим читателям на Хабре?

Ваш кругозор расширится пониманием того, что есть еще одна архитектура, альтернативная той, к которой мы привыкли. Советую прочесть статью Алексея. И у нее есть своя экосистема программного обеспечения.

Возьмите какой-нибудь простой баг и попробуйте его исправить в OpenJDK.

Что еще?
Звучит как огромный квест.

Не обязательно на Raspberi Pi, можно на Linux-сервере. Скачайте Liberica, запустите. Расскажите друзьям о том, что есть русская Java, которая делается в Санкт-Петербурге.

А еще можно прийти к нам на Joker, на котором у тебя будет доклад, а у BellSoft — стенд в демозоне.

Будем я, Алексей, Дмитрий Чуйко. Приходите с нами пообщаться. Дмитрий не уедет, мы его зарезервировали 🙂 Joker — очень важное для нас событие.

Ждем вас в следующий раз!
Спасибо вам, было очень круто.

Александр и Алексей приедут на конференцию Joker 2018 с докладом «Дорогая, попробуем ARM? Минутка рекламы. Приобрести билеты можно на официальном сайте конференции. Теория, приложения и рабочие нагрузки».

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть