» » » Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017

 

Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017

Автор: admin от 12-01-2018, 08:40, посмотрело: 39

Что можно посмотреть вечером или на этих выходных? Можно смотреть какие-нибудь фильмы, а можно — наш непрекращающийся сериал под названием «Java-конференции». Единственный сериал, после просмотра которого у вас может радикально увеличиться зарплата.



Вчерашняя статья про JPoint 2017 оказалась удивительно успешной. У неё почти не было комментариев, но на данный момент 88 закладок. То есть статья попала в цель: люди добавляют в закладки и смотрят — ура. Буквально в первый час её пришел читать сам Сатана.



Сегодня мы будем действовать по старой схеме: я для вас отсматриваю подряд 10 докладов, делаю короткое описание содержимого, чтобы неинтересное можно было выбросить. Кроме того, с сайтов собираю ссылки на слайды и описания. Полученное сортирую и выдаю в порядке увеличения рейтинга — то есть в самом низу будет самый крутой доклад. Оценки — это не лайки на YouTube, а наша собственная оценочная система, она круче лайков.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017

Блеск и нищета распределённых стримов

Спикер: Виктор Гамов; оценка: 4.24 ± 0.11. Ссылка на презентацию.





Первый слайд:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Понятно, что раз это Виктор, то речь пойдёт о Hazelcast, хоть с первого слайда это и непонятно. Это хороший вводный доклад на тему, как сделать стримы распределёнными, чтобы они наконец-то перестали тормозить (по-настоящему, а не как всегда).



Первым примером Виктор выбирает подсчёт слов — классическую задачу мира программирования. Будет мапа , нужно посчитать количество слов и вывести топ. Считать будут файлы с текстами песен Disturbed и Lady Gaga.



Можно сделать это на Спарке, как делает Женя Борисов. Понятно, что человек-хазелкаст не может опуститься до такого простого уровня.



Первый пример — с помощью стримов из восьмёрки вычитываем строки, и натравляем на результат compute — получается типичный подсчёт слов. Дается классификация операций над стримами: промежуточные, терминальные и стейтфул-блокирующие, иллюстрируется на примере с бургером (которую он невозбранно спёр из книжки про лямбды).



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Присутствует определенное количество кода на стримах с подробными объяснениями (алгоритмы простые, но позволяют всё хорошо продемонстрировать):



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Вопрос не в том, чтобы это написать хоть как-то, а чтобы сделать распределённым. Но интерфейс стримов распределённости не предполагает, нельзя просто так взять и сконвертить готовый код (максимум можно внутри одного процесса что-то сделать с помощью parallelStream, который не факт что вообще что-то ускорит). Лямбды тоже несереализуемы — просто так взять и переслать на другие ноды их нельзя. Результаты выполнения — тоже.



В 2014 году на JavaOne коллектив людей из Оракла (Гёц, Оливер, Сандоз, ...) рассказали как юзать эту парадигму для распределенных данных: сделали движок для Hadoop, Coherence, итп.



В изначальном дизайне библиотеки стримов можно было обычный Stream отнаследовать от DistributedStream, но этого сделано не было, ибо потребовало бы бороться с языком Java, притащить оверхед, и так далее. Поэтому нужно DistributedStream наследовать от просто Stream. В Хазле так и сделано.



В Coherence есть RemoteStreams, например. Там есть готовые коллекторы для стримов, для сборки данных в сериализованном виде. В Infinispan тоже есть куча интересных фишек.



Кроме собственно движка, у системы должно быть хорошее юзабилити: мы жабопрограммисты, нам хочется чтобы всё просто собиралось, фигак-фигак, девопс не про нас — сразу запихали в варник и шипнули на прод. Все эти вещи обещает решить Hazelcast. Распределённые кэши, распределённые вычисления, распределённое всё, и этим ещё и удобно пользоваться. Горизонтальное масштабирование, вертикальное масштабирование, бэкапы прямо на соседних нодах, итп.



Но есть и всякие проблемы, типа OOM.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Для демонстрации всех этих штук у Виктора имеется приложение, запиленное на Spring Boot, и внушительная демонстрация о том, как грузить данные (локально, не на кластере — но на клаудах он тоже всё это тестил, например, на Хероку. Или он так говорит). Виктор дальше делает лайвкодинг, и описывать лайвкодинг особо не имеет смысла.



Дальше Виктор переходит к Hazelcast Jet и Jet Streams — что это такое и как работает. (Кстати, вам не кажется, что это какой-то ад — столько продуктов называется Jet-чтотам?) Это либа для распределенных вычислений, работает на графовой модели и основана на Hazelcast IMDG. Можно сравнить со Spark и Flink.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Всё это, конечно, подробно описывается. Исполнение графа, тасклеты, итп. Показывает демки и бенчмарки, и на основании этого всего делает выводы. И потом ещё более 10 минут вопросов и ответов.



В этом описании пропущено достаточно инфы, чтобы доклад имело смысл смотреть, а Виктор не распял меня за тотальный спойлеринг всего :-)



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



9. Жизненный цикл JIT кода



Спикер: Иван Крылов; оценка: 4.29 ± 0.07. Ссылка на презентацию.





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



Говорящая картинка-эпиграф к этому докладу — Crazy House:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



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



Доклад будет о трансформации представления кода, профилях кода, деоптимизациях, и более практическая часть — 4 API для тюнинга компиляции. Две трети доклада — про проблематику, оставшаяся часть — практическая.



Вначале рассказывается про конвеер: статическая верификация, неоптимизирующая компиляция, получающийся в результате байткод, верификация в рантайме, линковка, исполняемый код.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Но может быть иначе: байткод может прилететь из какого-нибудь ByteBuddy, виртуалка может быть без интерпретатора как в JRockit, виртуалка может быть только с интерпретатором и всё, может быть гибридная виртуалка с AOT как в Excelsior JET.



Иван рассказывает о том, что профиль — это по сути, счётчики. Неточные счётчики для вычисления соотношений (а не абсолютные величины). Иногда у этих счётчиков есть дополнительные свойства — это позволяет делать дополнительные оптимизации.



Кроме профиля нужны ещё всякие небольшие интересные штуки. Иллюстрируется на особенностях скомпилированного Enum (в скомпилированном виде он весит больше, чем его текст — как бы намекает, что внутри зашита нетривиальная логика. Эту логику можно посмотреть по байткоду).



Иван показывает, как в общих чертах работает инлайнинг, и рассказывает о том, как однажды он этот инлайнинг случайно сломал (регрессия на 24%). Есть стандартные причины поломок типа: сильно большие методы, слишком большой уровень вложенности, специальные флаги настроек виртуалки, не инициализированные классы, несбалансированные мониторы, содержит байткод jsr, итп.



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



Дальше речь идёт об уровнях компиляци от 1 до 4. Рассказывается схема переходов, условия, пороги (типа полторы тысячи выполнений для C1), и другие интересные штуки. Если вам вдруг кажется, что вы всё это хорошо понимаете, то… скорей всего, это не так :-)



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



От этого делается переход к деоптимизациям, как они работают, как делятся на классы: детерминированные (constant propagation, с откатом (bias locking, tsx), спекулятивные с мгновенной остановкой (CHA invalidation).



Достаточно много кода должна выполняться по требованиям JVMS: проверки на обнуление, выход за пределы массивов, деление на ноль, проверка типов, итп. Чтобы код от них не тормозил, JIT изо всех сил пытается докзать, что эти проверки не нужны и выбросить их. Когда код меняется, эти оптимизации придётся выбросить. Приводится длиннющий список причин деоптимизации.



И завершается доклад подробным описанием API для настройки компилятора, которые связаны с описанной выше проблематикой. Даже если вам (как и мне) интересней копаться в кишочках JVM и экспериментировать, чем реально крутить настройки на проде кровавого ынтерпрайза — эту секцию всё равно стоит прослушать, т.к. там тоже много "мяса" по теме. Ключики просто так не объяснишь, любая попытка объяснить вскрывает дополнительные подробности. В том числе, есть пояснения про то, как это работает в Азуле.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Лично я буду использовать этот доклад для того, чтобы быстро вводить новичков в тему. Это хороший (и главное — быстрый) обзор темы про оптимизации и деоптимизации, который не выносит мозг чрезмерным погружением.



8. CRDT. Разрешай конфликты лучше, чем Cassandra



Спикер: Андрей Ершов; оценка: 4.32 ± 0.20. Ссылка на презентацию.





Доклад про ALPS системы (Available, Low Latency, Partition Tolerant, Scalable). К сожалению, в них неизбежны конкурентные модификации, и приходится понимать, какие изменения — правильные. Большинство систем, н-р Cassandra, использует политику LWW (last write wins) — будет показано, почему она не всегда работает. В качестве альтернативы LWW придумали CRDT, про который и рассказывается основная часть. В конце — много ссылок для домашней работы, самостоятельного изучения.



Всё это демонструется не на голой теории (которую можно и в пейперах почитать), а на примере милой сердцу любого веб-быдлокодера задачки о синхронизации данных в вебморде. Все демки не просто нарисованы на слайдах, а демонструются вживую (у Андрея на ноуте запущено 4 приложения).



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



То есть, эту приложуху открывают в двух вкладках браузера, но эти вкладки не общаются между собой напрямую, а через базу данных (Riak KV).



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



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



По ходу дела нас неотступно будут преследовать ссылки на документы, которые стоит изучить. В данном случае, способ организации данных в key-value базе освещается вот этим must have документом:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Но все такие сакральные вещи мгновенно демонструются на реальном, понятном примере типа распределенной корзины.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Если совсем кратко, то смысл в следующем: если из двух разных вкладок редактируется одно и то же поле, то может возникнуть конфликт. В предлагаемой системе, в веб-интерфейсе отобразится не просто последнее значение, а прямо так и будет написано: "у тебя тут конфликт, что будем делать?".



Рассматриваются вопросы типа ускорения отклика (асинхронная репликация, оптимистичный UI), решение проблем сети (сетевая сегментация, offline work чтобы работать в самолёте), итп. Короче, есть какие-то конкурентные изменения, и проблема с ними решается с помощью CRDT — conflict-free replicated data types.



Рассказывается, что такое Strong Eventual Consistency, и собственно CRDT (структуры данных со свойством SEC, решающие проблемы конкурентных изменений и автоматически разрешающие конфликты). Структуры данных там почти любые — счетчики, ргистры, флаги, списки, сеты, мапы, графы, и так далее — всё это можно описать в виде CRDT.



Рассматривается state based CRDT (при изменении состояния объекта передается всё состояние) и их проблемы. Точнее, одну основную проблему — огромный объем данных. Конкретные реализации — Akka и Lasp.



Аналогично рассматривается operation-based CRDT, преимущества и недостатки.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Предлагается прочитать книжку "Reliable and Secure Distributed Programming" обязательно на английском языке, потому что русский перевод — фуфлыжный. После этого переходим к базовому описанию разных видов broadcast: Unreliable, Reliable, FIFO, Gloabal Order. Обсуждается causal broadcast в разных вариантах.



В качестве примера op-based CRDT предлагаются evenuate, swiftcloud и antidotedb.



По результатам обсуждения предыдущих видов CRDT, переходим к Delta-CRDT: требования такие же как у state-based, а размер — как у op-based. Реализует их Akka и Riak KV.



Все эти виды CRDT иллюстрируются на реальном примере типа GCounter (grow-only counter) и PNCounter (positive-negative counter) = GCounter + GCounter. Со счётчиками возникают проблемы, и конечно, тут нам понадобятся Riak Counters. Дальше на очереди — LWWRegister, Version Vector, MVRegister, GSet, 2PSet, OR-Set, AWMap. Всё это с подробным описанием.



Что это значит для меня? Имхо, CRDT — будущее распределённых систем. Область распределённых систем бурно развивается, и нужно поддерживать свои знания в ногу со временем, в частности читать пейперы и ходить на такие вот доклады. Ну и конечно, раз в Akka запилили delta CRDT, этот вопрос стоит изучить в первую очередь.



7. Java-инспекции в IntelliJ IDEA: что может пойти не так?



Спикер: Тагир Валеев; оценка: 4.33 ± 0.12. Ссылка на презентацию.





Для начала, надо понимать, что Тагир — это @lany, и он является живым воплощением хаба Java на Хабре.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017

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



А ещё, для проведения этого доклада пришлось пожертвовать Тагиру мой ноутбук. Он лучше всех работал с проектором, или что-то такое. Если присмотритесь к крышке ноута, увидите на нём единственную круглую наклейку "это Сбертех, детка!" — не самая очевидная наклейка для сотрудника JetBrains!



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Ладно, к делу. Доклад — про написание инспекций для Идеи.



Картинка-эпиграф к докладу: такую ошибку нормальная IDE точно помогла бы предотвратить.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



В Идее две тысячи инспекций, большинство из которых — поиск и замена.



Приводится пример хотелки пользователя Идеи, чтобы добавили трансформацию из



set.stream().collect(Collectors.toList())


в более разумный вид



new ArrayList<>(set)


Для тех кто в танке, Тагир поясняет, почему регулярки — не лучший способ решать эту задачу. Нельзя представлять код в виде набора символов, нужна более абстрактная модель, например, AST. Однако его в нормальной ситуации тоже не хватает. Хватает PSI (Program Structure Interface), который реализован в Идее.



С помощью примерно такого кода можно покрыть сразу целый класс эквивалентных записей:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



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



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Если писать правильно, то Идея будет автоматически добавлять пропущенные импорты и прочие ништяки (см. вызов shortenClassReferences). Кроме импортов, нормализовывать код можно множеством разных способов, например — автоматически удалив ненужные квалификаторы или приведения типов.



Следущий интересный пример — обработка комментариев. В старых инспекциях, после фикса они просто терялись, в новых — за этим стараются специально следить. Где это возможно, комментарии остаются на своём месте, но не всегда так можно сделать. Например, если мы сворачиваем цикл с удалением до list.removeIf, и в середине цикла были комментарии, то все они уползут наверх и появятся непосредственно над строчкой с вызовом list.removeIf.



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



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



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Следующие блоки — про дженерики и приведения типов. Как можно догадаться, проблем тут вагон.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



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



Лично мне этот доклад мне очень полезен, потому что написание инспеций для Идеи — одна из вещей, которые в обязательном порядке буду делать. Зачем это нужно маркетологу — сейчас объяснять не буду, про это будет отдельная статья.



6. Analyzing HotSpot Crashes



Спикер: Volker Simonis; оценка: 4.35 ± 0.14. Ссылка на презентацию.





Фолькер — это товарищ из SAP, систематически рассказывающий всякую жесть о том, как чинить Java, если её вы намерены использовать её так же жестоко, как у него на работе. Обычно там происходит кровь-кишки-расчленёнка, отладка падающих JVM, путешествия по дебрям кода на C++ и ассемблере, и так далее.



Этот доклад не исключение:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Доклад начинается с обзора структуры HotSpot VM



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Фолькер как бы намекает, что при починке нам потребуется копаться в этом всём. По сути, это такая фуллстек задача, где наш "стек" — это кишки JVM. Задача делится на две основные части: понять, в какой части стека случилась ошибка, и затем, используя наши знания об этой части, нужно починить ошибку.



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



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



Если кому-то интересно, как можно быстро скрашить JVM:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Важно, что Фолькер показывает свои примеры весьма схематично. Зачастую, недостаточно просто скопипастить код, нужно немного подумать. Например, настоящий код из этого краша (только что проверил) должен выглядеть как-то так:



import sun.misc.Unsafe;

import java.lang.reflect.Field;

public class Main {

    public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException, ClassNotFoundException {
        Class<?> c = Class.forName("sun.misc.Unsafe", false, Main.class.getClassLoader());
        Field theUnsafe = c.getDeclaredField("theUnsafe");
        theUnsafe.setAccessible(true);
        Unsafe u = (Unsafe) theUnsafe.get(null);
        u.putInt(0x99, 0x42);
    }
}


Напоровшись на грабли, мы, вслед за Фолькером, яростно штудируем логи падения виртуалки:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Роемся в регистрах и стеке:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Обсуждаем генерирование hs_err.log и то, что с ним всё непросто:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Исследуем места падения:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



И так далее.



Например, покрашиться можно в интерпретаторе, но при этом не обязательно что это как-то связано с самим интерпретатором. Возможно, у нас просто поломался хип. Или вот например, можно таким способом отлаживать Out of Memory (нужно копаться, начиная с флага -XX:+CrashOnOutOfMemoryError и соответствующего лога).



Для меня ценность этого доклада в том, что он даёт конкретный набор ручек, за которые можно ухватиться. Как конкретно смотреть дизассемблер, что прописывать в опции VM, как использовать Serviceability Agent, как использовать replay-файлы, и так далее. Что ещё более важно, можно посмотреть за ходом мыслей Фолькера и попытаться научиться думать похожим образом.



Конечно, не каждый день у тебя падает JVM, и ещё меньше шансы того, что ты сможешь починить такой баг (элементарно, у тебя может не быть столько времени, чтобы днями напролёт ползать по логам). Обычно такие баги репортят и ждут, пока их починят профессионалы. С другой стороны, зная вещи, о которых говорит Фолькер, можно не дожидаясь фикса придумать какой-то хитрый воркэраунд (не на уровне починки самой JVM, а на уровне лёгкого рефакторинга своего кода на Java).



И с третьей стороны, если ты сам роешься в кишках JVM с целью проведения экспериментов, шанс что ты что-то разломаешь в пыль резко растёт. Плюс, если ты роешься в ещё не выпущенной джаве, можно наткнуться на такие проблемы, которые прямо сейчас, вынь да положь, решать тебе никто не будет. Как говорится, in open source no one can hear your scream. Это вряд ли можно считать самым распространённым способом использования полученных из этого доклада знаний, но если честно, вот это для меня — основное.



5. Kafka льёт, а Spark разгребает!



Спикер: Алексей Зиновьев; оценка: 4.38 ± 0.19. Ссылка на презентацию.





Вначале дается вводная про Спарк и его место в современном мире.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



В этом докладе будет фокус на Spark Streaming и Kafka. Сейчас есть запрос не столько на батчевую обработку, сколько на риалтайм, и на это нужно реагировать.



Основные поинты доклада:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Забавно, что в докладе присутствует код как на Java, так и на Scala. Алексей честно признается, что он не супер специалист в Scala, но иногда использовать её приходится.



Те, у кого загорелось одно место от слова "real-time" применительно к бигдате, сразу есть оговорка, что у нас под риалтаймом будет пониматься что-то, способное выдать ответ за приемлемое время.



Алексей рассказывает состояние бигдаты в прошлом, когда люди просто лопатили большие куски батчами. О том, что во-многом всё это было завязано на отчёты, и модным было строить отчёты поверх Кассандры и Монги. Типичные джобы выполнялись от 5 до 50 часов.



В 2017 году люди скорей хотят что-то вычислять на лету в режиме скользящего окна. Приложение не обязательно супер высоконагруженное, и приходящие миллиарды ивентов не обязательно отображать, но нужно учесть и как-то их агрегировать. А ещё сейчас лютый хайп вокруг машинного обучения (и в этом плане хочется переобучать модели, гасить эффект от прошлых моделей, итп — короче, нужно интегрировать машинное обучение с риалтаймом). Ещё есть идея о data lake, но она не работает :-)



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



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



Следующий шаг — использование Кассандры. Там всё в памяти, всё круто быстро работает, итп. И главное сделать достаточно несложно — просто льём логи не на диск, а в Кассандру.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Более того, есть коннекторы на cassandra to spark. Но с этим решением есть некоторые проблемы, в которых рассказывается в докладе.



Поэтому мы возвращаемся к старому механизму, отправке сообщений. Publish-subscribe, топики, итп. Но проблема в том, что JMS не очень хорошо масштабируется в ширину, да и хочется очередь, которая поддерживает всё и сразу — и point to point, и publish-subscribe, и распределенная была, и чтобы fault tolerance, итп.



Так мы приходим к Kafka. С Кафкой нам приезжают два важных преимущетва: масштабирование без даунтайма и отсутствие потерь данных при репликации.



Далее Алексей рассказывает терминологию и основы работы Кафки, зачем нужен Zookeeper.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



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



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



После этого мы переходим на второй Спарк и обсуждаем его новое API.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



И от этого переходим к концепции бесконечной таблицы. И ко всему этому можно посмотреть веб-интерфейс, посмотреть длительность всех операций, и так далее. Проводится демка "многопоточного задалбывателя Кафки" ©, на выходе печатающего в консоль. В этом месте Алексей окончательно переходит на Скалу.



Но вывод в консоль — это неинтересно, а хочется кучу разных других операций: filter, sort, aggregate, join, foreach, explain, итп. Для этого тоже есть демка.



Дальше мы уходим совсем вглубь и рассматриваем потроха Спарка, смотрим Explain, итп:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Глобальная картина всего:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



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



Уф, кажется, по большинству упомянутых тем пробежал. Конечно, демки и обсуждения я тут даже не затрагивал — а ведь это самая главная часть доклада. Короче, смотрите доклад.



Чем этот доклад полезен для меня? Понятно, что вот прямо сейчас я не рванусь писать бигдату, да и нет у меня никакой "биг" даты. С другой стороны, если такая задача всё же подвернётся — можно будет посмотреть на картину эволюции прошлых лет, описанную Алексеем, и сразу начать с современных решений, а не городить свои заранее устаревшие велосипеды. Ну и переливание из Кафки в Кафку — огонь идея.



4. Техники векторизации кода в JVM



Спикер: Владимир Иванов; оценка: 4.47 ± 0.11. Ссылка на презентацию.





Вопрос залу: "кто знает, что такое векторизация?"



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Судя по лесу рук, сидящим в зале этот час покажется вечностью :-) Вкратце, вот о чём будет доклад:



Основная тема доклада — OpenJDK, автовекторизация в нём, интринсики которые выигрывают от векторизации, и под конец — немного о будущем.



12 лет назад началась новая эра: мир начал всерьез задумываться о параллелизации. Throughput однопоточных приложений почти не растёт. Можно добавить серверов, ядер, использовать специальные инструкции. Все современные процы умеют SIMD. Рассматривается, как это выглядит на x86: широкие регистры, инструкции над пакованными векторами, итп.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Обсуждаются техники векторизации: автоматическая, полу-автоматическая, или напрямую работать с инструкциями (low-level представлениями).



По набору инструкций есть проблема обратной совместимости. Можно код написать сразу на нескольких разных наборах инструкций (надо автоматически определять, что доступно). Anger Fog нга эту тему доказывал, что расходы на это невероятно большие, плюс есть огромный список проблем. JVM в этом смысле в привелигированном положении, так как байткод переносимый, и JVM всё знает о машине, на которой запускается.



В хотспоте есть куча уже готовых SIMD инструкций, может делать автоматическую векторизацию, и есть соответствующие интринсики типа копирования массивов. Обсуждается алгоритм -XX:+UseSuperWord, и что такие оптимизации работают только над счётными циклами.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Показываются опции для проверки этого (-XX:+PrintCompilation, -XX:+TraceLoopOpts) или можно просто сделать -XX:+PrintAssembly и вычитать всё это глазами. Приводится большое количество примеров циклов, и аудитории предлагается сказать — являются ли они оптимизируемыми. Показывается в ассемблере как выглядят развёрнутые циклы, и как их можно случайно поломать. Обсуждается, почему именно такой код генерится, и как это связано с выравниванием.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



По ходу дела рассматриваются разные способы ускорения типа Fused Operations, всё это в контексте разного нижележащего железа и версии JDK. Ну и AVX-512, увеличивший в 10 раз количество инструкций на x86.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Под конец упоминаются интринсики: System.arraycopy, Arrays.copyOf, и начиная с Девятки: Arrays.mismatch, ArraysSupport.vectorizedMismatch.



Подводятся итоги того, в каком состоянии находится экосистема Java относительно использования SIMD в 2017 году. И из этого напрямую делается вывод о необходимости проекта Panama, в котором происходит разработка векторных API. Подробно рассказывается о проекте: о текущем статусе, проблемах, перспективах и связи с другими проектами в OpenJDK.



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Для меня этот доклад важен тем, что даёт понимание текущего статуса одного из самых перспективных направлений разработки JVM. Если бы я мог взять и вбухать всё своё свободное и рабочее время в какой-то из проектов OpenJDK, эта тема была бы, пожалуй, на самой вершине (но сразу после Graal & Truffle, которых вышибить с первого места невозможно).



3. Перформанс: Что В Имени Тебе Моём?



Спикер: Алексей Шипилёв; оценка: 4.47 ± 0.06. Ссылка на презентацию.





Так получилось, что в топе у нас есть всего два доклада, которые были одновременно и на JPoint, и на JBreak. И оба эти доклада сделаны Лёшей.



Этот доклад рассматривался вчера, в предыдущей статье о лучших докладах JPoint 2017. По второму разу его описывать не буду, переходите по ссылке.



2. Java 9 Модули. Почему не OSGi?



Спикер: Никита Липский; оценка: 4.60 ± 0.06. Ссылка на презентацию.





Как следует из названия, разговор будет целиком о модулях и об OSGi. Для тех кто ещё не в курсе (т.е. посмотрел недостаточно докладов JUG.ru), Никита Липский — это разработчик совершенно самостоятельной реализации Java Excelsior JET, пилит её более 17 лет (то есть стоял у истоков Java вообще), является идейным вдохновителем проекта и практикующим компиляторщиком. То есть, входит в очень небольшой круг людей, которые не просто смотрят и имплементят результаты чьей-то архитектурной работы, а активно в ней участвует. Это конечно, не Mark Reinhold (большинство из нас всё-таки используют OpenJDK, а не JET, поэтому его мнение было бы более в кассу), но уже близко к тому.



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



Вначале даётся вводная о стандартном вопросе обычного разработчика: зачем мне модули, если уже есть Maven и OSGi. Если с Maven всё более-менее понятно (например, клеш версий зависимостей, который мы чиним из года в год), то с OSGi всё мутней.



На Нацлидер скажет в этом месте что-то вроде такого:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Тут некоторые люди сразу оказались по обе стороны баррикады: как исследователям OpenJDK, этот аргумент, безусловно катит. Но как конечным пользователям нам в общем-то насрать — главное чтобы OpenJDK работало, а как будут мучиться его корные разрабы и исследователи — ССЗБ (сами себе злобные бараны).



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



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Дальше подробно разбираются проблемы OSGi. Всё это иллюстрируется диаграммами, типа вот этой схемы версионирования:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Мы проходимся по модульности, обновлениям на лету (помним, что нельзя так просто взять и выгрузить класс, classloader memory leaks, вот это всё). Проблемы с версионированием и то, что OSGi никак не помогает избежать нарушения loading constraints (погуглите по слову "LinkageError" чтобы оценить масштаб проблемы). Иначе говоря, чтобы избежать этой проблемы, существует единственное решение — не использовать внутри программы библиотеку двух разных версий. Это развенчивает миф о том, что OSGi эту проблему, якобы, решает.



Но самое ужасное в другом. У JVM по стандарту не определён порядок загрузки. Разные JVM (или одна, но с разными настройками), могут загружать их либо лениво (ссылки разрешаются при первом доступе), либо энергично (сразу разрешаются все доступные ссылки). OSGi не работает с энергичной загрузкой! Он работает только по тому чудесному стечению обстоятельств, что в HotSpot по-умолчанию сделана ленивая подгрузка. Но по сути, это мина замедленного действия — однажды в OpenJDK порядок загрузки классов изменится, и всё сломается. Это ужас-ужас, особенно учитывая, что такие работы уже ведутся (привет, Graal & Truffle!).



Я тут описываю упрощённо, и если интересны детали (и если вам кажется, что в этой аргументации есть изъяны) — обязательно читайте доклад. Кстати, Никита присутствует на Хабре @pjbooms и может быть, если система оповещения Хабра опять не заглючит, увидит ваши комментарии и что-нибудь ответит.



С другой стороны, в Jigsaw изначально думали над разными способами использования, и в этом плане там всё очень хорошо. Обсуждается "мантра Jigsaw": "reliable configruation + strong encapsulation", и её реализация в текущих реалиях, и делается некое заключение:



Что посмотреть на выходных? Обзор лучших докладов в свободном доступе. Часть вторая, JBreak 2017



Ну и потом десять минут вопросов, конечно.



Чем этот доклад оказался полезен лично для меня? Да всем. Это один из тех редких докладов, который как бы и про advanced топик на тему работы JVM, и must have при проектировании и реализации почти любого приложения чуть больше хэлловорлда. Если взять самый-самый глобальный вывод для себя: на OSGi смотреть с опаской и самостоятельно не использовать (чем более low level проект, чем больше там хаков — тем сильней станов

Источник: Хабрахабр

Категория: Программирование » Веб-разработка

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *