为什么Java字节码方法中使用的局部变量数量不是最经济的？

Question

我有一段简单的Java代码：

public static void main(String[] args) {
    String testStr = "test";
    String rst = testStr + 1 + "a" + "pig" + 2;
    System.out.println(rst);
}

使用Eclipse编译器编译它，并使用AsmTools检查字节码。它显示：

​

​

该方法有三个局部变量。参数在槽0中，而槽1和2被认为是代码使用的。但是我认为两个局部变量就足够了--索引0无论如何都是参数，而且代码只需要多一个变量。

为了看我的想法是否正确，我编辑了文本字节码，将局部变量的数量减少到2个，并调整了一些相关的说明：

​

​

我用AsmTools重新编译了它，它运行得很好！

那么，为什么Javac或Eclipse编译器不进行这种优化来使用最小的局部变量呢？

Answer 1

仅仅是因为Java从实时编译器那里获得了性能。

您在Java源代码中所做的，甚至在类文件中显示的内容，都不是在运行时支持性能的东西。当然，你不应该忽视这一部分，但只有在不犯“愚蠢的错误”的意义上。

意思: jvm在运行时决定一个方法是否值得转换为(高度优化的！)机器代码。如果jvm决定“不值得优化”，那么为什么要通过在其中进行大量的优化来使javac变得更复杂和更慢呢？加号:输入的字节码越简单和基本，JIT就越容易分析和改进输入！

Answer 2

有几个原因。首先，这是没有必要的表现。JVM已经在运行时对事情进行了优化，因此没有必要向编译器添加冗余复杂性。

但是，这里没有人提到的另一个主要原因是调试。使字节码尽可能接近原始源，使其更易于调试。

Answer 3

嗯，你只是在两个完全独立的地方之间建立了一个虚假的依赖关系。这意味着JIT编译器需要更复杂/更慢，才能解开更改并返回到原始字节码，或者在它可以进行的优化方面受到限制。

请记住，Java编译器在您的开发(或构建)机器上只运行一次。是JIT编译器知道它正在运行的硬件(和软件)。Java编译器需要创建简单、直接的代码，以便JIT处理和优化(或者，在某些情况下，可以解释)。没有什么理由对字节码本身进行过度优化--您可能会减少几个字节的可执行文件大小，但是为什么要麻烦呢?特别是如果结果要么是CPU效率较低，要么是JIT编译时间更长？

我现在还没有进行实际测试的环境，但我确信JIT将从两个字节码中生成相同的可执行代码(在.NET中当然会这样做，这在许多方面是相似的)。