Performance optimization effective interaction with virtual machine

Оптимизация производительности:
эффективное взаимодействие с виртуальной
машиной
December 12, 2014 www.ExigenServices.com

2 www.ExigenServices.com
Цели тренинга
 Узнать некоторые подробности устройства JVM
вообще и HotSpot JVM в частности
 Научиться писать код, который работает
быстрее
 Узнать об утилитах для работы с JVM

Содержание
 Некоторые моменты архитектуры HotSpot
JVM
 Эффективное взаимодействие с JIT-
компилятором
 Эффективное взаимодействие со сборщиком
мусора

Архитектура HotSpot JVM
 Runtime
 Загрузка классов…
 Сборщик мусора
 Интрепретатор
 JIT
 Клиентский
 Серверный

 Архитектура HotSpot JVM
 Эффективное взаимодействие со сборщиком
мусора

Эффективное взаимодействие с JIT-
компилятором: типы компиляторов
 client - 32bit
- простой, ориентирован на приложения клиентского типа
(апплеты, игры)
- работает быстро, важна скорость запуска приложений
- генерирует менее оптимальный код
 server – 32bit, 64bit
- сложный, ориентирован на приложения серверного типа
- работает дольше, важна производительность создаваемого
кода
- более серьёзный анализ, сбор большей статистики =>
применение более агрессивных оптимизаций

 Машины серверного класса:
 Памяти ≥ 2Gb
 Количество cpu ≥ 2
 Компилятор, выбираемый по умолчанию

Какой компилятор работает?
 Используйте jinfo (Java SE 6)
 Или вызовите
 Или используйте java –version
 Или просто поменяйте тип компилятора:
● java –client MyClass.class
● java –server MyClass.class

компилятором: escape-анализ
Escape-анализ
 Является частью серверного компилятора
 Использует понятие непокидающего объекта. Объект О
называется непокидающим для метода М, если:
- объявлен внутри метода M
- не является объектом класса Thread или производного от
него
- не имеет финализатора
- не сохраняется в статическом поле класса или в поле
покидающего объекта
- не передается другому методу в качестве аргумента, если
только достоверно не известно, что O не покидает и этот
метод

Объекты i1 и e1 являются непокидающими

Возможные оптимизации:
 Устранение блокировок на непокидающих
объектах
 Оптимизация ссылок на объекты
 В ряде случаев – размещение объекта в
стеке или регистрах, а не в куче

компилятором: синхронизация
Синхронизация java-объектов
 Операции захвата/освобождения объектов дорогие
 В большинстве случаев захват объекта не является
состязательным:
- либо объект был свободным
- либо произошёл рекурсивный захват в рамках потока
Решение:
 Использование легковесных блокировок (эквивалентов CAS -
compare-and-swap – инструкций), это быстро
 Использование тяжеловесных блокировок, если невозможно
использовать легковесные – это на порядок медленнее

компилятором: синхронизация
Использование CAS-инструкций может быть дорогим на
многопроцессорных машинах
 Решение – привязанные (biased) блокировки
 Минус – дорогая операция отката привязки. JVM
анализирует статистику откатов связывания и
может запретит привязывания блокировки для
определённых типов объектов
 -XX: +UseBiasedLocking (начиная с 5.0 update 6)

 Пропуск блокировки (lock elision)
- Избежание блокировки над локальными переменными
- -XX: +DoEscapeAnalisys
 Укрупнение блокировки(lock coarsening)
- Объединение смежных synchronized блоков
- -XX: +EliminateLocks

Советы по синхронизации:
 Сразу рассчитывайте на использование вашего
кода в многопоточных приложениях.
Экономить на синхронизации нет смысла
 Используйте средства обнаружения
состязательных блокировок (например, jvmstat)

 Архитектура HotSpot JVM
 Эффективное взаимодействие со
сборщиком мусора

Эффективное взаимодействие со
сборщиком мусора: принципы работы
Сборка мусора (GC)
 Размещает объекты в памяти, находит и освобождает место,
занимаемое ненужными объектами
 Автоматическая и безопасная
 Проще, если граф объектов «заморожен» (stop-the-world
паузы)
 Возможны различные подходы
- С дефрагментацией или без
- Разные алгоритмы
- С разными типами аллокации (размещения объектов в
памяти) – например, учитывая «близость» области памяти к
процессору

Сборка мусора с поколениями
 Молодые и старые объекты содержатся отдельно
- В пространствах, называемых «поколениями»
- Возможны различные алгоритмы для молодого и старого
поколения
- Есть ещё третье пространство - Permanent Generation,
содержащее данные о загруженных классах,
откомпилированные методы и т.д.
 Слабая гипотеза о поколениях
- Большинство объектов временные
- Молодое поколение можно собирать отдельно от старого

Фоновая сборка мусора
– Уменьшает влияние GC на приложение
– Сборка мусора происходит одновременно с работой
приложения
– Если фоновый GC собирает только старшее поколение, нет
необходимости отслеживать изменения в молодом
поколении

 Последовательный / Serial GC
– Молодое поколение – последовательный копирующий GC,
старое – Mark-Sweep Compact
– Отлично подходит для клиентских приложений, не
требующих много памяти (≤ 200 Mb)
– “stop-the-world” сборщик – длительные паузы при больших
объёмах
 Фоновый / Concurrent Mark-Sweep GC
– Предназначен для избегания “stop-the-world” пауз
– Приводит к увеличению нагрузки на процессор, снижая
общую производительность

Как узнать про сборку мусора?
 jmap, jmap –heap, jmap –histo
 -verbose:gc
 -XX: +PrintGC
 -XX: +PrintGCDetails
 -XX: PrintHeapAtGC
 -XX: PrintGCTimeStamps
 jconsole
 jvisualVM
 YourKit Profile

сборщиком мусора: jvisualvm

сборщиком мусора: аллокация
 Быстрая аллокация
- Новый объект выделяется в молодом поколении
- Не нужно отслеживать изменение ссылок
- Гораздо быстрее, чем стандартные аллокаторы для С/С++
 Быстрое освобождение новых объектов
- Сборка молодого поколения
Совет:
– Не бойтесь выделять маленькие объекты для
промежуточных результатов
– Избегайте бессмысленных аллокаций, они приводят к
лишним вызовам GC

Также не стоит забывать про анализ
локальности (escape analysis), поэтому:
 Используйте неизменяемые маложивущие
объекты вместо часто изменяемых
долгоживущих объектов
 Используйте простой код с большим
количеством аллокаций вместо сложных
контрукций с меньшим количеством
аллокаций

 Большие объекты
- Долго аллоцировать (если объект не помещается в
молодом поколении)
- Дорого инициализировать
 Частая аллокация и освобождение объектов разных
размеров приводит к фрагментации (для GC без
дефрагментации или с частичной дефрагментацией)
Поэтому избегайте использования больших объектов,
но не в ущерб удобству

Non-Uniform Memory Access (NUMA)
 Доступ к памяти ассиметричен
– процессоры имеют разные задержки при доступе к различным участкам
памяти
- SPARC, Opteron, некоторые процессоры Intel
 NUMA-аллокатор
- Память под объект выделяется «ближе» к процессору, на котором
выполняется аллоцирующий поток
- Доступ к объектам быстрее из потока, в котором произведена
аллокация
 Включается явно: -XX: +UseNUMA
 JDK6u2, для Solaris ≥ 9, в Linux (с Linux kernel 2.6.19 и glibc
2.6.1)

Обнуление ссылок
 Редко помогает GC
- GC в состоянии определить, доступен ли объект
- Делает код менее читаемым
- Может породить скрытые ошибки
 Исключения
- Структуры, основанные на массивах (в этом
случае мы сами управляет памятью)
- Предотвращение утечки памяти, связанной с
финализацией

Пулы объектов
 Наследие старых VM с очень медленной скоростью аллокации
 Необходимо помнить
- GC с поколениями оптимизированы для работы с
маложивущими неизменяемыми объектами
- Локальные объекты могут быть оптимизированы
 Неиспользуемые объекты в пулах
- Лишняя работа для GC по сканированию/копированию
- Не приносит пользы, если приложение их не использует

Исключения
 Объекты, которые дорого инициализировать
 Объекты, которые связаны с редкими
ресурсами
- Потоки
- Соединение к БД

 Излишняя аллокация
 Правильная версия
 Старайтесь реалистично оценивать размер структур данных

сборщиком мусора: System.gc()
 Не используйте явных вызовов GC
- GC обладает информацией о скорости аллокации,
заполненности старшего поколения…
- System.gc() может повредить производительности
 Исключения
- Вызов System.gc() в период явного бездействия
системы
 В HotSpot
- System.gc() вызывает полный stop-the-world GC
- -XX: +DisableExplicitGC позволяет игнорировать
System.gc()

сборщиком мусора: финализация
 Основное применение – освобождение
системных ресурсов
 Финализируемые объекты – все с непустым
finalize()
 Аллокация финализируемых объектов
- Существенно медленнее
- VM должна их отслеживать

сборщиком мусора: финализация
Использование финализации для управления
системными ресурсами
 GC выполняет много работы по сопровождению
объекта с непустым finalize() и перед тем, как этот
объект будет финализирован
 GC вызывается, когда заканчивается память
 Памяти обычно больше, чем других системных
ресурсов
Поэтому управляйте ресурсами явно – используйте
пулы

сборщиком мусора: утечка памяти
Утечка памяти в системах со сборкой мусора
вызывается
– Объектами, которые доступны, но не
используются
– Использованием механизмов финализации
(временная утечка)

Стандартные случаи утечки памяти
 Забытые обработчики событий в Swing, AWT и т.д.
 Исключения могут менять порядок выполнения

Обнаружение утечек памяти
 jconsole
 jstat
 VisualVM
 jmap
 -XX: PrintClassHistogram и Ctrl + Break

Полезные ссылки
 Список опций JVM
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-
140102.html
 Этот тренинг подготовлен на основе доклада Екатерины
Павловой «Оптимизация производительности: эффективная
работа с виртуальной машиной»
http://conference.javatalks.ru/data/JVMTalk.pdf
 Блоги по этим и многим другим вопросам
http://javablogs.com

Вопросы

Performance optimization effective interaction with virtual machine

More Related Content

What's hot (14)

Viewers also liked (9)

Similar to Performance optimization effective interaction with virtual machine (20)

More from Return on Intelligence (20)

Performance optimization effective interaction with virtual machine