Performance optimization: effective interaction with virtual machine

Оптимизация производительности:
эффективное взаимодействие с виртуальной
машиной

September 5, 2012 www.ExigenServices.com

Цели тренинга

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

2 www.ExigenServices.com

Содержание

 Некоторые моменты архитектуры 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

Similar to Performance optimization: effective interaction with virtual machine

More from Return on Intelligence

Performance optimization: effective interaction with virtual machine