image

В этом выпуске


Microprofile: очередная попытка реанимации Java EE
— Заденет ли Brexit Java-разработчиков?
— Раскладываем по полочкам Java Memory Model
— Профилирование: слабые стороны AsyncGetCallTrace
… и многое другое


1. Новости


1.1. Microprofile

Ссылка 1: http://microprofile.io/
Ссылка 2: https://developer.ibm.com/wasdev/blog/2016/06/27/microprofile-announce/
Ссылка 3: http://middlewareblog.redhat.com/2016/06/27/microprofile-collaborating-to-bring-microservices-to-enterprise-java/
Ссылка 4: http://www.tomitribe.com/blog/2016/06/microprofile/

Java EE продолжает тонуть в хайпе микросервисов. Парни из IBM, RedHat и нескольких других компаний решили бросить ей спасательный круг, анонсировав инициативу MicroProfile.io. Задача — подогнать стандарты Java EE под современные тренды. Читай — натянуть Java EE на микросервисы. Причем в буквальном смысле. Например, предлагается чуть ли не стандартизировать максимальный размер джарника и время старта приложения. Что-то вроде «enlarge your ...», только наоборот.

Реакция на инициативу неоднозначна. Кто-то ехидничает:

Кто-то предлагает не тратить время на заведомо проигрышные идеи:

Мое мнение — инициатива, безусловно, хорошая. Но вся предыдущая история Java EE была про «стандарты ради стандартов». Удастся ли MicroPofile.io учесть ошибки прошлого, и переключиться на модель «стандарты для людей», покажет время.

Между тем, ситуация вокруг заморозки Java EE продолжает накаляться. Так, вышла очередная разжигающе-апокалиптическая статья, суть которой в двух словах «Oracle гады, все пропало». Публикацию недвусмысленно прокомментировал сам James Gosling:
I'd love to be able to say that this is bullshit, but it's tragically the opposite. Oracle is run by the highest IQ idiots I've ever met. They're torching Oracle, it's customers, and every company they've ever acquired. The one ray of light is that the core Java group has fared much better than EE.

Продолжаем следить за развитием событий.

1.2. BREXIT

Ссылка: http://www.ibtimes.co.uk/brexit-will-london-lose-its-fintech-crown-1567222

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

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

1.3. Анализируем GitHub

Ссылка: https://cloudplatform.googleblog.com/2016/06/GitHub-on-BigQuery-analyze-all-the-open-source-code.html

Ребята из Google залили публичные репозитории GitHub в свой движок BigQuery, и открыли к нему доступ всем желающим. Остается положить какие-то 300$ на счет, и вы легко сможете собирать всевозможную статистику по этому огромному датасету. Например, найти все использования пакета sun.misc :-)

image

Запросы рекомендуется составлять разумно, потому что 1.5Tb данных в BigQuery очень быстро превращают доллары в тыкву.

2. Почитать


2.1. Java Memory Model

Ссылка 1: http://shipilev.net/blog/2016/close-encounters-of-jmm-kind/
Ссылка 2: https://groups.google.com/d/msg/mechanical-sympathy/T0pNhJSkZWQ/zHDubWKUBwAJ

Модель памяти Java хорошо разжевана в бесчисленных статьях и докладах. Буквально несколько правил, которые надежно скрывают детали реализации JVM и железа. Но разработчики упорно пытаются выйти за границы этой элегантной модели, ошибочно полагая, что они уже достаточно хорошо разобрались в кишочках происходящего. Свербит. Зудит. Чешется. Отсюда растут ноги множества некорректных интерпретаций JMM. Одним не нужен volatile на x86, ибо TSO. Другие пустыми synchronized-блоками happens-before запиливают. Третьи кэши в память «флашают». Бороться с этим сложно, так как под рукой долгое время не было наглядных примеров, демонстрирующих ошибочность таких подходов и утверждений.

Алексей Шипилев проделал титанический труд, и собрал воедино огромное количество наглядных примеров неправильного толкования JMM. Да, прямо такие, где «реордеринги на TSO», и вот это все. Размеру статьи позавидовал бы и Лев Николаевич, но ее прочтение очень важно. В первую с точки зрения веры — после прочтения вы наконец поверите, что заигрывать с JMM не стоит.

Комметнарий Gil Tene по второй ссылке подводит жирную черту под всем вышесказанным.

2.2. Профилирование и AsyncGetCallTrace

Ссылка: http://psy-lob-saw.blogspot.ru/2016/06/the-pros-and-cons-of-agct.html

В последнее время идет много дискуссий вокруг метода AsyncGetCallTrace, который позволяет снять дамп потока, не требуя при этом остановки на safepoint. Например, на его основе построен Honest Profiler. В своем посте Нитсан показывает некоторые слабые стороны этого подхода. Например, невозможность отпрофилировать интринзики.

Думаю, в ближайшее время стандартом первой линии профилирования может стать связка JMC + Honest Profiler, так как они очень неплохо дополняют друга друга.

Вдогонку свежее видео с доклада Нитсана про профилирование:


2.3. Немного про JIT

Ссылка: https://www.infoq.com/articles/OpenJDK-HotSpot-What-the-JIT

Хорошая статья про особенностях работы JIT. Рассматриваются вопросы tiered compilation, деоптимизации, интринзиков, и т.д. Написана лайтово и интересно.

Кстати, есть в JVM одно решение, которое лично мне непонятно — почему code cache отделен от metaspace? Уже не раз натыкался на проблему, когда при активной работе класслоадеров приходится тюнить эти два параметра параллельно. В противном случае просто в какой-то момент отрубается компиляция. Одним metaspace никак нельзя обойтись было? Да и в целом по ощущениям, что metaspace, что code cache на данный момент достаточно слабо встроены в инфраструктуру GC. Например, можно легко получить переполнение code cache, хотя в metaspace болтаются никому ненужные класслоадеры.

2.4. Визуализация GC

Ссылка: http://mattwarren.org/2016/06/20/Visualising-the-dotNET-Garbage-Collector/

Matt Warren визуализировал работу GC в процессе работы приложения. Правда, не в Java, а в .NET :-) Но все равно интересно. Для Java что-нибудь подобное есть? И насколько возможно/удобно в Java получать нотификации о событиях GC?

3. Мудрость


3.1. Идеальный софт


3.2. Протоколы против имплементаций



4. Юмор


4.1. Что делать, если вы подняли инвестиции на IT-стартап?

Разумеется, нанять шеф-повара для кормления собак!
Честно говоря, смахивает на вирусную рекламу.

Предыдущие выпуски

#4 (06.06.2016 — 19.06.2016)
#3 (23.05.2016 — 05.06.2016)
#2 (09.05.2016 — 22.05.2016)
Поделиться с друзьями
-->

Комментарии (7)


  1. Scf
    04.07.2016 12:10
    -3

    Неоднозначино отношусь к JMM. happens-before и ограничения на параллельность исполнения — это, все, конечно хорошо. Но на практике все равно приходится думать в терминах процессорного кеша и memory fence, т.к. современный высокопроизводительный код использует sun.misc.Unsafe, который в JMM не упоминается.


    1. Scf
      04.07.2016 23:02
      +1

      Хотелось бы увидеть возражения по сути, а не минусы


  1. vedenin1980
    04.07.2016 12:17

    Ребята из Google залили публичные репозитории GitHub в свой движок BigQuery, и открыли к нему доступ всем желающим. Остается положить какие-то 300$ на счет, и вы легко сможете собирать всевозможную статистику по этому огромному датасету.

    Честно не понял большого смысла, ведь GitHub сам по себе предоставляет достаточно неплохой поиск (особенно расширенный поиск), плюс хороший механизм API. Разве что потребуется какой-то хитрый sql запрос, но почему-то вообще в голову не приходит ситуация когда за это стоило бы заплатить 300$. Хотя бесплатные запросы наверное могут быть полезны.


    1. Maccimo
      04.07.2016 19:57

      IMHO поиск у GitHub никуда не годится.
      Как правило гораздо продуктивнее пойти на google.com и найти то, что нужно, используя «site:github.com».


  1. shybovycha
    04.07.2016 12:24
    +1

    Что-то мне подсказывает, что пункт 2.2 должен называться «Профилирование: слабые стороны AsyncGetCallTrace»…


  1. Scf
    04.07.2016 12:48

    Странная статья у Шипилёва. Вот он рассматривает, что модель барьеров не подходит для анализа поведения программ:


    void observer() {
      r.r1 = y;
      r.r2 = x;
    }

    LoadLoad барьер где? Зачем валить на компилятор, микропроцессор самостоятельно может поменять эти инструкции местами.


  1. sunless
    05.07.2016 13:01

    > Визуализация GC. Для Java что-нибудь подобное есть?

    Полно. Каждый приличный профилятор включает подобный визуализатор. Самый. Я вот пользуюсь VisualVМ, есть в JMC. Есть полезный флаг -XX:+PrintGC, который переработали к 9ке в http://openjdk.java.net/jeps/271. Полученные логи можно и самостоятельно парсить, чтобы автоматизировать процесс.