静态编译与JIT编译相比，有很多宗教信仰。就个人而言，我倾向于静态编译，但这确实是问题所在。虽然JIT编译从理论的角度来看具有各种优点，但我还没有看到任何证据表明这些优点是可以实现的 - 即据我所知，优势只能是理论上的。据我所知，没有人做过每一项研究来衡量当前状态，我们所能做的就是利用我们的偏见猜测，更深入挖掘我们的战壕，还有另外一组基准，其中一组语言被误用或者是只是简单无关紧要。
要回答这个问题，我真的需要回答两个（或三个）问题：
最近的研究比任何几年前的研究都更有价值。
直接比较可能是不可行的，但只要进行两次真正的经验证据的真实研究就会很好;我意识到这可能是不可能实现的，至少在大多数人都同意结果的程度上。我知道benchmarking game，我怀疑这是我们最接近或将要进行真正研究的。
答案 0 :(得分：0)
没有JIT 种语言，但有许多JIT 语言实现。
编程语言是某些技术报告中的规范（通常用英语写成）。
编程语言规范的一个很好的例子是R5RS（Scheme的一些变体）。您可以找到该语言的JIT编译和解释（以及AOT - 编译）实现。
R5RS中没有任何内容禁止（或暗示）Scheme的JIT实现。
即使像C ++ 11这样强大的编译语言也可以理论进行JIT编译。这通常是不值得的。
顺便说一句，你可以找到C的JIT实现（例如，tinycc）。您还可以找到C（或C ++）的解释器。另请参阅Cling。你会发现几个JIT-ing库。在libgccjit和LLVM中查找实例;它们实际上并不是那么“及时”（但它们似乎是这样的，但是在内部生成一些汇编程序文件;实质上，它们是足够快的AOT编译器，实际上可以用作JIT编译器）。但是asmjit更像是“JIT”-y。
实际上，计算机足够快，你可以将一些东西编译成C，运行它的GCC编译（进入一些临时插件），因此编译每个REPL交互到（dlopen - ed） C代码。 （FWIW，我在我的旧MELT事情中这样做了。）
在Self上阅读旧的Ungar博士论文。它做了某种JIT，它在某些罕见的情况下是如此缓慢（有时需要一整天的CPU）它可能已经显示为AOT。
同时查看SBCL。它编译为每次REPL交互的机器代码。
另请阅读J.Pitrat关于CAIA系统的博客。
在某些方面， JIT只是一个流行词。（它可能与程度和优化方式有关，特别是因为它可以执行“运行上下文”相关的优化;但请阅读{ {3}}）。