Will runtimes like CLR and JVM be able to use Haswell TSX instructions?

Question

After reading Anandtech on 'Haswell TSX' (tranactional memory barriers) I immediately wondered if CLR/JVM will be able to make use of these in C#/Java/Scala/F# for heavily parallel applications (C# Rx/TPL/TFD).

Schiff

Before you vote to close, this processor change could have big impacts on server-side programming. Specifically whether these runtimes can use these instructions with existing constructs or whether new constructs (STM) will have to be introduced for programmers to take advantage of the new hardware. – Schiff

Joe Duffy's latest blog post helped to clarify what the next generation in multi-threading will look like (at least for C#/.NET). bluebytesoftware.com/blog/2012/12/08/ImperativeFunctional.aspx – Schiff

Maybe they'll fix that eventually but for now they suggest no to use this feature as it's broken: HSW136, No Fix, Software Using Intel® TSX May Result in Unpredictable System Behavior on page 12 of the spec update pdf. So I guess there will be no more effort to include this feature in CLR or JVM until it's finally fixed. – Misdate

Minor update: TSX found buggy in Skylake and disabled by microcode update (like it was for Haswell and early Broadwell). Given that most CPU models aren't supposed to support it and most of those that were supposed to support it have it disabled due to bugs, I'm not even sure it's worth the hassle. – Outbound

Answer 1

HLE (hardware lock elision) can be easily integrated into any existing codebase that uses locks. For example, there is already exists an implementation for pthreads. Also, note that JVM already performs lock elision optimization, I think they can switch to hardware lock elision when possible easily.

But things gets more complicated with transactions. You can't start a transaction and push 1Mb of updates, your transaction will be aborted. Because of that, hardware transactional memory is limited, it is not as composable and modular as software transactional memory. It is a very low-level thing. Also, note that not every function can be called safely from transactions. Such function must be free from side effects.

Because of that, I expect TSX will be available in CLR in form of compiler intrinsics that will be used by framework developers to create better concurrent collections and synchronization primitives. It won't be like Haskell's or Clojure's transactional memory.

Peacock

Answer 2

Old question, but I thought I'd add a new answer with at least one concrete pointer

Intel has done experimentation using their TSX system to elide locks in Java, published here. Typical results though are only 2-3% on standard benchmarks such as SpecJVM2008, though one benchmark does see 18% improvement. Synthetic benchmarks see much better results, but the results are... synthetic.

Food

Answer 3

I expect the high performance JVM guys will jump on it first. e.g. http://www.azulsystems.com/products/zing/virtual-machine

I see TSX being of most use in high performance collection implementations. I don't see any reason why we can't implement a set of native code collections using TSX, and project that to .Net or Java using regular native invoke techniques.

Massenet

Azul have integrated that in their Azul JVM. Here is a presentation discussing how they did it link – Seibold

Answer 4

Adding up-to-date answer:

It seems that the usage of Intel-TSX instructions is implemented since Java 8u25. See https://bugs.openjdk.java.net/browse/JDK-8031320

Jadwiga

Answer 5

The problem that we saw was that in TSX mode the rate of retired operations is lower thus rendering the advantages of lock elision. That said I thing that if any runtime can benefit from TSX - it is adaptive runtimes like JVMs that cat track profitability at a particular call site and deoptimize/recompile if needed.

Enjoyment