Does the CLR perform "lock elision" optimization? If not why not?

Question

The JVM performs a neat trick called lock elision to avoid the cost of locking on objects that are only visible to one thread.

There's a good description of the trick here:

http://www.ibm.com/developerworks/java/library/j-jtp10185/

Does the .Net CLR do something similar? If not then why not?

Answer 1

It's neat, but is it useful? I have a hard time coming up with an example where the compiler can prove that a lock is thread local. Almost all classes don't use locking by default, and when you choose one that locks, then in most cases it will be referenced from some kind of static variable foiling the compiler optimization anyways.

Another thing is that the java vm uses escape analysis in its proof. And AFAIK .net hasn't implemented escape analysis. Other uses of escape analysis such as replacing heap allocations with stack allocations sound much more useful and should be implemented first.

IMO it's currently not worth the coding effort. There are many areas in the .net VM which are not optimized very well and have much bigger impact.

SSE vector instructions and delegate inlining are two examples from which my code would profit much more than from this optimization.