JBreak 2017

Оптимизация производительности бередит умы опытных разработчиков с начала компьютерных времён. В коллективном бессознательном оптимизация — это то, что делает программирование интересным, конференции раскупаемыми, личный послужной лист — золотым. В этом обзорном докладе мы поговорим об оптимизации больших/инфраструктурных проектов (к примеру, OpenJDK): общих принципах, тенденциях и соотношениях; жизненном цикле проекта и экономике оптимизаций; роли и жизненном цикле тестов производительности; типичных ловушках, разногласиях и противоречиях, в которых оказываются оптимизационные задачи в крупных проектах.

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

Сегодня только очень ленивый разработчик не пробовал Spring Boot. Всем хочется быть на коне и во всеоружии. Мы писали Spring приложения, теперь Spring Boot. Мы тестировали Spring приложения, а теперь тестируем… ну, вы поняли.

Чем проще инструмент, тем больше магии он делает «под капотом». Spring Boot не исключение. Более того, мало кто задумывается, что происходит при использовании привычных всем инструментов, описанных в документации Spring Test.

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

Did you ever found hs_err_pid or replay_pid files in your Java application directory? Did your Java application ever crash and you didn't know why? This talk will unveil the contents stored by the HotSpot crash handler into the corresponding error files and how this information can be used to analyze and reproduce the crash. It will also introduce tools like the HotSpot Serviceability Agent which helps to introspect native core files and extract the relevant Java information from them which is otherwise not easily accessible by native debuggers.

Вы из тех, кто гонится за производительностью, запихивая в любой цикл Collection.parallelStream()? Задумываетесь, как обойтись без глобальной переделки кода и решить все проблемы с помощью большего количества серверов? Как получить распределённую обработку с линейным ростом производительности? Если подобные вопросы звучат у вас в голове, тогда этот доклад для вас. Оказывается, лишь немногие могут запускать Streams в распределенном режиме — Oracle Coherence, Infinispan, Hazelcast Jet — кто-то за деньги, кто-то бесплатно. На примере Hazelcast Jet Виктор расскажет обо всех деталях распределённой обработки. Кроме того, познакомит слушателей со своим другом Ориентированным Ациклическим Графом и покажет, как с его помощью организована обработка информации поверх API Java 8 Stream. Распределенная! Высокопроизводительная! «В памяти»!

У каждого современного процессора присутствует «джентльменский набор» векторных инструкций (SIMD) для параллельной обработки данных: множество версий SSE и AVX на x86/x64, VIS на SPARC, NEON в ARM, AltiVec в Power. Такое многообразие не лучшим образом сказывается на удобстве использования. Существует множество нюансов в работе даже в рамках одной платформы, не говоря уже о кросс-платформенном случае. Разговор пойдёт о том, как сейчас выглядят векторные расширения процессора и на какие ухищрения приходится идти JVM, чтобы не давать им простаивать: CPU dispatching, VM intrinsic’и, автоматическая векторизация байт-кода в JIT-компиляторах. Будет упомянут и специализированный векторный API (Vector API), работы над которым активно ведутся в Project Panama.

Java — очень удобная, быстрая и современная платформа. Но не все об этом знают. В эпоху стремительно развивающихся платформ вроде Golang или Node.js может показаться, что Java остаётся позади — во временах толстых, медленных, и (что особенно важно) необычайно сложно поддерживаемых чудовищ.

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

Это доклад о том, как наличие DevOps помогает улучшать не только Mean Time To Repair, но и поддерживать общее здоровье проекта. О том, что зачастую недостаточно сказать админу «настройка-ка мне application server». Возможно, его нужно не настроить, а написать с нуля.

IntelliJ IDEA постоянно подчёркивает ваш код, предлагая заменить его на что-нибудь получше. Иногда результаты кажутся просто волшебными. Как IDE это делает? Как разбирается в вашем коде, как генерирует новый код на замену старого и какие тут есть подводные камни?

Мы посмотрим, из чего состоит типичная инспекция кода в IntelliJ IDEA и сколько седых волос появляется у разработчиков IDE ради того, чтобы вы могли одним нажатием улучшить свой код.

Дедлоки – одна из наиболее актуальных проблем при разработке многопоточных приложений. В рамках этого доклада будет рассмотрен инструмент Dl-Check, используемый для поиска потенциальных дедлоков. В ходе разработки подобного инструмента не обойтись без инструментации байт-кода, для реализации которого стандартом де-факто является фреймворк ASM. В первой части доклада будет представлен основной алгоритм указанного инструмента, который позволяет эффективно находить потенциальные дедлоки в процессе работы приложения. Вторая часть доклада будет посвящена инструментации байт-кода, а также полезным техникам и нетривиальным проблемам, связанным с ней.

As Java developers, we take strings for granted. They're everywhere, in every API, and in almost all interaction with systems outside the JVM. But Java's implementation of String is not without its problems. In this talk we'll explore how String is implemented and walk through some uncommon use cases. We will discuss some of the shortcomings of String and how alternative languages have addressed similar challenges. And we'll take a tour of some unusual libraries that provide an alternative representation of strings you might find useful.

Одна из главных проблем больших Java-приложений — это cбо... рка мусо... ра. Хранение больших куч данных, активно фрагментирующие приложения и прочие выпадающие из гипотезы о поколениях нагрузки приносят ещё больше проблем. Промышленные GC давно решили первую большую часть проблемы сборки, concurrent marking — выяснение графа объектов без долгой остановки приложения. Shenandoah — новый сборщик мусора, который пытается решить вторую большую часть головоломки, а именно перемещение объектов без остановки приложения, тем самым сбивая паузы ещё больше. Этот доклад об особенностях дизайна и реализации Shenandoah, достоинствах, которыми можно гордиться, и недостатках, с которыми приходится мириться.

Как техника в Java и многих других объектно-ориентированных языках, utility-классы очень удобны для предоставления доступа к популярным процедурам из разных мест кода. Тысячи таких классов и процедур можно найти в Apache Commons, Guava и в JDK. Однако, действительно ли этот подход можно назвать объектно-ориентированным и делают ли utility-классы наш код чище и понятнее? Нужны ли нам эти процедуры в ООП? Если не нужны, то какая альтернатива? Как в Java мы можем повторно использовать код без utility-классов?

Использовать Hadoop/Spark как средство построения отчётов умеют многие, но последнее время всё больше и больше клиентов хотят обработки больших потоков данных в режиме real-time (а не просто сохранять их в S3 или Cassandra для будущих отчётов, на построение которых уходят часы). В типичном ТЗ по real-time аналитике часто имеются пункты о том, что необходимо подсчитывать «на лету» некоторые агрегированные величины за небольшой период времени, фильтровать поток, уменьшая нагрузку на последующие стадии вычислений. Достаточно часто мы можем видеть проекты, где команды организуют своё «озерцо данных» в Amazon, просто сваливая все приходящие ивенты в Kafka. Справится ли Spark с потоками из Kafka? А если справится, то какой ценой и что ему в этом поможет? Не ждите на докладе введения в Spark, RDD, разговоров за Big Data. Один кейс — одно решение — немного теории — правим конфиги — пишем код.

Несколько дата-центров с асинхронной репликацией и отсутствием координации; доступность и корректная работа в условиях сетевой сегментации; молниеносный отклик на клиенте и оптимистичный UI; офлайн-режим работы в браузере или на смартфоне. Всё это звучит круто, не правда ли? Немногие приложения сегодня могут похвастаться таким набором возможностей. Причина в том, что всё это может привести к конкурентным изменениям, а конкурентные изменения приводят к конфликтам… И вот вы уже пишете свой conflict resolver на timestamp’ах. А будет ли ваш conflict resolver работать правильно? Скорее всего, нет. Научное сообщество придумало решение проблемы — CRDT (Conflict-free replicated datatypes). В своем докладе Андрей покажет почему простейшие conflict resolver’s не работают на конкретном примере, а потом расскажет про CRDT. Слушатели узнают о различных видах CRDT, их преимуществах и недостатках. Доклад также коснётся границ применимости CRDT. В конце доклада Андрей рассмотрит несколько баз данных с поддержкой CRDT, для того, чтобы вы знали, какую БД выбрать для вашего следующего проекта. Или, может быть, задумались о написании своей собственной…

Today’s applications are expected to provide powerful full-text search. But how does that work in general and how do I implement it on my site or in my application?

Actually, this is not as hard as it sounds at first. This talk covers:

How full-text search works in general and what the differences to databases are.

How the score or quality of a search result is calculated.

How to implement this with Elasticsearch.

Attendees will learn how to add common search patterns to their applications without breaking a sweat.

В Java 9 с неизбежностью появятся модули. Кого-то это мало волнует, кого-то пугает, кто-то искренне недоумевает: зачем, ведь у нас уже больше 15 лет есть OSGi, который решает ровно те же проблемы, что и модули? В этом докладе Никита попробует разобраться, какие проблемы пытается решить OSGi, как он их решает и решает ли в действительности. Затем обсудит, какие проблемы, которые пытается решить OSGi, Jigsaw совсем не решает и почему, а также какие проблемы решает и как. Ну и на конец доклада: какие проблемы Jigsaw при этом привносит в экосистему Java и что с этим делать.