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.,
Vector). Newer applications generally use the non-synchronized collections (e.g.,
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. 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.
- Product options:
- Diagnostic options:
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.