JEP 374: Disable and Deprecate Biased Locking

A new candidate Java enhancement proposal (JEP) from OpenJDK developer Patricio Chilano Mateo, JEP 374, wants to disable and deprecate biased locking. It scores an XS for effort and duration, making it a likely feature for JDK 15 later this year.

The stated goal of the JEP is to “determine the need for continued support of the legacy synchronization optimization of biased locking, which is costly to maintain.”

JEP 374: Disable and Deprecate Biased Locking

The JEP owner describes the motivation for this proposal as follows:

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.

SEE ALSO: JEP 372 – Remove the Nashorn JavaScript Engine

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. 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 brought a lot of complex code into the synchronization subsystem and affects other HotSpot components, too. Complex legacy code not only makes it difficult to develop or change the synchronization subsystem, but maintaining it is more and more of an effort as well. That’s why this JEP aims to take the first step towards removing support for biased locking.

SEE ALSO: JEP 373 – Reimplement the Legacy DatagramSocket API

If the JEP makes it into a JDK version, it will disable biased locking by default when HotSpot is started. It will still be possible for users to enable it again by setting XX:+UseBiasedLocking on the command line, but UseBiasedLocking and related options would be deprecated; still working, but issuing a deprecation warning if used.

Mateo notes that some Java applications will notice an adverse effect on performance when biased locking is disabled, which is why the move is toward disabling and deprecating it, not straight out removing it. The hope is also to obtain a better idea of the scenarios in which users are still benefiting from biased locking.

For more information, check out JEP 374 here.

The post JEP 374: Disable and Deprecate Biased Locking appeared first on JAXenter.