分享一篇SOSP2023关于jit测试的论文。主要的目的是通过保持代码语义不变，尽可能的探索jit优化的空间。方法集合了苏老师很多过往优秀文章的思想，推荐大家阅读一下Compiler Validation via Equivalence Modulo Inputs，Skeletal Program Enumeration for Rigorous Compiler Testing. 文章中检查oracle的方法类似的文章 FuzzJIT: Oracle-Enhanced Fuzzing for JavaScript Engine JIT Compiler. 通过template测试jvm的文章 Compiler Testing via Template Java Programs.
摘要
本文介绍了编译空间这一新颖概念，它有助于在现代语言虚拟机（LVM）中对即时（JIT）编译器进行全面验证。编译空间由大量 JIT 编译选择组成，即使对于单个程序而言，也可以交叉验证 JIT 编译的正确性。为了以轻量级和与 LVM 无关的方式彻底探索编译空间，我们有策略地改变测试程序的 JIT 相关性，但保留语义的代码结构，以触发不同的 JIT 编译选择。我们在 Java 虚拟机（JVM）工具 Artemis 中实现了我们的技术。通过评估，我们收到了 85 份针对三种广泛使用的生产型 JVM（即 HotSpot、OpenJ9 和 Android Runtime）的错误报告。其中，53 个已得到确认或修复，许多还是关键性的。值得一提的是，所有报告的错误都与 JIT 编译器有关，这表明我们的技术具有明显的有效性和很强的实用性。我们希望，我们方法的通用性和实用性将使其广泛适用于理解和验证 JIT 编译器。
关键思想
考虑下面这个例子，一共有四个函数。所以总共的jit优化情况是2^4=16种，所有的情况代码执行结果应该一致均为3。过去的测试方法考虑#1和#16种，即无优化和代码全部优化的情况，漏掉了很多。本文通过插入/删除循环、函数调用和不常用的冷门路径等方法控制解释器和编译器之间的切换。
