c++ - Java 字节码的即时编译

Question

我们目前正在研究我们自己的 Java 虚拟机实现的 JIT 编译部分。我们现在的想法是将给定的 Java 字节码简单地转换为操作码，将它们写入可执行内存并直接调用到方法的开头。

假设给定的 Java 代码是:

int a = 13372338;
int b = 32 * a;
return b;

现在，采用了以下方法(假设给定的内存从 0x1000 开始并且返回值预期在 eax 中):

0x1000: first local variable - accessible via [eip - 8]
0x1004: second local variable - accessible via [eip - 4]
0x1008: start of the code - accessible via [eip]

Java bytecode | Assembler code (NASM syntax)
--------------|------------------------------------------------------------------
              | // start
              | mov edx, eip
              | push ebx
              |         
              | // method content
ldc           | mov eax, 13372338
              | push eax
istore_0      | pop eax
              | mov [edx - 8], eax
bipush        | push 32
iload_0       | mov eax, [edx - 8]
              | push eax
imul          | pop ebx
              | pop eax
              | mul ebx
              | push eax
istore_1      | pop eax
              | mov [edx - 4], eax
iload_1       | mov eax, [edx - 4]
              | push eax
ireturn       | pop eax
              |         
              | // end
              | pop ebx
              | ret

这将像虚拟机一样简单地使用堆栈。
关于这个解决方案的问题是:

这种编译方法可行吗？

甚至有可能以这种方式实现所有 Java 指令吗？如何翻译诸如 athrow/instanceof 和类似命令之类的东西？

Answer 1

这种编译方法有效，易于启动和运行，并且至少消除了解释开销。但它会导致大量代码和非常糟糕的性能。一个大问题是，即使目标机器 (x86) 是寄存器机器，它也会 1:1 音译堆栈操作。正如您在发布的代码段(以及任何其他代码)中看到的那样，这总是会导致每个操作的多个堆栈操作操作码，因此它使用寄存器 - 见鬼，整个 ISA - 尽可能低效。

您还可以支持复杂的控制流，例如异常。这与在解释器中实现它没有太大区别。如果您想要良好的性能，您不想每次进入或退出 try 时都执行工作。堵塞。有一些方案可以避免这种情况，C++ 和其他 JVM 都使用它(关键字:零成本或表驱动的异常处理)。这些实现、理解和调试非常复杂和复杂，因此您应该首先使用更简单的替代方案。只要记住它。

至于生成的代码:第一个优化，您几乎肯定会需要的，是将堆栈操作转换为三个地址代码或使用寄存器的其他一些表示。有几篇关于这个及其实现的论文，所以除非你想要我，否则我不会详细说明。然后，当然，您需要将这些虚拟寄存器映射到物理寄存器上。寄存器分配是编译器构造中研究最深入的主题之一，至少有六种启发式方法在 JIT 编译器中使用相当有效且足够快。我最想知道的一个例子是线性扫描寄存器分配(专门为 JIT 编译创建)。

除此之外，大多数 JIT 编译器专注于生成代码的性能(与快速编译相反)使用一种或多种中间格式并以这种形式优化程序。这基本上是您对 Mill 编译器优化套件的运行，包括诸如常量传播、值编号、重新关联、循环不变代码运动等的老手——这些东西不仅易于理解和实现，而且还被描述过在三十年的文学作品中，包括教科书和维基百科。

上面的代码非常适合使用原语、数组和对象字段的直线代码。但是，您根本无法优化方法调用。每个方法都是虚拟的，这意味着内联甚至移动方法调用(例如在循环外)基本上是不可能的，除非在非常特殊的情况下。您提到这是针对内核的。如果您可以接受在没有动态类加载的情况下使用 Java 的子集，那么您可以通过假设 JIT 知道所有类来做得更好(但它将是非标准的)。然后你可以，例如，检测叶类(或更一般的方法，它们永远不会被覆盖)并内联它们。

如果您确实需要动态类加载，但希望它很少见，您也可以做得更好，尽管这需要更多的工作。优点是这种方法可以推广到其他事情，比如完全消除日志语句。基本思想是基于某些假设(例如，此 static 不会更改或未加载新类)专门化代码，然后在违反这些假设时取消优化。这意味着您有时必须在运行时重新编译代码(这是 硬 ，但并非不可能)。

如果你沿着这条路走得更远，它的逻辑结论是基于跟踪的 JIT 编译，它已应用于 Java，但 AFAIK 并没有证明它优于基于方法的 JIT 编译器。当您必须做出数十或数百个假设才能获得好的代码时，它会更有效，就像使用高度动态的语言一样。