На прошлой неделе случился релиз десятки — и хотя Graal был доступен и раньше, теперь он стал ещё доступней — Congratulations, you're running #Graal! — просто добавьте

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Что конкретно это может нам дать и где можно ожидать улучшений, и какие велосипеды надо начинать выпиливать?

Пример, который я буду рассматривать — частично надуманный, однако, основанный на реальных событиях.

Пока идёт горячее обсуждение быть или нет быть jigsaw в java 9 и в каком виде ему быть — не стоит забывать про полезняшки, которые несёт с собой девятка — и одна из них — повышение точности Clock.systemUTC() — JDK-8068730.

Что же было раньше ?

До java 8 был System.currentTimeMillis() и System.nanoTime(), и если первый давал wall clock время, но с миллисекундным разрешением, то второй даёт время с разрешением до наносекунд, но область применения ограничена измерением разности времён, причём в рамках одной jvm — и ни о каком использовании такой временной метки между разными машинами и быть не может.

Поэтому часто велосипедят свои precise timestamp дающие wall clock время с большим разрешением, чем у currentTimeMillis (используя jni со всеми вытекающими) — более подробно про разницу между currentTimeMillis и nanoTime, и про велосипед можно почитать в моём старом посте.

Java 8 заложил очень мощный фундамент — Java Time API. С ним можно сказать пока и joda time, и встроить свой велосипед в java.time.Clock, т.к. штатный SystemClock по своей сути работает поверх System.currentTimeMillis() и не может обеспечить разрешение, лучше, чем миллисекунда.

И вот теперь в игру вступает java 9

RMarkdown, R и ggplot

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

Преамбула

Конференция это прежде всего доклады, и далеко не последнее место занимает то, как оформлены слайды доклада.

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

Пожалуй известные средства для создания слайдов это:

• PowerPoint, и вариации в лице LibreOffice Impress, Apple KeyNote
• облачные вариации с тем же подходом — Google Slides
• LaTeX
• и относительно новый (для меня) RMarkdown

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

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

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

Отработав в компании более 4х лет в нескольких смежных больших проектах я участвовал в собеседовании более чем 50 человек, из которых было нанято только 5.

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

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

Существует типичная проблема в большом классе задач, которая возникает при обработке потока сообщений:

— нельзя пропихнуть большого слона через маленькую трубу, или другими словами, обработка сообщений не успевает «проглотить» все сообщения.

При этом существуют некоторые ограничения на поток данных:

• поток не равномерный и состоит из событий разного типа
• количество типов событий заранее не известно, но некоторое конечное число
• каждый тип события имеет свою актуальность во времени
• все типы событий имеют равный приоритет

На диаграмме приведён пример разрешения проблемы: нагребатор(tm), работающий на нитке T₁, в то время как разгребатор(tm) работает на нитке T₂

• за время обработки события типа A успевают прийти новые события как типа B, так и A
• после обработки события типа B необходимо обработать наиболее актуальное событие типа A

Т.о. стоит задача о выполнении задач по ключу, так, что выполняется только самая актуальная из всех задач по данному ключу.

На суд публике представляется созданный нами ThrottlingExecutor.

Замечание терминологии: stream есть поток данных, тогда как thread есть нитка или нить выполнения. И не стоит путать потоки с нитками.

Замечание 1: проблема осложняется ещё тем, что может быть несколько нагребаторов(tm), при этом каждый нагребатор(tm) может порождать только события одного типа; с другой стороны есть потребность в нескольких (конечно же, для простоты можно выбрать N=1) разгребаторах(tm).

Замечание 2: мало того, что данный код должен работать в многопоточной (конкурентной) среде — т.е то самое множество нагребаторов(tm) — разгребаторов(tm), код должен работать с максимальной производительностью и низкими latency. Резонно к этим всем качествам добавить ещё и свойство garbage less.

И почти в каждом проекте так или иначе возникает эта задача, и каждый её решает по разному, но все они либо не эффективны, либо медленны, либо и то, и другое вместе взятое.