Накануне Java-конференции Джокер 2015 который начнется завтра, я публикую большое интервью с Алексей Шипилев , инженер группы производительности Java в Oracle, один из самых крутых и известных экспертов по производительности в мире.
И, конечно же, отличный оратор.
Мы подробно поговорили с Алексеем:
- о предстоящих изменениях в классе String;
- о том, кто на самом деле разрабатывает OpenSource;
- о разработчиках систем и их карьере;
- об обмене технологиями, «научных» и «продуктовых» разработках;
- о сложности низкоуровневых задач;
- о развитии Java-сообщества и бенчмарк-войнах;
- об изменяемых и неизменяемых;
- о Небезопасном;
- о JMH, бенчмарках и узкой специализации.
Продолжительностью более часа, его можно слушать в дороге.
Под катом — стенограмма нашей беседы для тех, кому видео не понравилось.
Об изменениях в строке
— Алексей, раньше вы много говорили о Performance, а в последнее время много работали над классом String. Подскажите пожалуйста, с чем это связано? — Я также говорю о String с точки зрения производительности, поскольку участвую в проектах, направленных на оптимизацию строк.Каждый день в этой области делается множество небольших оптимизаций, но мы вносим два основных изменения.
Первое - это Компактные струны .
Символы большинства строк, которые есть в Java-приложениях, размещаются практически в ASCII. Это означает, что каждый символ в строке может использовать 1 байт, а не 2, как того требует спецификация char. Сегодня внутри String внутреннее хранилище представляет собой массив символов.
Он высоко оптимизирован, и люди ожидают от него высокой производительности.
Поэтому, чтобы попытаться сжать эти строки, нужно сделать два представления этой String: одно представление представляет собой типичный массив символов, а второе — массив байтов, в котором каждый байт соответствует определенному символу.
И необходимо провести большую работу над производительностью, которая обеспечит, как мы говорим в критериях выпуска, «нерегрессию».
Чтобы пользователи, перешедшие с Java 8 на Java 9, не только не испытывали боли, но испытывали счастье и прирост производительности от этой нашей фичи.
И там много разных волнующих вещей, о том, как работает «библиотека», как и что делается с конкатенацией строк, как рантайм все это дело обрабатывает. В общем, очень много мелких деталей.
- Совсем не страшно? Класс String — он также проходит через весь JDK. - Тупой! На самом деле, вы даже можете увидеть, что под оригинальным предложением ребят из команды библиотеки классов есть несколько забавных комментариев.
Один из них принадлежит Мартину Бухгольцу из Google, который известен как один из разработчиков JSR-166. Мартин однажды сказал что-то вроде: «Это сложная задача, удачи!» Второй комментарий от меня, что-то вроде: «Ну ребята, я не верю, что такое можно сделать, потому что черт его знает… String — это такой класс.
Прикасаться к нему действительно опасно».
Сейчас мы потратили полгода на тщательное прототипирование этого изменения, тщательное его измерение, выработку понимания того, как все это влияет на производительность, выбор правильной стратегии генерации кода.
И теперь я очень рад, потому что понимаю, что это изменение То, что казалось опасным, стало ясным после всей этой работы.
Знание всех плюсов и минусов помогает, и с ним все в порядке.
— А что теперь будет с теми, кто для ускорения работы своего кода нагло полез в массив символов, лежащий в строке? - Их ждет сюрприз.
Согласно спецификации, никто не гарантирует, что внутри строки находится массив символов.
Я думаю, что люди, которые идут на многое, чтобы выиграть какое-то выступление, уже изначально подписываются на то, что они должны следить за всеми изменениями.
— Что такое «нет регресса производительности»? Есть ли какой-то набор тестов, есть ли какие-то критерии его оценки? — К этому есть формальное и неформальное отношение.
Неформальное отношение таково, что у нас есть большое сообщество, которое привыкло к тому, что основной выпуск работает по крайней мере так же медленно, как и последний крупный выпуск.
Потому что иначе возникают проблемы, как перейти на новую версию.
Поэтому, когда вы разрабатываете новую фичу, вы помните, что нельзя просто провалить производительность, нужно где-то выиграть.
И есть формальные критерии, которые говорят, может ли производительность теряться на такой-то процент при таких-то нагрузках.
Но это внутреннее дело команды разработчиков, а не OpenJDK. Скорее отношение именно такое — мы понимаем, что сообщество хочет, чтобы Java не регрессировала.
Мы также хотим, чтобы Java не регрессировала.
Наше развитие опирается на это невысказанное предположение.
— Вы как-то общаетесь с крупными вендорами, с производителями корпоративных серверов, линии которых продолжаются? - Это довольно просто.
Мы работаем в крупной корпорации и имеем много внутренних клиентов.
И их вполне достаточно.
Это только кажется, что open source висит в воздухе, что его разрабатывают сами, хакеры-энтузиасты.
Обычно все наоборот. Есть крупные игроки, которые финансируют разработку по каким-то внутренним причинам.
Почему Oracle купила Java у Sun и начала инвестировать в ее развитие? Дело в том, что когда вы инвестируете в платформу, вы даете большие бонусы своей организации-разработчику.
Если у вас есть продукт, у которого проблемы с производительностью, и вы знаете, что он локализован во время выполнения, вы можете прийти к разработчикам и сказать: «Ребята, вот это баг! Давай, исправь это побыстрее».
И разработчики понимают, что им за это платят зарплату и идут исправлять.
О разработчиках систем и их карьере
- Вы суперизвестный человек.Наверняка, каждый день вам в LinkedIn пишет куча хедхантеров и пытается перебить вашу ставку.
Почему ты все еще в Oracle? «Знаете, я давно пытаюсь ответить на этот вопрос для себя и постоянно отвечаю другим.
Я читал в блоге или в какой-то книге, что если посмотреть, как устроены слои продуктов в нашей отрасли, то мы увидим, что есть оборудование, есть операционные системы, библиотеки, приложения и т. д. А если посмотреть на население разработчиков на всех этих уровнях, вы получаете перевернутую пирамиду.
Ниже приведены люди, которые делают фундамент низкого уровня.
И этих людей очень мало.
По объективным причинам – порог входа достаточно высок, нужен большой опыт и хорошее образование, чтобы вы смогли там сделать что-то разумное.
— Другими словами, чтобы улучшить процессор Intel, нужно… - Вам нужно много и долго учиться.
Гораздо больше, чем, например, написание приложения для Android. Чтобы стать хорошим системным инженером, вам понадобится 5–10 лет опыта работы на производстве.
Когда ты уже приобрел этот опыт, кажется, что твое место в этой экосистеме находится именно на этом низком уровне.
Можно, конечно, перейти с этого уровня и написать какие-то корпоративные приложения, но это значит, что вы подвергаете воздействию всех тех людей, которые находятся рядом с вами там внизу, вникая во все это.
Там серьезная нехватка кадров.
Там столько работы — просто тьма.
Я более-менее трезво пытаюсь оценить соотношение той работы, которую мы можем сделать, и той работы, которая необходима.
И это соотношение составляет один к 10, а то и 100. — Значит, действительно не хватает людей? — Да, и это не особенность Java. Это особенность данного системного уровня.
Там мало людей, много работы, поэтому там есть хорошие интересные задачи.
Это дает вам возможность выбирать, какие задачи вы хотите выполнять.
Из 100 заданий, которые у вас есть, вы можете выбрать задания, которые дают:
- а) прибыль общества;
- б) прибыль вашей компании;
- в) прибыль лично для вас.
Обычно чем меньше людей, тем дороже.
У меня такое ощущение, что в нашей отрасли как-то все это работает по-другому.
Так? — Нет, системщики просто дорогие.
Хорошие системные инженеры стоят очень дорого.
И самое главное, что предложение там существенно меньше спроса.
И значительно меньше конкуренции.
Это не значит, что я сижу в своем гараже и работаю над своим стартапом, молясь, чтобы кто-нибудь в соседнем гараже не придумал точно такую же идею для стартапа и не реализовал ее.
В моей сфере всех людей, которые занимаются чем-то похожим на мой бизнес, можно перечислить в одном письме.
И особой конкуренции нет. Поэтому, скажем, веселые отраслевые конференции вроде тех же JVMLS , забавное зрелище.
Когда читаешь какой-нибудь форум по программированию, возникает, например, спор — «какой язык лучшеЭ», «какая платформа лучшеЭ» и т. д. А когда ты в компании JVMLS, когда рядом с тобой сидят люди, которые на самом деле работают на «нижнем уровне», есть согласие и взаимопонимание.
Потому что там все в одной лодке, все дико перегружены, у всех одинаковые проблемы.
Это такой большой сеанс психотерапии.
Никаких «пинков пяткой в грудь», никаких заявлений о том, что «мы сделали лучше, а вы все отстой».
Там, естественно, есть понимание и братство, основанное на каких-то личных симпатиях и антипатиях.
— Где современному студенту или недавнему аспиранту научиться системному программированию? У меня такое ощущение, что в современных университетах преподают по учебникам и лекалам 80-х.
— И это очень неплохо, потому что фундаментальная наука остается фундаментальной.
И это не зависит от конъюнктуры рынка.
Есть классические книги и учебники, ставшие классикой университетских программ.
Может быть, не в советских или российских университетах.
Можно просто взять программу какого-нибудь Стэнфорда или MIT и посмотреть, что они читают, по каким учебникам они ее читают. - Например, Информатика 101 ? — Информатика 101 — это обычный вводный курс.
И для них есть специализированные курсы и учебники.
Если вы не можете посмотреть курс онлайн, вы можете просто найти учебник, который обычно представляет собой классическое произведение.
И учиться непосредственно на этом.
Я знаю немало школ в России, которые так делают. В Новосибирске, например, одно время существовала школа, которую еще создавал академик Ершов, школа составителей.
- Это связано с Эксельсиор в современном виде? — Эксельсиор, я думаю, родился там именно потому, что там были люди с достаточным опытом.
Они могли бы собраться вместе и производить такие продукты.
А если после учебников хочется практики, то в большинстве компаний, занимающихся таким программированием, открыты вакансии для стажеров и джуниоров.
Вы можете на практике убедиться, насколько то, что написано в учебнике, отличается от того, что происходит в действительности.
— С вами случилось то же самое? - Да.
Будучи студентом, я стал стажером в команде Intel, которая работала над средами выполнения Java. С одной стороны, я учился в университете и читал книги какого-то Мучника, Хеннесси-Паттерсон , Таненбаум и другие, но зато у меня на работе был реальный продукт, в который я мог попытаться перенести идею из учебника.
Или просто прочитайте проект и поймете, что это то, о чем вы прочитали месяца два назад в учебнике.
Такова теория и практика.
Это похоже на то, что называется «системой физтеха»: когда студентам в первые три года дают фундаментальные основы (математика, физика, информатика), а затем их направляют на условно базовые кафедры в научные институты, промышленное производство, где они под крылом руководителей-практиков занимаются настоящей научной работой.
В нашей отрасли эффективный инструмент примерно один и тот же — студенту необходимо получить базу в вузе, а затем присоединиться к какой-нибудь организации, где он сможет начать использовать свои знания на практике.
Яндекс, ABBYY, Сбертех и другие компании, насколько я понимаю, движутся точно в том же направлении.
Они хотят набирать студентов и обучать их.
- Проблема известна.
Дефицит отрасли растет быстрее, чем академические учреждения могут обеспечить кадрами.
Рост отрасли составляет около 15% в год. И это много.
— Я бы все-таки разделил индустрию прикладного ПО и индустрию системного ПО.
Размер индустрии прикладного программного обеспечения расширяется или сокращается в зависимости от того, что происходит на рынке: от готовности инвесторов вкладывать средства в отдельные направления или стартапы.
И насколько я вижу, всегда есть спрос на программирование системного уровня, потому что это фундамент, на котором все работает. И больших колебаний спроса нет, потому что люди, делающие платформы, нужны всегда.
Об обмене технологиями, «научных» и «продуктовых» разработках
— Java активно крадет технологии, возможности и идеи из других языков? — Я бы не назвал это «мастерством», потому что в технологиях, например, в рантаймах, значительная часть разработки выполняется либо в академии, либо в полуакадемических научно-исследовательских лабораториях, которые публикуют научные статьи или технические отчеты о том, как они работают. «пробовал такую идею».Сгорел/не сгорел».
Люди, реализующие рантаймы, читают эти статьи: «Да, нас это устраивает, давайте попробуем реализовать это здесь».
Понятно, что одну статью будут читать люди, пишущие рантаймы для разных языков.
Основной основой такого рода развития является полунаучное и полупромышленное слияние НИОКР.
— Есть ли сейчас такие лаборатории в России? «Такой вид работы требует уникального набора навыков.
Я не знаю целых лабораторий, которые базировались бы в России, а знаю отдельных людей, которые участвуют в таких разработках.
Если мы говорим о научно-исследовательских лабораториях, финансируемых промышленностью, то граница между исследованиями и прикладным внедрением достаточно подвижна.
Часто это одни и те же люди.
— Известно, что многие инженерные проблемы в конечном итоге решаются учеными, а многие научные проблемы решаются инженерами.
В прикладной математике такое происходит постоянно.
— В Oracle Labs есть люди, более ориентированные на науку, которые пробуют решения в отрыве от продукта.
А продукт их работы — технические отчеты или статьи.
И есть продуктовые команды, которые, пытаясь улучшить продукт, берут идеи из подобных научных статей.
При этом нередко внутри самого продукта рождаются какие-то решения, которые затем замечают исследователи и пытаются развивать.
Это такой симбиотический процесс.
Вот почему НИОКР финансируются крупными корпорациями.
— То есть есть ощущение, что компании вкладывают в это деньги? «Это не чувство, я просто это вижу».
О том, кто продвигает OpenSource
— Возвращаясь немного к вопросу открытого исходного кода, и в частности Java. С одной стороны, его разрабатывает и продвигает вендор, т.е.Oracle, с другой стороны — это сообщество, существующее отдельно от организаций.
В экосистеме Java есть Дуг Ли, который очень увлечен параллелизмом, но он не работает в Oracle. Насколько уникальна эта ситуация, когда лидер региона находится вне организации? - Не уникальный.
Например, Oracle не активно разрабатывает вопросы, связанные с портированием на альтернативные архитектуры.
Например, ARM64 в основном разрабатывается Red Hat, потому что Red Hat заинтересована в этом.
Есть еще условный Intel, условный AMD, которые тоже заинтересованы в улучшении генераторов кода.
- Их вообще видно? К вам приходят люди из Intel и AMD и говорят: «вот оптимизация для нашего последнего процессора»? - Они не могут этого сказать.
Они говорят: «Послушайте, если мы сгенерируем такой код, будет лучше.
Вот наши данные о производительности».
И если составители говорят, что это изменение действительно хорошее, то всё это принимается.
— Какой процент людей в Java-организации занимается низкоуровневыми задачами? - Я никогда не считал.
Грубо говоря, я бы сказал, что в моей небольшой сфере деятельности JDK, наверное, около пятидесяти человек, с которыми я более или менее часто контактирую.
Честно говоря, я не знаю, сколько людей занимается какими-то другими фичами.
Можно, конечно, посмотреть рабочую схему и оценить, но там будет много людей, которые занимаются разработкой.
- Сотни людей? - Думаю, две-три сотни.
— Чувствуете ли вы, что низкоуровневая часть — это большой процент людей? - Да, большой.
Но задача эта пока настолько сложна, что этих людей по-прежнему не хватает. 
О сложности низкоуровневых задач
- Почему задание сложное? - В основном потому, что здесь много движущихся частей.Есть много вещей, которые вам нужно знать и к которым нужно быть готовым.
Например, вы пишете компилятор и вам необходимо знать ошибки процессора.
Знайте, во-первых, что они вообще существуют (а для многих это новость, что есть ошибки в процессорах), что вам нужно будет посмотреть на эти ошибки, чтобы понять, что не всегда в нестандартном поведении виноват ваш компилятор.
.
Вы должны знать, уметь и понимать, что ошибка, которую вы сейчас исправляете, может быть связана с каким-то диким вмешательством прошлых преобразований кода, которые были сделаны до той части, за которую вы предположительно несете ответственность.
Вам нужно знать этот стек досконально.
Сами рантаймы — это продукты, в которых компоненты можно разделить в большую ячейку, но на самом деле эти компоненты очень тесно связаны друг с другом.
Если вы хотите исправить ошибки, это часто означает, что вам нужно исправлять ошибки в разных компонентах, а если вы занимаетесь перформансом, то вам обязательно придется работать над кучей компонентов одновременно.
Я радуюсь как ребенок, когда мой патч производительности занимает пять строк в одном файле, потому что это крутое изменение производительности, оно явно правильное и помогает. Но большие, хорошие изменения в производительности обычно требуют изменений во всех маленьких частях всего большого продукта.
Поэтому вам нужно знать этот продукт, а продукт огромен.
— Означает ли это, что он плохо спроектирован? - Нет. - Почему же тогда происходят такие вещи? Одним из критериев хорошего дизайна считается локальность: чтобы устранить проблему, нужно покопаться в одном месте, а не в десяти.
«На бумаге все прекрасно работает».
На самом деле происходят две вещи: во-первых, когда начинаешь гнаться за производительностью, оказывается, что абстракциям необходимо иметь место в каких-то отдельных местах, потому что именно так ты и получаешь выигрыш.
А во-вторых, выскакивают баги.
Вы что-то знаете о платформе, о том, как ведет себя платформа, что процессор, например, точно передает из регистра в регистр, когда вы ему говорите «двигаться».
Если отталкиваться от этого предположения, можно написать красивый компилятор, но вдруг окажется, что в процессоре есть ошибка.
Что вы сделаете, чтобы это исправить? Вбиваете костыль в генератор кода.
Потому что это практическое решение практической проблемы.
— А если у клиента есть ферма, и на ферме 1000 сломанных процессоров… — Если прочитать исходный код JVM HotSpot, то можно увидеть там разные ужасы и, что самое важное, многие из этих ужасов подписаны.
Например, можно встретить комментарии в духе «этот код написан некрасиво, но он написан некрасиво по таким-то причинам».
— Это правило вообще соблюдается? - Обычно наблюдается.
Когда вы исправляете такие ошибки, вы должны написать, почему вы на самом деле сделали такой иезуитский поступок.
И в таких местах обычно пишут что-то вроде: «Наивный человек мог бы предположить, что это можно было написать по-другому.
Но здесь по-другому написать нельзя, потому что преобразования в таком-то месте придадут этому графу такой-то вид. И вообще, зайдите и почитайте баг по этой ссылке, там вы увидите пятнадцатистраничный эпос о том, почему эта штука работает не так, как надо.
То есть это мелкие детали.
Аппаратная транзакционная память
— Возвращаясь к ошибкам и процессорам.В классическом книга У Херлихи и Шавиты есть отдельная глава, посвященная аппаратной транзакционной памяти.
Не могли бы вы рассказать нам немного больше о том, что такое транзакционная память? — Рациональность транзакционной памяти в том, что возникает проблема синхронизации, когда нужно произвести скоординированное изменение в нескольких местах памяти.
Когда вам нужно внести атомарные изменения в одну ячейку памяти, вы просто выполняете атомарную операцию.
Другое дело, когда вам нужно сделать какое-то нетривиальное преобразование, которое вы делаете несколько чтений, несколько записей, вам нужно сделать весь этот блок атомарным.
Можно сделать блокировку, сказать, что «мы захватили здесь блокировку, сделали все под ковриком, отпустили блокировку», и это работает с функциональной точки зрения.
Другое дело, что будет на этих локах? Раздор! Поэтому я хочу получить некий аппаратный механизм, которому можно будет сказать «в начале транзакции запомни, что у нас было, потом под ковром я что-то сделаю в состоянии машины, а когда зафиксирую транзакцию».
, то все это состояние машины будет атомарно отображаться всем остальным».
Это все транзакция.
У меня есть не просто отдельные операции записи и чтения, у меня есть целая транзакция, которая публикует все это состояние сразу или вообще ничего не публикует. - Это выглядит как КАС , что меняет ссылку.
— Да, это можно сделать с помощью CAS, но там возникают проблемы — там нужно сделать обертки, которые вы будете CAS, а здесь можно сделать и с голой памятью.
— А обертки влекут за собой распределение, трафик памяти.
- Да.
HTM помогает всего этого избежать, обойтись без лишнего создания объектов-оберток.
Вы можете сказать так: «Теперь я начал транзакцию, сделал 10 хранилищ в памяти, фиксирую транзакцию, и либо все эти 10 хранилищ видны, либо ни одно из них не видно».
— Как в базах данных? - Да.
Вот почему такая память называется транзакционной, потому что это транзакция.
Но для этого нужна аппаратная поддержка.
Потому что уже существовали программные реализации транзакционной памяти.
Программные реализации выполняются значительно медленнее, поэтому необходима аппаратная поддержка.
Мне нужно как-то объяснить аппаратуре, что если я выполню команду «начать транзакцию», то в этот момент машина говорит «ок, я прикину, что все, что делается после начала этой транзакции, никому не видно, и при коммите я все опубликую».
— Есть ли инструкции типа «начать транзакцию» прямо в ассемблерном коде? — хстарт. Затем вы говорите: xcommit, и оборудование сообщает вам, удалось ли ему зафиксировать транзакцию или нет. ксаборт. Всё хорошо.
Все ждали появления аппаратной транзакционной памяти.
Азул в своем Вега уже давно занимаются созданием транзакционной памяти и добились, как говорится, успеха с эксплуатацией этой HTM-памяти в Java. — Только Вега умерла.
— Вега не просто так умерла.
Гил Тене , технический директор Azul Systems, заявил, что x86_64 настолько приблизился к Vega по характеристикам производительности, что поддерживать Vega стало нерентабельно.
— Да, поддерживать оборудование дорого.
- Да, и почему? Когда есть продавец оборудования, у которого есть завод и он продаёт тебе всё за копейки.
По сравнению со стоимостью собственного производства микропроцессоров это сущие копейки.
И все обрадовались и начали делать свои небольшие прототипы.
Даже мы.
Естественное место, где вы можете использовать HTM в Java, — это, скажем, тривиальный синхронизированный блок, в котором есть 2, 3, 4 хранилища.
Вы начинаете транзакцию на входе и сбрасываете ее на выходе.
Семантика точно такая же.
— То есть JIT вдруг говорит, что мы теперь не блокировки используем, а такие хитрые транзакционные инструкции? — И это было сделано даже чуть ли не в восьмёрке.
Но тут вдруг, как гром среди ясного неба, выяснилось, что какие-то чуваки нашли ошибку в аппаратной реализации этого самого HTM в Haswell. А поскольку этот баг, насколько я понимаю, уже был в кремнии, исправить его невозможно.
— То есть схема кривая? - Да.
Поэтому Intel извинилась перед всеми и выпустила обновление микрокода, в котором HTM был отключен.
Поскольку HTM — это необязательная функция, и для ее использования необходимо проверить флаг процессора.
Вы можете выпустить обновление микрокода процессора, в котором будет написано: «Я это не поддерживаю».
Это ошибка производителя оборудования, но такое иногда случается.
— Был знаменитый отзыв процессоров Pentium III. Судя по всему, это происходит раз в 10 лет. — Не с Pentium III, а просто с Pentium, по-моему.
Несмотря на то, что многие, как и я, купили Haswell частично, чтобы попробовать TSX, а потом вдруг оказалось, что ваш процессор превратился в тыкву.
— Вы в итоге обновили микрокод или забыли его? — Оно обновится автоматически.
- Как это произошло? — Обновляет операционную систему при загрузке.
У нее есть специальная сумка с микрокодом.
— То есть биос для этого обновлять не нужно? — Насколько я понимаю, это делается через BIOS/UEFI, операционная система сообщает процессору: «Вот ваш новый микрокод».
— Вообще-то такое уже есть у всех? — Да, это нормальная стратегия с точки зрения функционала, потому что был баг, портящий память.
Лучше медленнее, но правильнее.
— Каковы планы Intel на будущее в отношении HTM? - У них новая ревизия.
Кажется, оно называется Скайлейк.
Haswell рекламировался как «процессор, поддерживающий аппаратную транзакционную память», а Skylake рекламировался как «процессор, который наконец правильно поддерживает транзакционную память».
Посмотрим, как пойдет на этот раз.
О развитии Java-сообщества и бенчмарк-войнах
— Когда Sun работала с сообществом, было полное ощущение, что Sun владеет всем.С покупкой Oracle все боялись, что будет еще хуже.
А сейчас у меня такое ощущение, что Oracle, наоборот, вложила значительные средства в развитие Java-сообщества.
Насколько обоснованно это чувство? — Когда говоришь о таких вещах, нужно отделять субъективное ощущение от объективного.
Sun, конечно, прекрасно работала с сообществом, рассказывая на конференциях о том, как оно развивается.
Однако, если вы прочтете обзоры некоторых JavaOnes, которые проводила Sun, Sun из года в год объявляет одними и теми же словами, что они выпускают ту или иную функцию.
Можно просто посмотреть, что и как, используя объективные критерии.
Сколько лет выпускалась семёрка? - 5 лет. — Когда вышла семёрка? - в 2011. — Когда Oracle купила Sun? — В 2009–2010 гг.
- Здесь.
Потому что Oracle, придя и купив Sun, сказала: «Ребята, хватит пытаться съесть слона целиком, давайте есть слона по частям.
Здесь у нас есть базовый набор функций, которые появляются в JDK 7, и мы выпускаем JDK 7, вперед».
— Вы скорее говорили о модели релиза, но меня больше интересует сообщество.
— Мне сложно сравнивать, потому что, когда я работал в Sun, я особо не работал с сообществом.
— Но вы были в Intel, и, насколько я понимаю, вы там делали Harmony. То есть вы видели все с другой стороны.
И это было, по моему мнению, еще до открытия исходного кода JDK. - Да.
OpenJDK вышел в 2007 году, и мы это сделали.
Гармония с 2004 по 2008 год. История здесь в том, что до некоторого времени мало кто интересовался разработкой самой среды выполнения.
Потому что было довольно много вендоров, которые сделали свою JVM. Был Oracle, который создал JRockit и стек, построенный на его основе.
Потом была и остается IBM, которая делает J9. Была SAP и другие компании, создавшие свои собственные JVM. То есть существовала конкуренция между поставщиками.
Я участвовал в так называемых «эталонных войнах».
Когда у вас есть Java как стандарт, как спецификация, и есть несколько разных реализаций от разных вендоров, и вы используете бенчмарки, чтобы показать, какая из этих реализаций круче.
Это привело к довольно большим улучшениям во время выполнения, этого нельзя отрицать.
Однако есть в этих бенчмарк-войнах один небольшой минус — после определенного момента эти бенчмарк-войны превращаются в экономию на разного рода совпадениях, которые не помогают реальным приложениям, а помогают конкретным бенчмаркам.
И это нормально.
То есть вы сначала оптимизируете то, что помогает всем, а потом ничего не остается, как в условиях конкуренции оптимизировать то, что вы в здравом уме вообще не стали бы оптимизировать.
Например, поместите кеш перед HashMap, который кэширует первые двадцать тысяч длинных значений.
Понятно, что это не та оптимизация, которая нужна обычному пользователю; это необходимо для конкретного эталона.
Теперь, по моему личному мнению, войны за контрольные показатели на уровне программного обеспечения утихли; на аппаратном уровне они все еще происходят. И теперь у нас есть OpenJDK как такой индустриформирующий проект. Это сотрудничество многих компаний.
Если раньше у всех была проприетарная реализация, каждый что-то ковырял отверткой в своей песочнице, то теперь есть общая реализация, в которой реализована куча общей инфраструктуры для рантайма.
И поэтому разумная стратегия — разработать одну реализацию.
— Есть ли проекты, похожие на OpenJDK по влиянию на индустрию? - GCC, LLVM и подобные крупные проекты.
Ведь open source рождается, в том числе, для экономии денег компании, чтобы каждая компания не изобретала велосипед заново.
С одной стороны, выгодно использовать чужие разработки, а с другой — каждая компания имеет свои и делится ими с другими.
Поэтому мне кажется, что сообщество, касающееся рантаймов, начало очень сильно развиваться с появлением OpenJDK. Возвращаясь к вашему вопросу.
Я не думаю, что взрыв сообщества произошел из-за покупки Oracle компании Sun. Это было больше связано со структурой работы.
Если у вас есть проприетарная реализация, у вас меньше шансов заставить поставщика вас услышать.
А если у вас открытый исходный код, вы можете легко внести некоторые изменения самостоятельно; если они окажутся хорошими, вы сможете вернуть их сообществу.
? Теги: #Интервью #Высокая производительность #образование #java #jvm #перфоманс #Системное программирование #строка #без слайдов #шипилев
-
Создание Блога, Который Оценят Ваши Читатели
19 Oct, 24 -
Arduino <-> Stm32 Hal Или Наоборот
19 Oct, 24 -
Новый Блокнот++ 6.0
19 Oct, 24 -
Я Богат
19 Oct, 24 -
Коворкинг Подходящего Калибра
19 Oct, 24 -
Как Я Решил Заняться Разработкой Игр
19 Oct, 24
