像 CLR 和 JVM 这样的运行时是否能够使用 Haswell TSX 指令？答案

【问题标题】：Will runtimes like CLR and JVM be able to use Haswell TSX instructions?像 CLR 和 JVM 这样的运行时是否能够使用 Haswell TSX 指令？
【发布时间】：2012-12-07 06:21:28
【问题描述】：

阅读Anandtech on 'Haswell TSX' (tranactional memory barriers) 后，我立即想知道 CLR/JVM 是否能够在 C#/Java/Scala/F# 中将这些用于高度并行的应用程序（C# Rx/TPL/TFD）。

【问题讨论】：

在您投票关闭之前，此处理器更改可能会对服务器端编程产生重大影响。具体来说，这些运行时是否可以将这些指令与现有结构一起使用，或者是否必须为程序员引入新结构 (STM) 以利用新硬件。
Joe Duffy 的最新博客文章帮助阐明了下一代多线程将是什么样子（至少对于 C#/.NET）。 bluebytesoftware.com/blog/2012/12/08/ImperativeFunctional.aspx
也许他们最终会解决这个问题，但现在他们建议不要使用此功能，因为它已损坏：HSW136, No Fix, Software Using Intel® TSX May Result in Unpredictable System Behavior 在规范更新 pdf 第 12 页上。所以我想在最终修复之前，不会再努力将这个特性包含在 CLR 或 JVM 中。
次要更新：TSX 在 Skylake 中发现了错误并被微码更新禁用（就像 Haswell 和早期的 Broadwell 一样）。鉴于大多数 CPU 型号不应该支持它，并且大多数应该支持它的 CPU 型号由于错误而将其禁用，我什至不确定它是否值得。

标签： x86 clr intel transactional-memory intel-tsx

【解决方案1】：

老问题，但我想我会用至少一个具体指针添加一个新答案

英特尔已经使用他们的 TSX 系统在 Java 中进行了消除锁的实验，发布了here。尽管标准基准测试（例如 SpecJVM2008）的典型结果仅为 2-3%，但一项基准测试确实看到了 18% 的改进。综合基准测试的结果要好得多，但结果是……综合的。

【讨论】：

【解决方案2】：

HLE（硬件锁省略）可以轻松集成到任何使用锁的现有代码库中。例如，已经存在 pthreads 的实现。另外，请注意 JVM 已经执行了锁省略优化，我认为他们可以在可能的情况下轻松切换到硬件锁省略。

但是交易变得更加复杂。您无法启动事务并推送 1Mb 的更新，您的事务将被中止。正因为如此，硬件事务内存是有限的，它不像软件事务内存那样可组合和模块化。这是一个非常低级的东西。另外，请注意，并非每个函数都可以从事务中安全地调用。这样的功能必须没有副作用。

因此，我预计 TSX 将以编译器内在函数的形式在 CLR 中可用，框架开发人员将使用它来创建更好的并发集合和同步原语。它不会像 Haskell 或 Clojure 的事务内存。

【讨论】：

【解决方案3】：

我希望高性能 JVM 人员会首先使用它。例如http://www.azulsystems.com/products/zing/virtual-machine

我看到 TSX 在高性能集合实现中最有用。我看不出为什么我们不能使用 TSX 实现一组本机代码集合，并使用常规本机调用技术将其投影到 .Net 或 Java。

【讨论】：

Azul 已将其集成到他们的 Azul JVM 中。这是一个演示文稿，讨论他们是如何做到的link

【解决方案4】：

添加最新答案：

似乎从 Java 8u25 开始使用 Intel-TSX 指令。见https://bugs.openjdk.java.net/browse/JDK-8031320

【讨论】：

【解决方案5】：

我们看到的问题是，在 TSX 模式下，退休操作的比率较低，从而发挥了锁省略的优势。这就是说，如果任何运行时都可以从 TSX 中受益，那就是像 JVM 这样的自适应运行时，它可以跟踪特定调用站点的盈利能力，并在需要时进行反优化/重新编译。

【讨论】：