Comments 7

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

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

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

IMHO поиск у GitHub никуда не годится.
Как правило гораздо продуктивнее пойти на google.com и найти то, что нужно, используя «site:github.com».
Что-то мне подсказывает, что пункт 2.2 должен называться «Профилирование: слабые стороны AsyncGetCallTrace»…

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


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

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

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

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

Only those users with full accounts are able to leave comments. Log in, please.