JDK-8235256 : JEP 374: Deprecate and Disable Biased Locking
  • Type: JEP
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 15
  • Submitted: 2019-12-03
  • Updated: 2021-08-28
  • Resolved: 2020-06-15
Related Reports
Relates :  
Description
Summary
-------

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


Goals
-----

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


Motivation
-------------

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. 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. Furthermore, 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 comes with the cost of requiring an expensive revocation operation in case of contention. Applications that benefit from it are therefore only those that exhibit significant amounts of uncontended synchronized operations, like those mentioned above, so that the cost of executing cheap lock owner checks plus an occasional expensive revocation is still lower than the cost of executing the eluded compare-and-swap atomic instructions. Changes in the cost of atomic instructions since the introduction of biased locking into HotSpot also change the amount of uncontended operations needed for that relation to remain true. Another aspect worth noting is that applications won't have noticeable performance improvements from biased locking even when the previous cost relation is true when the time spend on synchronized operations is still only a small fraction of the total application workload.

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.

Description
-----------

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: `BiasedLockingStartupDelay`, `BiasedLockingBulkRebiasThreshold`, `BiasedLockingBulkRevokeThreshold`, `BiasedLockingDecayTime` and `UseOptoBiasInlining`
  - Diagnostic options: `PrintBiasedLockingStatistics` and `PrintPreciseBiasedLockingStatistics`

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.

Comments
Ok, I'll add those two flags to the JEP. Thanks [~kvn].
06-03-2020

2 additional C2 flags, UseOptoBiasInlining and PrintPreciseBiasedLockingStatistics, should be deprecated too .
06-03-2020

Edition looks good, thanks [~mr]. I assigned it to you.
05-03-2020

I've done a light copy-editing pass to tighten up the wording and align some terminology. If this looks okay to you then assign the issue to me and I"ll move this to Candidate.
05-03-2020

While there is very little technical change involved in this JEP, it was considered necessary/desirable to write a JEP for increased visibility of the change. JEPs seem to make their way into various "what's new" blogs and articles on OpenJDK, whereas Release Notes (which will still be created for this) seem to be largely overlooked. I've added myself as Reviewer.
20-02-2020