«Жить на Гавайях, работать над суперпопулярным сервисом, внедрить там в продакшне экспериментальную Java-технологию, на которую другие ещё только с опаской поглядывают» — звучит как описание выдуманной Java-карьеры, о которой можно только мечтать. Но есть человек, для которого это всё суровые будни, и мы с ним пообщались.

Благодаря Крису Талингеру в Twitter уже вовсю используют новый компилятор Graal, и не просто во имя любви к инновациям: это помогает компании экономить ощутимые суммы. Крис уже делился опытом Twitter в Петербурге на конференции Joker, а теперь приготовил новый доклад, призванный показать обычным Java-разработчикам, как им подступиться к Graal. А в ожидании этого доклада мы расспросили его и об основах Graal, и о том, как теперь в Twitter заходят ещё дальше, и о том, как Крис организовал на Гавайях Java-конференцию LavaOne.


Руслан ARG89 Ахметзянов: Начнём с самого начала: что вообще такое Graal?

— Это произносится как /g r a l/, потому что это не английское слово /g r ? l/, это немецкое /g r a l/. Graal — это just-in-time компилятор для JVM. Существуют разные JVM, но думаю, что большинство людей знают и используют HotSpot, входящий в OpenJDK. Ещё есть, например, J9 от IBM. Но я на протяжении долгого времени работаю именно с HotSpot.

HotSpot давно работает с компиляторами C1 и C2. А Graal — это ещё один JIT-компилятор, который при желании можно использовать, что и делаем, например, мы в Twitter. Этому был посвящён мой предыдущий доклад.

Руслан: И вот ещё об основах. Если начать гуглить Graal, он вечно упоминается в связке с Truffle, а Truffle в вашем докладе не упоминался...

— Здесь недавно произошло переименование. Пару лет назад название Graal относилось просто к JIT-компилятору. Он назывался Graal, а также была другая технология Truffle, основанная на Graal. А недавно Oracle Labs устроили ребрендинг и объединили JIT-компилятор Graal, Truffle, Substrate VM и ещё некоторые вещи под единым названием Graal VM. И это отчасти запутывает людей. Когда я говорю «Graal», я всегда имею в виду JIT-компилятор, а не Truffle, Substrate VM или ещё что-то подобное. Компилятор называется Graal. Truffle — фреймворк для разработки рантаймов для языков программирования.

Руслан: Окей, определились, мы говорим только о JIT. Первый вопрос: зачем вообще кому-то нужен написанный на Java JIT-компилятор, если у нас уже есть отлично работающий компилятор на «сях»?

— Тут есть две причины. Как я уже сказал, у HotSpot уже были два компилятора C1 и C2, написанные на C++. И C2 — top-tier компилятор. Это означает, что он генерирует код для пиковой производительности. Задача Graal в том, чтобы заменить C2 и HotSpot. И главная причина в том, что C2 — очень старая технология.

Да, как вы сказали, она справляется со своими задачами. Но она очень старая и сложная, поэтому в ней очень сложно разбираться, новым людям сложно разобраться в коде и работать над ним. Очень сложно вносить изменения. Компилятор работает, но мы толком не можем вносить в него новые оптимизации. А появляются новые языковые фичи: проекты, над которыми я работал в Oracle, Valhalla, Panama и тому подобное… Имплементировать всё это в C2 сложно, а в Graal гораздо проще. Это первая причина.

А вторая причина в том, что при определённых условиях, скажем так, Graal производит куда лучший нативный код, чем способен C2 — особенно для компаний вроде нас, Twitter. Об этом я рассказывал в докладе на Joker 2017. В продакшне мы экономим 8% утилизации CPU просто с помощью замены C2 на Graal. А в масштабах Twitter это много денег.

Олег olegchir Чирухин: Звучит разумно. А что с обратной совместимостью? Все эти инновации случайно не сломают нам старый код?

— Нет, потому что компилятор просто читает Java-байткод, входным языком для компилятора служит Java-байткод, мы просто парсим его. Graal никак не вмешивается в байткод, он просто читает его, как и C2. А вот то, что у него получается затем на основе байткода — нативный код — уже не слишком обратно-совместимо, да.

Олег: А когда люди основывают свой код на всяких странных и ненадёжных штуках вроде Unsafe, такое в Graal не сломается?

— Я бы сказал, что проблемы очень маловероятны. Не буду ничего гарантировать, люди наверняка творят очень странную хрень, но вероятность очень низкая. До сих пор я не сталкивался с кодом, который не запустился бы на Graal. А я всякое пробовал. У нас сегодня на Graal все основные сервисы работают.

Руслан: А запомнился ли вам какой-нибудь особенно безумный код из всего, что скармливали Graal, про который беспокоились «тут всё гладко не пройдёт»?

— Даже не знаю. Я уже долго этим занимаюсь и всегда старался попробовать самый разный код. Когда я ещё работал в Oracle, я просто скачивал случайный софт и пытался запустить его на Graal и посмотреть, что получится. Нашёл тогда несколько багов, и мы починили их все. О, вот к какому софту я порой возвращаюсь проверить, работает ли он ещё: игра Runescape, теперь она уже считается старой.

Олег: А, знаю её.

— Она была суперпопулярна лет 10 назад. Существует до сих пор. Кажется, там уже всё поменялось и теперь можно скачать нативный клиент, но в те времена она была написана на Java и запускалась в браузере с помощью Java-плагина, если правильно помню. А можно было запустить отдельный Java-клиент. Она до сих пор установлена у меня на ноутбуке, по-прежнему работает и я могу её запустить.

Причина, по которой я использую её, в том, что она скачивает кучу всего. У тебя на десктопе маленький Java-клиент, который скачивает пачку JAR-файлов и запускает их. А ещё весь код там обфусцирован. Обфускация обычно вносит в код такие изменения, которых ни компилятор, ни VM не ожидают. Это по-прежнему валидный код, в нём нет ошибок. Но байткод отличается от того, что выдал бы Javac. И для компилятора это, скажем так, интересно! Я по-прежнему иногда обращаюсь к этой игре, но думаю, из-за неё никогда ничего не падало.

Олег: Кстати, не можем ли мы использовать Graal для обфускации? Заменять фрагменты? Мы же можем использовать его для ahead-of-time компиляции, можем в этом случае и обфусцировать, получая нативный код?

— Вы говорите про AOT-компиляцию, появившуюся в Java 9?

Олег: Да!

— Как работает AOT в Java 9? Создаёт нативную библиотеку, но не создаёт статичный исполняемый файл. Вы берёте .class-файл, JAR-файл или модуль и компилируете в нативный код. Но чтобы запустить его, вам всё равно равно нужна JVM, и ей всё равно нужно прочитать class-файл, просто затем она видит: «О, для этого у меня уже есть нативный код, не требуется дёргать компилятор!» Понимаете? Это не exe-шник, это просто прекомпилированный код.

Могу ошибаться, но Substrate VM (часть всей этой Graal VM-истории, о которой я говорил) действует несколько иначе. Substrate VM создаёт исполняемый файл, уже содержащий в себе VM. Тут я не уверен полностью, но там внутри всё равно требуется требуются данные class-файлов. А в этом случае вся обфускация теряется.



Руслан: Давайте поговорим об использовании Graal в Twitter. С тем, что можно сократить загруженность процессора, понятно. Но не рискованно ли использовать такую экспериментальную технологию в сервисе такого масштаба?

— Риск есть всегда, что ни делай. У вас есть приложение, есть Java-код. Когда меняете этот код — хоть добавляете строчку, хоть рефакторите — это всегда рискованно. Да, Java хорошо протестирована, и можно быть на 99,999% уверенным в успехе, но всё может и упасть из-за какого-нибудь бага.

Вы правы, конечно, это рискованно, потому что Graal не так хорошо протестирован, как C2, который существует уже 20 лет и на котором работает весь мир. Причины, по которым мы это делаем: во-первых, деньги (это всегда хорошо), а во-вторых, мы очень, очень хорошо тестируем до отправки в продакшн. Мы не просто берём сервис в продакшне, переключаем его и скрещиваем пальцы, надеясь на успех.

Мы тестировали разные сценарии в самых первых пробных версиях. Поначалу проверяли в экспериментальных окружениях просто посмотреть, сработает или нет, а затем очень медленно выкатывали. Запускали всего лишь один инстанс в продакшне и смотрели, всё ли в порядке. А затем запускали уже сотни. Мы медленно всё меняли, и прошёл почти год, прежде чем мы переключились целиком. Да, рискованно, но если предпринимать должные меры предосторожности, то можно.

Руслан: Год с начала тестирования технологии или год с запуска первого инстанса?

— Год с того, как я начал работать в Twitter. А с первого инстанса до 100% на Graal прошло 6-8 месяцев.

Руслан: Вы говорили, что с начала использования Graal в Twitter столкнулись в связи с этим только с 4-5 багами.

— Примерно так, да.

Руслан: Это связано с упомянутой тщательностью тестирования? Или у вас есть какие-то особые лайфхаки «как при громадном архитектурном переходе на экспериментальную технологию не огрести багов»?

— Особых лайфхаков нет, просто подключали Graal и всё, использовали поначалу экспериментальное окружение. Ничего особого я не делал, не модифицировал Graal для использования у нас. Это были обычные баги, с ними разобрались, в апстриме они все пофикшены. Я это уже упоминал в докладе, а с тех пор ещё больше времени прошло: в последний раз баг обнаруживали уже больше года назад.

Руслан: Если погуглить “Twitter Graal crashes”, найдутся связанные с этим вопросы на Stack Overflow?

— Мы всё фиксили на GitHub. Исходный код Graal лежит на GitHub и я заводил там баги, так что можете открыть проект. К сожалению, Oracle Labs меняли репозитории, сейчас они уже, кажется, на третьем. В общем, я заводил баги в каких-то старых версиях, в старом репозитории. Думаю, если открыть слайды моего доклада, можно найти нам ссылки на баг-репорты.

Олег: А где увидеть баги и фич-реквесты? Я открыл страницу на GitHub, там их мало.

— Ну, технически, это всё должно происходить на GitHub. Что-то происходит в мейлинг-листе. А что, хотите понять, как оформить фич-реквест?

Олег: Нет, хочу понять, как мониторить активность в этом проекте.

— По сути, всё на GitHub. Если зайти туда и открыть Graal — сейчас вроде бы проект там под названием Graal — и подписаться на него, будете получать уведомления обо всём происходящем. И ещё вам стоит также подписаться на мейлинг-лист OpenJDK Graal, там тоже происходят дискуссии.

Руслан: К слову о GitHub и проверке ваших баг-репортов. А что вы сейчас делаете в связи с Graal? Раз вы его уже больше года как запустили, похоже, система у вас уже нормально работает. Теперь занимаетесь какими-то фиксами или новыми фичами?

— Я затеял одну штуку, которую надо бы завершить, особенно теперь, когда Java 10 скоро выйдет. Хотя для 10, думаю, уже поздно. В общем, я начал добавлять поддержку, хотя это не совсем правильное слово… переносить оптимизации Compact Strings из C2 в Graal.

Я начал эту работу, Олег вот кивает, потому что знает, что его имя сейчас всплывёт. Там ещё не всё сделано, некоторые части остались, но главные сделаны. Теперь нужно тестировать и тому подобное. И у меня не было времени вернуться к этому и доделать. И потом Олег сказал «Может, я это сделаю?» А сам не сделал!

Олег: Мне очень стыдно, правда. А что с процессорами и архитектурами, отличными от Intel?

— Есть SPARC-порт Graal, это я начал давно, а затем кто-то другой закончил. Он работает. А ещё был парень, забыл его имя, который делал ARM 64-порт в качестве дипломной работы в университете, и этот порт лежал без дела заброшенным. Но затем я уговорил его пожертвовать этот код в проект Graal OpenJDK, и когда это произошло и Oracle решили опенсорснуть ARM, Red Hat подхватили эту разработку. Так что сейчас, по сути, поддерживаются все три главных платформы. Возможно, мне уже не стоило бы называть SPARC «главной», но две главных поддерживаются. Кстати, у Graal нет 32-битной поддержки. Все платформы, которые он поддерживает, 64-битные.

Руслан: Правильно, кому эти 32 сегодня нужны?

— Вот и я что говорю! Не знаю, есть какие-то безумные люди, которые хотят запускать его на ARM, что даже можно понять, потому что его используют в embedded-системах, так что некоторый смысл есть. В общем, это одна из вещей, которыми я занимаюсь.

Другая, которой занимаемся мы в Twitter… В наше время мода на слово «облако» уже прошла, новый баззворд — «машинное обучение». Все говорят про ML. Об этом были доклады, это не то что бы новинка, мы этим уже 2-3 года занимаемся. У нас есть ML-фреймворк, назовём это так, который был разработан для настройки значений параметров JVM, в первую очередь GC. Так что вы запускаете сервис, или приложение, или что у вас там, и говорите фреймворку: «Так, я хочу настроить мои GC-параметры для наилучшей производительности».

Этот фреймворк называется Autotune, и мы используем его для настройки параметров инлайнинга в Graal для сервисов, использующих Graal. Это следующий шаг. Мы сейчас делаем это, тестируем это, и уже нашли хороший набор значений параметров, которые улучшают производительность. Но мы ещё не пробовали в продакшне, у меня есть только экспериментальные числа, так что не слишком им доверяйте. Думаю, у нас получилось выжать ещё 8% в экспериментальном окружении. На продакшне обычно получается меньше — возможно, в итоге получим 5%, это будет здорово, снова сэкономленные деньги.

Олег: Autotune не в опенсорсе?

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

Олег: Эти параметры инлайнинга Graal настраиваются статично, или можно прямо во время исполнения на лету менять?

— Хороший вопрос. Думаю, в данный момент поддержки для изменения их на лету нет. Но технически, предполагаю, это возможно. В Graal как раз и хорошо по сравнению с C2, что его параметры — это попросту «-Dgraal.чтототам», можно менять их на лету. Я никогда не пробовал, но думаю, что возможно.

Олег: Но тогда требуется деоптимизация и повторная оптимизация с этими параметрами, да?

— Сейчас с ходу не скажу, надо посмотреть на код, но то, как определены параметры… Думаю, что не как static finals или что-то вроде, а в таком случае компилятор, вероятно, просто читает их из памяти, и можно их менять. Не думаю, что они заинлайнены в нативный код.

Олег: Думаю, должно быть интересно для условий динамических облачных окружений. Все константы могут меняться на лету.

— Это интересно, да. А ещё это создаёт целый класс новых проблем. Когда делаешь такое, а потом хочешь перезагрузить, это всегда хитро.

Руслан: К вопросу об опенсорсности Грааля: а насколько компетентным требуется быть, чтобы в него контрибьютить? А то, похоже, Олегу вот уже не терпится что-то туда покодить!

— Надеюсь, покодит! Это хороший вопрос, он связан с главной причиной, по которой я топлю за эту технологию. Я уже сказал, что C2 очень сложный. Там требуется потратить 2-3 года только на то, чтобы изучить код и понять, что происходит. И тогда окажешься готов писать новый код. Я видел это много раз в Oracle, когда мы нанимали новых людей и они год-два фиксили баги, их раздражало, что они не понимают код так быстро, как им бы хотелось. Так что весь смысл замены C2 на Graal как раз в том, что его куда легче понимать — из-за того, как он написан, он хорошо структурирован, разбит на модулей. Я не имею в виду модули Java 9, но там разделение на части, это очень модульная структура. И в этом проекте приняты меры, чтобы участник не создал циклические зависимости и не добавил зависимости, которые не следовало бы. В общем, всё куда понятнее.

А помимо того, ещё и написано на Java, что куда понятнее, особенно когда дело доходит до очень низкоуровневого системного кода. С C++ можно сделать кучу странной хрени, которую никто не сможет понять. А в Java сложно сделать то, что люди не смогут понять. Если только не начинать безумствовать с Unsafe, но в Graal такого не делают.

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

Олег: Может, вам написать книгу для новичков, вводящую их в курс дела?

— По сути, пока что это всё ещё исследовательский проект. Он становится серьёзнее и мы уже используем его в продакшне, так что в строгом смысле исследовательским уже не назовёшь, но он развивался очень быстро, код менялся постоянно. Сейчас всё немного поутихнет, вот тогда может появиться смысл в сочинении книги. Но написать книгу — это большая работа.



Руслан: Думаю, ещё один вопрос про Graal и Java, а затем переключимся на LavaOne…

— А вы сами попробуете Graal?

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

Олег: Два года назад, вообще говоря.

— Да он старожил!

Олег: В общем, вопрос такой. В Java 9 мы получили модули, в следующей версии нас ждут value types. По-вашему, Graal выиграет в будущем от этих Java-нововведений? И какие фичи для вас полезнее всего?

— Ну, value types не «в следующей версии» из-за нового релизного цикла. Java 10 выйдет уже в марте, так что value types туда не попадут. А вот что попадёт, так это… Есть JEP, не помню номер [мы проверили: JEP 317], добавляющий Graal в качестве экспериментального JIT-компилятора. Так что мы двигаемся в правильном направлении. И в Java 9 на самом деле уже присутствует Graal, но там он не рекламируется как «экспериментальный JIT-компилятор», это произойдёт в «десятке». Это здорово, происходит прогресс, такое мне и хочется видеть.

А возвращаясь к value types, к сожалению, не вошедшими в «десятку»: они для Graal будут очень важны. Причина в том, что один из недостатков Graal по сравнению с C2 — графы объектов самого компилятора очень разрастаются, и при компиляции обход графа получается ого-го какой. В C++ объект может быть почти структурой, он плотно упакован, а Java-объект — другое дело. И если у вас граф, он должен быть Java-объектом, никуда не денешься. И Java-объект приводит к значительным накладным расходом, с ним много чего сразу приходит. Он использует больше памяти для представления графов. Если использовать для этого value types, это сэкономит часть памяти. Мы ждём этого. И как только value types попадут в JDK, уверен, что Graal немедленно их использует.

Олег: Насколько помню, там около 40 мегабайт на инстанс Java-процесса, так? Можно сократить до 10. В докладе вы так говорили.

— Нет, это другое. 40 мегабайт, упомянутые в моём докладе — это метаданные. Тут разные вещи. В случае с Graal используется больше Metaspace-памяти. Думаю, примерно 20-30 мегабайт. Ещё он использует память в старом поколении, это 40 мегабайт. Там хранится статичное состояние, поэтому это в old gen. Это хранится всё время, пока запущена JVM.

А я говорю вот о чём. При компиляции парсишь Java-байткод в compiler graph, а затем проводишь все свои оптимизации над графом, и в конце конвертируешь его в нативный код. По сути, так компилятор и работает. И я говорю об этом графе. Он нужен только временно. Такому место в молодом поколении, потому что компиляция метода происходит быстро, это пара миллисекунд. А граф при этом может быть очень большим (зависит от того, насколько большой метод и сколько заинлайнено). Несколько сотен мегабайт. То же самое происходит и с C2, компилятору нужно место для представления тех данных, которые он компилирует. Но если использует C2, то аллокация происходит в нативной куче с malloc. Мы видели разные сценарии с C2 за годы, в худшем случае при компиляции метода с C2 потребовался гигабайт памяти. Обычно мегабайт двести или что-то вроде того. Но суть та же. Разница просто в том, где аллоцируется память. В случае с C2 это нативная память, а с Graal — Java-куча.

Руслан: У меня, возможно, тупой вопрос, но нельзя ли для избегания накладных расходов от использования Java-объектов в графе использовать скаляризацию и escape analysis?

— Нет, нельзя.

Руслан: Так и знал, это было бы слишком просто.

— Escape analysis и скаляризация позволяют скаляризовать что-то только в методе, где вы их используете. Простой пример: у вас есть метод, в самом начале метода вы создаёте объект и присваиваете его локальной переменной. Но граф компиляции существует на протяжении всей компиляции, переходя между различными стадиями, и порой достигает сотен мегабайт.

Руслан: Это я и ожидал услышать, потому что если бы это было возможно, вы бы знали об этом.

— Да, это было бы потрясающе. Это стало бы Священным Граалем компиляции. Но так не сделать.

Руслан: Олег, есть ли у тебя ещё вопросы по Graal?

Олег: Что, если я хочу JIT-компилировать один метод с помощью Graal, а всё остальное с C2? Такое возможно?

— Ну, в принципе возможно. Но нет чего-то, что можно просто вбить в командную строку: «Так, этот метод компилировать с Graal, остальное с C2». Брокер, который распределяет код в HotSpot такого не поддерживает. Но вот что возможно… Мы раньше упомянули Truffle, и с его помощью можно. В VM есть JVMCI, можно включить его, получая возможность компилировать метод JVMCI-компилятором. Graal — это JVMCI-компилятор. Truffle использует C1 и C2, а также он парсит код. Так что при парсинге метода можно отправить его в Graal.

Олег: Вы когда-нибудь такие трюки применяли?

— Нет, никогда не сталкивался с ситуацией, где такое бы понадобилось. Я хочу использовать Graal в 100% случаев, я хочу избавиться от C2, зачем тогда по-прежнему его использовать.

Руслан: Вам это не нужно, потому что Graal не ломает обратную совместимость, можно просто всегда использовать его.

— Именно так!

Руслан: Давайте перейдём к конференции LavaOne. Сколько людей там было в 2018-м?

— Недостаточно.

Руслан: Глядя на программу конференции, хочется спросить: как вы её составляли, просто открыли Call for Papers и ждали заявок, или у вас было своё видение и вы целенаправленно приглашали конкретных спикеров?

— В этом году я в первый раз устроил это, раньше на Гавайях никогда не было Java-конференции, такое случилось впервые. Я знал, что будет сложно, потому что тут нет настоящего Java-сообщества — например, нет местной Java Users Group. И я подумал сделать так: открыть CFP, увидеть, о чём спикеры хотят рассказать, и выбрать доклады, которые будут подходить для людей, ни разу до этого не бывавших на Java-конференциях.

В общем, я открыл CFP, и ряд спикеров сказал «Это звучит интересно, хочу выступить». Я выбрал временем проведения конференции январь, когда примерно во всём остальном мире довольно холодно. Благодаря этому я мог заполучить на Гавайях очень хороших спикеров. И затем выбрал то, что мне казалось хорошим. Я не знал уровень экспертизы зрителей, так что выбрал разное — что-то высокоуровневное, что-то низкоуровневое. Думаю, получилось хорошо.

Руслан: И у вас там было 12 докладов, или на NightHacking доступно не всё?

— Да, 12, все транслировались в прямом эфире, можно посмотреть записи.

Руслан: У нас при организации конференций есть проблема с тем, что зарубежные спикеры говорят «Нет, я не отправлюсь в Россию, потому что я не поддерживаю...», и дальше куча вариантов. У вас такой нет?

— Да, думаю, это специфичная для вас проблема.

Руслан: Раз для вас сложность в том, что на Гавайях нет Java User Group, может, вам её создать?

— Это тоже не так просто. Но если бы всё было просто, я бы этим не занимался. Смотрите! *показывает фотографию гавайского JUG*

Руслан: Так вы опередили наш совет!

— Да. В общем, главная проблема была в аудитории. Как я уже сказал, собрать спикеров сложности не было, а со зрителями без сообщества было непонятно. Мы активно использовали Twitter, но у меня есть ощущение, что немногие айтишники на Гавайях сидят в Твиттере. Они используют LinkedIn и Facebook. Я понял это, когда планировал LavaOne и пытался достучаться до людей. Много такого узнал. Я читаю лекции в университете, так что старался привлечь студентов. Им не надо было покупать билет, для них посещение было бесплатным. В общем, с этим было сложно, но надеюсь, что в следующем году будет полегче.

Руслан: А пытались получить поддержку Oracle?

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

Все зрители были местными, никто не прилетал ради конференции откуда-то, но этого я и не ожидал. Зато был спикер, прилетевший из Японии, это было здорово. А Россия недалеко от Японии, так что прилетайте тоже в следующем году!

Руслан: Ну как «недалеко», у нас есть граница с Японией, но Москва и Петербург в тысячах километров оттуда.

— Я слышал, что можно добраться на поезде. Садитесь на него!

Руслан: Да, за неделю, как раз Scala-приложение за это время скомпилируется! Вот ещё о чём хочется спросить. Мы за последний год получили много фидбэка о том, что среди спикеров стоит увеличить количество женщин. Но для Java-конференций это сложно, потому что среди Java-сениоров женщин в принципе мало. У вас состав спикеров вроде бы тоже мужской, вы об этой проблеме думали?

— Разумеется! У меня состав спикеров не был полностью мужским, было трое женщин. Одна — Мерседес Уисс, можете позвать её в Россию. Ещё были Хезер ВанКура из JCP и Йоланд Пуарье (Java community manager в Oracle), у них был совместный доклад как раз о помощи женщинам в IT, так что на LavaOne рассматривали конкретно эту тему. Вам стоит посмотреть это выступление, там много информации, которая может быть важной для вас.

Нам точно стоит способствовать участию женщин в конференциях. Выступать на конференции для многих и так может быть пугающим действием, а если все остальные спикеры мужчины и вы единственная женщина, то это становится ещё сложнее. Поэтому необходимо поддерживать в этом. Проект JDuchess может тут служить хорошим примером.

Руслан: Спасибо! Может, хотите сказать что-то российскому Java-сообществу или посетителям наших конференций? Призвать людей контрибьютить в Graal?

— Да, приезжайте в Новосибирск посмотреть мой новый доклад! Готовлю его сейчас, он называется «Graal: как использовать новый JIT-компилятор для JVM в реальной жизни». Там будут слайды, но основную часть доклада займут демо. Я буду просто показывать людям, где его взять, как использовать, что иметь в виду. Я объясню всю ситуацию с бутстрэппингом. Хочу, чтобы доклад был как можно более прикладной, так что люди остались с ощущением «О, это на самом деле просто использовать!» Так что вам определённо стоит или лично посетить доклад, или позже посмотреть на видео.

И возвращаясь к тому, что вы сказали раньше о приглашении спикеров. Я не хочу лезть в политику, но мне нравится приезжать в Россию, мне нравятся российские конференции, они интересные и хорошо организованные. Думаю, что и для всего технического сообщества на планете, и для Java-сообщества в частности, не имеет особого значения, какая страна… Мы все занимаемся одним и тем же. Мы пытаемся писать хороший софт, мы помогаем друг другу с этим, мы пытаемся сделать всё дучще. Вот почему спикеры отправляются на конференции: мы хотим рассказыавть людям о новых вещах и помогать им. Так что для меня нет никакой проблемы в том, чтобы приезжать в Россию и выступать на ваших конференциях. Мне это нравится, неважно, в какой стране мы находимся.

Руслан: Спасибо за это! Надеемся, вы донесёте это до зарубежных спикеров, с которыми встретитесь в США или Европе.

— Обязательно! Когда разговариваю с людьми, говорю им, что был в России на конференции Joker и определённо хочу ещё. Я приезжаю на каждую конференцию, куда вы меня приглашаете.

Руслан: Здорово, это приятно слышать, а то иногда думаешь «Что я делаю в этом месте, куда никто не хочет ехать».

— Я вот живу на Гавайях, где лето круглый год, зачем мне ехать в Новосибирск в марте? Это глупо, но… Я хочу поехать. Я хочу оказаться там, разговаривать с людьми и рассказывать им о новых вещах и о клёвых штуках, над которыми мы работаем. Причина в этом.

Руслан: Кстати, на Гавайях температуру меряют по Фаренгейту или Цельсию?

— По Фаренгейту. Если переводить, то сейчас, в 8:30 утра, здесь 23 градуса Цельсия.

Руслан: В Новосибирске, где живёт Олег, по Фаренгейту сейчас -29. Так что завидуем! Надо будет следующее интервью у вас брать на Гавайях, оформить как командировку. Спасибо за ответы, Крис!

— И вам спасибо! Увидимся на JBreak!

Минутка рекламы: как вы уже поняли, мы организаторы новосибирской конференции JBreak 2018, и до неё осталось меньше двух недель. Там можно будет и увидеть новый доклад Криса, и лично пообщаться с ним в дискуссионной зоне, и узнать много другого — все подробности и билеты доступны на сайте!