для более коротких пауз используйте 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 — это не «изолированные классы»
и т. д.
Можно построить валидный enum из 21200 констант, причём средствами чистой Java 5, безо всяких Unsafe и ConstantDynamic. Пруф.
Довольно интересная задача. Когда вы в прошлой части упомянули теоретический максимум в ~21K элементов, я ожидал в этой части увидеть, как вы его будете достигать ¯\_(ツ)_/¯
Связано. В JDK 13 Shenandoah GC претерпел существенные изменения; его даже иногда называют Shenandoah 2.0. В частности, была пересмотрена модель барьеров: ушли от дорогих read barriers в пользу load reference barriers, а также отказались от forwarding pointers — дополнительного слота в хипе перед заголовком каждого объекта.
Спасибо за подробную статью! Было приятно увидеть one-nio в топе.
Хочу отметить, что компактный вариант сериализации изначально задумывался для быстрого RPC с поддержкой эволюции классов. При этом не требуется передавать схемы вручную: главная фишка one-nio — в динамическом обмене схемами между клиентом и сервером. Это работает из коробки в RpcClient/RpcServer из той же библиотеки.
Хотел узнать, почему в таблице отмечена невозможность десериализовать классы, отсутствующие в classpath? Для отсутствующих классов one-nio автоматически генерирует классы-заглушки, и это неотъемлемая часть процедуры обмена схемами.
Казалось бы — делать нечего, будем ждать, пока в Oracle все допилят
Долго ждать бы пришлось… Как Oracle узнает, что у вас есть проблема с ZGC? Вы им репортили? И почему вы решили, что это бага в ZGC, а не в настройках/версии ОС?
ZGC использует технику colored pointers и multi-mapping. Это значит, что один и тот же диапазон физической памяти отображается в несколько виртуальных диапазонов, из-за чего Linux криво считает RSS процесса. Так что очень вероятно, что это не «процесс java израсходовал всю доступную память», а вы его не так «приготовили».
Статья называется «опыт использования», а по факту вижу: включили -> с первого раза не заработало -> выключили. И в чём тут опыт? Был бы интересен хоть какой-то минимальный анализ, что же пошло не так.
Первоначальная задумка была как раз исправить, но было бы уже многовато задач на написание кода для такого формата. Впрочем, несколько участников всё равно написали свой вариант с summaryStatistics(), получив в итоге полный балл за задачу.
Здесь, как и с бенчмарками, работает правило: измеренные значения в отсутствие теоретического обоснования не говорят ни о чём. Более того, цифры могут врать, и здесь как раз такой случай.
Как иначе объяснить, что объекты Class (кроме примитивных) занимали так много в JDK 8, но внезапно уменьшились в разы в JDK 9+? А дело в том, что метод, которым вы пользовались для измерения, злостно врал в JDK 8, а в JDK 9 ошибку исправили.
На самом деле, зависит от ОС. На Windows всё наоборот: минимальный интервал сна (1мс) достигается именно
Thread.sleep
, аLockSupport.parkNanos
при любом положительном аргументе засыпает минимум на 3.9мс (1/256 секунды). Такая вот особенность реализации.EliminateAutoBox
оптимизация здесь сработала, скорее, повезло. Она чаще не работает, чем работает :) Даже на свежайшей JDK 17-ea простой пример отсюда (setPrimitive) по-прежнему аллоцирует лишний объект.Зато если вместо автобоксинга написать
new Integer(i)
, то сразу всё хорошо оптимизируется. На этом фоне очень обидно, что конструкторы обёрток задеприкейтили, не предоставив сопоставимую по скорости альтернативу :(В обоих этих форматах можно объединить несколько профилей простой конкатенацией файлов.
Через функцию Search можно так же подсветить фрейм во всех стеках и увидеть суммарный процент. А начиная с версии 1.8, async-profiler умеет генерировать HTML Flame Graph (на основе Canvas) — такой граф рендерится в десятки раз быстрее, чем svg.
Упомянутый в статье async-profiler тоже не требует дополнительных флагов JVM, вносит меньший оверхед при профилирования в проде, тоже сам генерирует flame graph без сторонних перл-скриптов, но при этом показывает нативные стеки и стеки ядра. Но главное, лишён проблемы safepoint bias.
Подобная функциональность была доступна давно в виде недокументированного метода Unsafe.defineAnonymousClass. Теперь на смену неофициальному API приходит стандартный поддерживаемый.
Deprecate for Removal — это не «исключение при удалении»
Uncondended locking — это не «неконтролируемая блокировка»
Sealed Classes — это не «изолированные классы»
и т. д.
Довольно интересная задача. Когда вы в прошлой части упомянули теоретический максимум в ~21K элементов, я ожидал в этой части увидеть, как вы его будете достигать ¯\_(ツ)_/¯
Хочу отметить, что компактный вариант сериализации изначально задумывался для быстрого RPC с поддержкой эволюции классов. При этом не требуется передавать схемы вручную: главная фишка one-nio — в динамическом обмене схемами между клиентом и сервером. Это работает из коробки в RpcClient/RpcServer из той же библиотеки.
Хотел узнать, почему в таблице отмечена невозможность десериализовать классы, отсутствующие в classpath? Для отсутствующих классов one-nio автоматически генерирует классы-заглушки, и это неотъемлемая часть процедуры обмена схемами.
ZGC использует технику colored pointers и multi-mapping. Это значит, что один и тот же диапазон физической памяти отображается в несколько виртуальных диапазонов, из-за чего Linux криво считает RSS процесса. Так что очень вероятно, что это не «процесс java израсходовал всю доступную память», а вы его не так «приготовили».
Статья называется «опыт использования», а по факту вижу: включили -> с первого раза не заработало -> выключили. И в чём тут опыт? Был бы интересен хоть какой-то минимальный анализ, что же пошло не так.
summaryStatistics()
, получив в итоге полный балл за задачу.Как иначе объяснить, что объекты Class (кроме примитивных) занимали так много в JDK 8, но внезапно уменьшились в разы в JDK 9+? А дело в том, что метод, которым вы пользовались для измерения, злостно врал в JDK 8, а в JDK 9 ошибку исправили.
Добавьте в
idea64.vmoptions
строчкуПодробности в youtrack.jetbrains.com/issue/JBR-1596