JEP 143: Improve Contended Locking
Улучшение блокировок в условиях конкуренции
| Автор | Dan Daugherty |
| Ответственный | Daniel Daugherty |
| Тип | Feature |
| Область | Implementation |
| Статус | Closed / Delivered |
| Выпуск | 9 |
| Компонент | hotspot / runtime |
| Обсуждение | hotspot dash runtime dash dev at openjdk dot java dot net |
| Трудоёмкость | M |
| Длительность | L |
| Рецензенты | Karen Kinnear |
| Одобрен | Mikael Vidstedt |
| Создан | 2011/11/30 20:00 |
| Обновлён | 2017/03/06 11:34 |
| Задача | 8046133 |
Аннотация
Повысить производительность мониторов объектов Java в условиях конкуренции.
Цели
Повысить общую производительность мониторов объектов Java в условиях конкуренции по результатам следующих бенчмарков и тестов:
- CallTimerGrid (хотя это скорее стресс-тест, чем бенчмарк)
- Dacapo-bach (ранее dacapo2009)
- _ avrora
- _ batik
- _ fop
- _ h2
- _ luindex
- _ lusearch
- _ pmd
- _ sunflow
- _ tomcat
- _ tradebeans
- _ tradesoap
- _ xalan
- DerbyContentionModelCounted
- HighContentionSimulator
- LockLoops-JSR166-Doug-Sept2009 (ранее LockLoops)
- PointBase
- SPECjbb2013-critical (ранее specjbb2005)
- SPECjbb2013-max
- specjvm2008
- volano29 (ранее volano2509)
Что не является целью
Цель этого проекта — не повышение производительности внутренних мониторов или мьютексов VM: мониторы Java и внутренние мониторы и мьютексы VM реализованы разным кодом. Хотя некоторые идеи этого проекта могут быть применимы к внутренним мониторам и мьютексам VM, сам код к ним напрямую неприменим.
Цель этого проекта — не повышение производительности мониторов Java в условиях конкуренции на каждом бенчмарке или тесте; в некоторых случаях производительность на отдельном бенчмарке или тесте может снизиться. Такое снижение производительности может быть сочтено допустимым ради повышения производительности на другом бенчмарке или тесте.
Критерии успеха
Проект будет считаться успешным, если по результатам перечисленных выше бенчмарков будет продемонстрирован прирост производительности, не сведённый на нет значительными регрессиями производительности.
Не должно быть заметной регрессии производительности для блокировок без конкуренции.
Мотивация
Улучшение блокировок в условиях конкуренции принесёт значительную пользу реальным приложениям, а не только отраслевым бенчмаркам, таким как Volano и DaCapo.
Описание
В рамках этого проекта будут исследованы возможности повышения производительности мониторов Java в условиях конкуренции в следующих областях:
- Переупорядочивание полей и выравнивание по строкам кэша
- Ускорение
PlatformEvent::unpark() - Быстрые операции входа в монитор Java
- Быстрые операции выхода из монитора Java
- Быстрые операции
notify/notifyAllдля мониторов Java
Исходный объём работ включал также изменения для «более быстрого hashcode»; поскольку поддержка hashcode объектов Java не связана напрямую с мониторами Java в условиях конкуренции, эта работа не будет включена в данный проект.
В ходе этого проекта также будут исправлены различные ошибки, обнаруженные во время работы; эти исправления ошибок будут вестись отдельно от работы по повышению производительности, чтобы их можно было интегрировать раньше.
Для упрощения администрирования этот проект охватывается следующей «зонтичной» задачей:
JDK-6607129 Сократить трафик промахов когерентности L2$ в цикле активного ожидания на конкурентной блокировке, в частности для derby на ctn-family
Однако по мере завершения подзадач или исправлений ошибок работа будет интегрироваться под отдельными номерами задач. Так на весь проект можно ссылаться по одному номеру задачи (JDK-6607129), а поэтапные улучшения становятся доступны быстрее, чем если бы пришлось ждать завершения всего проекта.
Тестирование
Функциональное тестирование
Специального набора функциональных тестов исключительно для мониторов Java, по-видимому, нет, и он не нужен. Мониторы Java настолько широко используются даже простейшими программами на Java, что почти любая функциональная поломка в мониторах Java должна быть очевидна.
Стресс-тесты
Нужен набор хорошо известных стресс-тестов для мониторов Java. Это могут быть целевые стресс-тесты для конкретных сценариев работы мониторов Java или тесты, которые, как известно, интенсивно используют мониторы Java, запущенные со специальными параметрами, создающими нагрузку.
Примечание: используйте «-XX:-UseBiasedLocking -XX:+UseHeavyMonitors», чтобы обойти и смещённую блокировку (biased locking), и блокировку на основе стека; это принудительно включает использование объектов ObjectMonitor.
Стресс-тесты подзадачи переупорядочивания полей и выравнивания по строкам кэша
Стресс-тест должен быть направлен на создание большого числа активных объектов ObjectMonitor. Целью стресс-тестирования являются пиковое использование ObjectMonitor, алгоритм блочного выделения ObjectMonitor и код управления списком свободных ObjectMonitor. Задачи следующие:
- такое же или лучшее пиковое использование ObjectMonitor для малых и средних конфигураций,
- отсутствие утечек памяти и
- отсутствие сбоев в управлении структурами данных.
Стресс-тесты подзадачи ускорения PlatformEvent::unpark()
Стресс-тест должен быть направлен на большое число одновременно ожидающих потоков и/или потоков, одновременно выполняющих вход и выход. Соотношение потоков, выполняющих вход-ожидание-выход и вход-выход, должно настраиваться. Целью стресс-тестирования является механизм преемника.
Задача: никаких зависаний из-за потерянных операций unpark.
Стресс-тесты подзадачи быстрых операций входа в монитор Java
Стресс-тест должен быть направлен на корректность операций вход-выход при масштабируемом числе параллельных потоков. Целью стресс-тестирования является владение монитором Java.
Задача: никаких конфликтов владения, при которых более одного потока считает, что владеет монитором Java.
Стресс-тесты подзадачи быстрых операций выхода из монитора Java
Должны покрываться стресс-тестами подзадач «ускорение PlatformEvent::unpark()» и «быстрые операции входа в монитор Java».
Стресс-тесты подзадачи быстрых операций Notify/NotifyAll для мониторов Java
Стресс-тест должен быть направлен на корректность операций вход-ожидание-выход при масштабируемом числе параллельных потоков. Целью стресс-тестирования является владение монитором Java после завершения wait() и повторного входа в монитор Java.
Задача: никаких конфликтов владения, при которых более одного потока считает, что владеет монитором Java.