JEP 374: Disable and Deprecate Biased Locking

OwnerPatricio Chilano Mateo
StatusClosed / Delivered
Componenthotspot / runtime
Discussionhotspot dash runtime dash dev at openjdk dot java dot net
Reviewed byColeen Phillimore, David Holmes, Mikael Vidstedt
Endorsed byMikael Vidstedt
Created2019/12/03 14:24
Updated2020/06/18 02:45


Disable biased locking by default, and deprecate all related command-line options.


Determine the need for continued support of the legacy synchronization optimization of biased locking, which is costly to maintain.


Biased locking is an optimization technique used in the HotSpot Virtual Machine to reduce the overhead of uncontended locking. It aims to avoid executing a compare-and-swap atomic operation when acquiring a monitor by assuming that a monitor remains owned by a given thread until a different thread tries to acquire it. The initial lock of the monitor biases the monitor towards that thread, avoiding the need for atomic instructions in subsequent synchronized operations on the same object. When many threads perform many synchronized operations on objects used in a single-threaded fashion, biasing the locks has historically led to significant performance improvements over regular locking techniques.

The performance gains seen in the past are far less evident today. The cost of executing atomic instructions has decreased on modern processors since the introduction of biased locking into HotSpot. Furthermore, many applications that benefited from biased locking are older, legacy applications that use the early Java collection APIs, which synchronize on every access (e.g., Hashtable and Vector). Newer applications generally use the non-synchronized collections (e.g., HashMap and ArrayList), introduced in Java 1.2 for single-threaded scenarios, or the even more-performant concurrent data structures, introduced in Java 5, for multi-threaded scenarios. This means that applications that benefit from biased locking due to unnecessary synchronization will likely see a performance improvement if the code is updated to use these newer classes. Also applications built around a thread-pool queue and worker threads generally perform better with biased locking disabled. (SPECjbb2015 was designed that way, e.g., while SPECjvm98 and SPECjbb2005 were not.)

Biased locking introduced a lot of complex code into the synchronization subsystem and is invasive to other HotSpot components as well. This complexity is a barrier to understanding various parts of the code and an impediment to making significant design changes within the synchronization subsystem. To that end we would like to disable, deprecate, and eventually remove support for biased locking.


Prior to JDK 15, biased locking is always enabled and available. With this JEP, biased locking will no longer be enabled when HotSpot is started unless -XX:+UseBiasedLocking is set on the command line.

We will deprecate the UseBiasedLocking option and all options related to the configuration and use of biased locking.

The options will still be accepted and acted upon, but a deprecation warning will be issued.

Risk and Assumptions

Some Java applications may see a performance regression with biased locking disabled. Allowing biased locking to be re-enabled on the command line helps to mitigate this and provides possible insight into which situations may still benefit from its usage.