是否有任何多线程跟踪 JIT 编译器的示例？答案

【问题标题】：Are there any examples of multithreaded Tracing JIT compilers?是否有任何多线程跟踪 JIT 编译器的示例？
【发布时间】：2016-09-06 03:10:39
【问题描述】：

JVM 和 .NET CLR 都包含支持多用户线程的即时编译器。但是，我相信这些都是一次方法的 JIT。

我知道的所有tracing JITs，例如LuaJIT 和PyPy，都只是单线程的。

是否有跟踪支持多用户线程的 JIT 的示例？如果没有，是否有任何技术原因导致这些不存在？

【问题讨论】：

.NET 支持多核 jit。但一般来说，它并不是一个通用的解决方案，它只有在核心忙于抖动时才会产生任何明显的效果。这需要一台时间机器，它知道接下来可能使用什么方法。通过记录配置文件数据（方法执行的顺序）在 .NET 中解决。因此，下一次程序运行时，它们可以被提前运行。时间机器很棘手，他们告诉你 2015 年人们有悬浮滑板和飞行汽车。嗯，悬浮滑板是真的。
@HansPassant - 使用后台线程来 JIT 编译代码很有趣，我不知道 .NET 有这个功能。但是，即使在添加此功能之前，用户也可以创建多个线程——因此已经需要 .NET JIT 在多个线程上编译代码。尽管如此，.NET 仍然一次 JIT 编译一种方法。我的问题是关于Tracing JITs：在多个线程（在后台或支持多个用户线程）上编译的跟踪 JIT 是否有任何技术障碍？

标签： multithreading compilation jit pypy luajit

【解决方案1】：

分析（跟踪）正在运行的多线程程序要困难得多，但也并非不可能。跟踪的重点是使运行时比优化编译器第一次做的更好。如果线程是相互关联的，那么要修改代码的 JIT 不仅需要了解代码是如何执行的，还需要了解对其他线程的副作用。

当线程一需要访问内存中的一个大文件时，它是否会创建一个二级缓存刷新，导致线程二由于其正在运行的代码之外的原因而停止。 JIT 必须了解这些交互。否则，当线程二的改进来自于意识到线程一代码对线程二产生不利影响并试图消除缓存刷新时，它可能会花费大量时间来尝试优化线程二。

您是否正在考虑尝试编写自己的跟踪多线程 JIT？可以做到，但涉及到。

【讨论】：

AFAIK LuaJIT，例如，仅根据运行次数来决定要 JIT 的代码，而不是使用时间信息。因此，我相信它的算法应该不受您提到的线程间缓存问题的影响。在我看来，跟踪 JIT 不能支持多线程没有理论上的理由——但也许这样的 JIT 从未实现过？ 您是否正在考虑尝试编写自己的跟踪多线程 JIT？ 我正在考虑编写跟踪 JIT，是的。我正在尝试确定对多线程的支持是否是该项目的合理目标。
毫无疑问，您可以优化某些代码的运行次数，但从多线程应用程序的全局角度来看，这将是次优的。在过去的工作中，我们会手动优化关闭处理器中的某些内核，以便在不刷新的情况下使用更多的 L2 和 L3 缓存空间，我们会做一些事情，例如消除互斥锁并验证输入是否在计算后没有更新完成，因为“窥探”比实际锁定互斥锁要便宜得多，其中分析表明更新和读取很少发生冲突。
在跟踪 JIT 中支持多线程是合理的。唯一的问题是你能做出多好的优化。

【解决方案2】：

由于前提错误，您的问题没有实际意义。 Oracle 的 JVM/OpenJDK 的 HotSpot 优化器不是“一次一个方法的 JIT”。它的一项基本技术是内联功能，通常称为“积极内联”，因为它根据当前执行的分析（和其他提示）推测内联方法被假定为最有可能是动态方法调度的目标。这甚至包括反优化功能，如果程序的运行时行为发生变化并且不再执行优化的代码路径。

内联是基础，因为大多数其他代码优化只有在方法代码被内联到调用者的代码中并提供必要的上下文时才能发挥其真正的潜力。

因此，使用 HotSpot JVM，您已经拥有一个利用已知执行路径的多线程优化环境。但是，不需要以被描述为“跟踪”的方式收集这些信息。由于此 JVM 能够随时创建线程堆栈跟踪的快照，因此它还可以在定义的时间间隔内查看跟踪，比在每个方法调用中添加记录功能可以更好地控制分析开销。因此，JVM 可以将跟踪的获取限制在实际消耗大量 CPU 时间的线程上，并且本质上会得到一个实际的调用链，即使所涉及的方法包含在不同线程的多个调用链中。

【讨论】：

作为附录，您可以使用选项-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 让JVM 打印将内联的调用树。