Biased locking removed from Java 15 - does it impact you?

What is biased locking?

• Biased locking lowers the cost of uncontended/synchronization.
• It enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a?monitorenter?bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocess.or machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact.

Without biased locking: a thread needs to set and clear a lock bit when it performs repeated synchronizations on the same object. It also needs to wait for those set/clear writes to be drained to local cache before proceeding to execute further memory operations.

With biased locking: the first time a thread synchronizes on an object it does a bit more work to acquire synchronized ('bias' it to the thread). Subsequent syncrhonizations proceed via a simple read test with no need to drain to cache.

OpenJDK in Java 15 have disabled?biased locking?(JEP 374) in the Java virtual machine. This is a change from previous versions and could?potentially?have a negative impact on Java application’s performance.

To analyse your application performance is affected by biased locking or not, please try the following in your application performance tests:

Run your application performance tests as you normally would with the following command line flags on Java 11 (jdk11u) and if feasible Java 15 (jdk15):

enabled: -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0

disabled: -XX:-UseBiasedLocking

I would like to know the result of this no matter if you see a regression or not on the same Java Virtual Machine.

If you are able, then running it with the following scenarios would be of great help too:

1.???single-threaded

2.???thread count ~= hardware core count

3.???thread count ~= N * hardware core count where 8 < N < 16

The intent of these is to see how the level of concurrency affects the result.

?Where’s the trade off?

Well, if a biased lock is contended then there is more work to do to bias and unbias the lock. However, it is known that many synchronized operations are uncontended.

Biasing can be big win when a potentially concurrent data structure is used sequentially. The case where it helps most is exemplified in the problem we already found in class?DataOutputStream. Normally only one thread writes a?DataOutputStream?and it is often not read until the stream has been filled. All the same, every?putInt()?or?putLong()`?call invokes a syncrhonized method to increment the byte count by 4 or 8. That’s needed just in case some other thread might want to reliably locate the end of the valid buffer data but that rarely happens. So, the unbiased case suffers lock write and cache drain delays at every basic put operation.

A similar case occurs with class ByteOutput Stream. Method putByte is synchronized. So writing a single byte involves a lock and unlock. n.b. method putInt calls putByte 4 times, requiring 4 locks and unlocks. Method putLong calls it 8 times!

?Why is biased locking being removed?

The implementation of biased locking adds a great deal of complexity to the JVM and is understood by only a small subset of the most experienced engineers. The cost of maintaining it and designing around it is significantly slowing down progress on new features. It has been a long term goal to remove it if at all possible. Some OpenJDK contributors wanted to remove it right away in jdk15 others argue for a slower deprecation route in order to check that we could really dispense with it.

References :

• https://www.oracle.com/java/technologies/java-tuning.html#section4.2.5
• https://openjdk.org/jeps/374