Biased locking in java

Question

I keep reading about how biased locking, using the flag -XX:+UseBiasedLocking, can improve the performance of un-contended synchronization. I couldn't find a reference to what it does and how it improves the performance.

Can anyone explain me what exactly it is or may be point me to some links/resources that explains??

Vigor

Answer 1

Essentially, if your objects are locked only by one thread, the JVM can make an optimization and "bias" that object to that thread in such a way that subsequent atomic operations on the object incurs no synchronization cost. I suppose this is typically geared towards overly conservative code that performs locks on objects without ever exposing them to another thread. The actual synchronization overhead will only kick in once another thread tries to obtain a lock on the object.

It is on by default in Java 6.

-XX:+UseBiasedLocking 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 multiprocessor 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.

Eolic

unfortunately bias locked is being depreciated by openJDK 15 see openjdk.java.net/jeps/…. and quarkus.io/blog/biased-locking-help – Stoma

Answer 2

Does this not answer your questions?

http://www.oracle.com/technetwork/java/tuning-139912.html#section4.2.5

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 multiprocessor 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.

Though I think you'll find it's on by default in 1.6. Use the PrintFlagsFinal diagnostic option to see what the effective flags are. Make sure you specify -server if you're investigating for a server application because the flags can differ:

http://www.jroller.com/ethdsy/entry/print_all_jvm_flags

Spoliate

Answer 3

I've been wondering about biased locks myself.

However it seems that java's biased locks are slower on intel's nehalem processors than normal locks, and presumably on the two generations of processors since nehalem. See http://mechanical-sympathy.blogspot.com/2011/11/java-lock-implementations.html and here http://www.azulsystems.com/blog/cliff/2011-11-16-a-short-conversation-on-biased-locking

Also more information here https://blogs.oracle.com/dave/entry/biased_locking_in_hotspot

I've been hoping that there is some relatively cheap way to revoke a biased lock on intel, but I'm beginning to believe that isn't possible. The articles I've seen on how it's done rely on either:

1. using the os to stop the thread
2. sending a signal, ie running code in the other thread
3. having safe points that are guaranteed to run fairly often in the other thread and waiting for one to be executed (which is what java does).
4. having similar safe points that are a call to a return - and the other thread MODIFIES THE CODE to a breakpoint...

Gavel

There is another article with more precise results: mechanical-sympathy.blogspot.com/2011/11/…. It was published few days after mechanical-sympathy.blogspot.com/2011/11/… – Package

Answer 4

Worth mentioning that biased locking will be disabled by default jdk15 onwards

JEP 374 : Disable and Deprecate Biased Locking

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.

Further

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.

And ya, no more System.identityHashCode(o) magic ;)

Ullage

Answer 5

Two paper here:

https://cdn.app.compendium.com/uploads/user/e7c690e8-6ff9-102a-ac6d-e4aebca50425/f4a5b21d-66fa-4885-92bf-c4e81c06d916/File/ccd39237cd4dc109d91786762fba41f0/qrl_oplocks_biasedlocking.pdf

https://www.oracle.com/technetwork/java/biasedlocking-oopsla2006-wp-149958.pdf

web page too: https://blogs.oracle.com/dave/biased-locking-in-hotspot

jvm hotspot source code:

http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/oops/markOop.hpp

Unpolite

You're really free. It's OK – Fleeta