# Biased Locking, OSR, and Benchmarking Fun

DevFeed: [Biased Locking, OSR, and Benchmarking Fun](<https://devfeed.tech/articles/biased-locking-osr-and-benchmarking-fun-13619.md>)

Original publisher: [Read original article](<https://mechanical-sympathy.blogspot.com/2011/11/biased-locking-osr-and-benchmarking-fun.html>)

Author: Martin Thompson (noreply@blogger.com)

Published: 2011-11-22T16:36:00Z

Content type: tutorial

Language: en

Sources: [Mechanical Sympathy](<https://devfeed.tech/sources/mechanical-sympathy.md>)

Topics: [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Java](<https://devfeed.tech/topics/java.md>), [JIT](<https://devfeed.tech/topics/jit.md>)

Tags: [azul](<https://devfeed.tech/tags/azul.md>), [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [java](<https://devfeed.tech/tags/java.md>), [jit](<https://devfeed.tech/tags/jit.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [locking](<https://devfeed.tech/tags/locking.md>), [locks](<https://devfeed.tech/tags/locks.md>), [low-latency](<https://devfeed.tech/tags/low-latency.md>), [performance](<https://devfeed.tech/tags/performance.md>), [profiling](<https://devfeed.tech/tags/profiling.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

This article revisits an experiment on Java biased locking after accounting for JVM warm-up behavior. It explains On Stack Replacement and JIT compilation, and argues that several shorter warm-up runs can produce better-optimized code than one long warm-up when designing micro-benchmarks.

## Source excerpt

After my last post on Java Lock Implementations, I got a lot of good feedback about my results and micro-benchmark design approach. As a result I now understand JVM warmup, On Stack Replacement (OSR) and Biased Locking somewhat better than before. Special thanks to Dave Dice from Oracle, and Cliff Click & Gil Tene from Azul, for their very useful feedback. In the last post I concluded, based on my experiments, that biased locking was no longer necessary on modern CPUs. While this conclusion is understandable given the data gathered in the experiment, it was not valid because the experiment did not take account of some JVM warm up behaviour that I was unaware of. In this post I will re-run the experiment taking into account the feedback and present some new results. I shall also expand on the changes I've made to the test and why it is important to consider the JVM warm-up behaviour when writing micro-benchmarks, or even very lean Java applications with quick start up time. On Stack Replacement (OSR) Java virtual machines will compile code to achieve greater performance based on runtime profiling. Some VMs run an interpreter for the majority of code and replace hot areas with compiled code following the 80/20 rule. Other VMs compile all code simply at first then replace the simple code with more optimised code based on profiling. Oracle Hotspot and Azul are examples of the first type and Oracle JRockit is an example of the second. Oracle Hotspot will count invocations of a method return plus branch backs for loops in that method, and if this exceeds 10K in server mode the method will be compiled. The compiled code on normal JIT'ing can be used when the method is next called. However if a loop is still iterating it may make sense to replace the method before the loop completes, especially if it has many iterations to go. OSR is the means by which a method gets replaced with a compiled version part way through iterating a loop. I was under the impression that normal JI