Как стать автором
Обновить
170
0
Андрей @apangin

Пользователь

Отправить сообщение

для более коротких пауз используйте LockSupport.parkNanos();

На самом деле, зависит от ОС. На Windows всё наоборот: минимальный интервал сна (1мс) достигается именно Thread.sleep, а LockSupport.parkNanos при любом положительном аргументе засыпает минимум на 3.9мс (1/256 секунды). Такая вот особенность реализации.

То, что EliminateAutoBox оптимизация здесь сработала, скорее, повезло. Она чаще не работает, чем работает :) Даже на свежайшей JDK 17-ea простой пример отсюда (setPrimitive) по-прежнему аллоцирует лишний объект.

Зато если вместо автобоксинга написать new Integer(i), то сразу всё хорошо оптимизируется. На этом фоне очень обидно, что конструкторы обёрток задеприкейтили, не предоставив сопоставимую по скорости альтернативу :(
Не очень понял, в чём проблема. Да, async-profiler может собирать профиль в нескольких форматах, которые потом можно объединять, фильтровать и анализировать на любой другой машине.
  • collapsed — простейший текстовый формат, который тривиально парсить и фильтровать хоть grep'ом;
  • jfr — бинарный формат, совместимый с Java Flight Recorder. Его можно открывать в Mission Control и там уже по-всякому анализировать: по классам, пакетам, потокам, временным интервалам и т. д.

В обоих этих форматах можно объединить несколько профилей простой конкатенацией файлов.
Без проблем — пользуйтесь, чем нравится. Я, скорее, для себя понять, какие востребованные фичи можно было бы добавить в async-profiler. Просто пока всё, что вы перечислили, в нём тоже есть :)

Через функцию Search можно так же подсветить фрейм во всех стеках и увидеть суммарный процент. А начиная с версии 1.8, async-profiler умеет генерировать HTML Flame Graph (на основе Canvas) — такой граф рендерится в десятки раз быстрее, чем svg.
Достоинств по сравнению с чем?
Упомянутый в статье async-profiler тоже не требует дополнительных флагов JVM, вносит меньший оверхед при профилирования в проде, тоже сам генерирует flame graph без сторонних перл-скриптов, но при этом показывает нативные стеки и стеки ядра. Но главное, лишён проблемы safepoint bias.
В JEP 371 всё же написано. Никакой магии. На самом деле, почти для всего, для чего сейчас используется динамическая кодогенерация (всевозможные прокси, лямбды, обёртки, фильтры и скомпилированные выражения), лучше подходят именно hidden classes, потому что 1) они по смыслу анонимные; 2) их хорошо бы уметь собирать независимо от ClassLoader'а; 3) им зачастую требуется приватный доступ к контексту, в рамках которого динамический класс генерируется.

Подобная функциональность была доступна давно в виде недокументированного метода Unsafe.defineAnonymousClass. Теперь на смену неофициальному API приходит стандартный поддерживаемый.
Обычно так и делаю. Но в данном случае речь не о нескольких неточностях, а о том, что вся статья выглядит как машинный перевод без какого-либо контекста предметной области. Улучшить её можно, только написав заново с нуля Java специалистом.
Пожалуйста, не переводите больше технические статьи, смысла которых не понимаете. У Google Translate и то качественнее получается.

Deprecate for Removal — это не «исключение при удалении»
Uncondended locking — это не «неконтролируемая блокировка»
Sealed Classes — это не «изолированные классы»
и т. д.
21455 получил. Пожалуй, на этом пора остановиться.
Ещё пара трюков, и вот уже 21391 константа: LargeEnum.class. Можно ли больше?
Можно построить валидный enum из 21200 констант, причём средствами чистой Java 5, безо всяких Unsafe и ConstantDynamic. Пруф.

Довольно интересная задача. Когда вы в прошлой части упомянули теоретический максимум в ~21K элементов, я ожидал в этой части увидеть, как вы его будете достигать ¯\_(ツ)_/¯
Портировано, но позже. Во время событий, описанных в статье, Shenandoah 2.0 в JDK 8 ещё не было. Да и не вечно же сидеть на восьмёрке.
Связано. В JDK 13 Shenandoah GC претерпел существенные изменения; его даже иногда называют Shenandoah 2.0. В частности, была пересмотрена модель барьеров: ушли от дорогих read barriers в пользу load reference barriers, а также отказались от forwarding pointers — дополнительного слота в хипе перед заголовком каждого объекта.
Спасибо за подробную статью! Было приятно увидеть one-nio в топе.

Хочу отметить, что компактный вариант сериализации изначально задумывался для быстрого RPC с поддержкой эволюции классов. При этом не требуется передавать схемы вручную: главная фишка one-nio — в динамическом обмене схемами между клиентом и сервером. Это работает из коробки в RpcClient/RpcServer из той же библиотеки.

Хотел узнать, почему в таблице отмечена невозможность десериализовать классы, отсутствующие в classpath? Для отсутствующих классов one-nio автоматически генерирует классы-заглушки, и это неотъемлемая часть процедуры обмена схемами.
Что починили? Если вы про JEP 351, то эта фича вообще о другом.
Казалось бы — делать нечего, будем ждать, пока в Oracle все допилят
Долго ждать бы пришлось… Как Oracle узнает, что у вас есть проблема с ZGC? Вы им репортили? И почему вы решили, что это бага в ZGC, а не в настройках/версии ОС?

ZGC использует технику colored pointers и multi-mapping. Это значит, что один и тот же диапазон физической памяти отображается в несколько виртуальных диапазонов, из-за чего Linux криво считает RSS процесса. Так что очень вероятно, что это не «процесс java израсходовал всю доступную память», а вы его не так «приготовили».

Статья называется «опыт использования», а по факту вижу: включили -> с первого раза не заработало -> выключили. И в чём тут опыт? Был бы интересен хоть какой-то минимальный анализ, что же пошло не так.
Начиная с Java 11 однофайловые программы можно запускать сразу без javac:
java C:\path\to\HelloWorld.java
Первоначальная задумка была как раз исправить, но было бы уже многовато задач на написание кода для такого формата. Впрочем, несколько участников всё равно написали свой вариант с summaryStatistics(), получив в итоге полный балл за задачу.
Здесь, как и с бенчмарками, работает правило: измеренные значения в отсутствие теоретического обоснования не говорят ни о чём. Более того, цифры могут врать, и здесь как раз такой случай.

Как иначе объяснить, что объекты Class (кроме примитивных) занимали так много в JDK 8, но внезапно уменьшились в разы в JDK 9+? А дело в том, что метод, которым вы пользовались для измерения, злостно врал в JDK 8, а в JDK 9 ошибку исправили.
У меня была такая же проблема — пофиксил сам.
Добавьте в idea64.vmoptions строчку
-XX:-SplitIfBlocks

Подробности в youtrack.jetbrains.com/issue/JBR-1596

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Работает в
Зарегистрирован
Активность