JEP 374: Deprecate and Disable Biased Locking

Аннотация

Отключить biased locking по умолчанию и объявить устаревшими все связанные с ним параметры командной строки.

Цели

Определить, нужно ли и дальше поддерживать унаследованную оптимизацию синхронизации biased locking, поддержка которой обходится дорого.

Мотивация

Biased locking — метод оптимизации, который используется в HotSpot Virtual Machine, чтобы снизить накладные расходы на блокировку без конкуренции. Его цель — не выполнять атомарную операцию compare-and-swap при захвате монитора. Для этого предполагается, что монитор остаётся во владении данного потока, пока его не попытается захватить другой поток. Первый захват монитора привязывает монитор к этому потоку, и последующим синхронизированным операциям над тем же объектом атомарные инструкции уже не нужны. Когда множество потоков выполняет множество синхронизированных операций над объектами, которые используются в однопоточном режиме, привязка блокировок исторически давала значительный прирост производительности по сравнению с обычными методами блокировки.

Прирост производительности, который наблюдался в прошлом, сегодня гораздо менее заметен. Многие приложения, которым помогал biased locking, — это старые, унаследованные приложения, использующие ранние API коллекций Java, которые синхронизируются при каждом обращении (например, Hashtable и Vector). Более новые приложения обычно используют несинхронизированные коллекции (например, HashMap и ArrayList), появившиеся в Java 1.2 для однопоточных сценариев, или ещё более производительные конкурентные структуры данных, появившиеся в Java 5, для многопоточных сценариев. Поэтому приложения, которые выигрывают от biased locking из-за лишней синхронизации, скорее всего, станут работать быстрее, если перевести их код на эти более новые классы. Кроме того, приложения, построенные на очереди пула потоков и рабочих потоках, обычно работают быстрее при отключённом biased locking. (Например, так устроен SPECjbb2015, а SPECjvm98 и SPECjbb2005 — нет). За biased locking приходится платить: при конкуренции требуется дорогая операция отзыва. Поэтому выигрывают от него только приложения, в которых выполняется значительное количество синхронизированных операций без конкуренции, как в упомянутых выше, так что стоимость дешёвых проверок владельца блокировки плюс изредка дорогого отзыва всё ещё ниже стоимости выполнения исключённых атомарных инструкций compare-and-swap. Стоимость атомарных инструкций изменилась с тех пор, как biased locking появился в HotSpot, а вместе с ней изменилось и количество операций без конкуренции, при котором это соотношение остаётся верным. Стоит отметить и ещё одно: даже если указанное соотношение стоимостей выполняется, приложения не получат заметного прироста производительности от biased locking, когда время, затрачиваемое на синхронизированные операции, составляет лишь малую долю общей нагрузки приложения.

Biased locking добавил много сложного кода в подсистему синхронизации и затрагивает также другие компоненты HotSpot. Из-за этой сложности трудно разобраться в разных частях кода, а значительно изменить архитектуру подсистемы синхронизации непросто. Поэтому мы хотели бы отключить biased locking, объявить его устаревшим и в итоге удалить его поддержку.

Описание

До JDK 15 biased locking всегда включён и доступен. С этим JEP biased locking больше не будет включаться при запуске HotSpot, если в командной строке не задан -XX:+UseBiasedLocking.

Мы объявим устаревшими параметр UseBiasedLocking и все параметры, связанные с настройкой и использованием biased locking.

• Штатные параметры: BiasedLockingStartupDelay, BiasedLockingBulkRebiasThreshold, BiasedLockingBulkRevokeThreshold, BiasedLockingDecayTime и UseOptoBiasInlining
• Диагностические параметры: PrintBiasedLockingStatistics и PrintPreciseBiasedLockingStatistics

Эти параметры по-прежнему будут приниматься и действовать, но будет выдаваться предупреждение об устаревании.

Риски и допущения

Некоторые Java-приложения могут работать медленнее при отключённом biased locking. Возможность снова включить biased locking в командной строке помогает смягчить эту проблему и может показать, в каких ситуациях его использование всё ещё даёт выигрыш.