为什么 javac 连简单的代码都不优化？答案

【问题标题】：Why javac does not optimize even simple code?为什么 javac 连简单的代码都不优化？
【发布时间】：2012-11-28 18:19:43
【问题描述】：

给定以下代码：

public class MainClass {
    public static int f(){
        int i=0;
        i++;
        return i;
    }
}

编译器 javac 生成以下代码：

Compiled from "MainClass.java"
public class latte_jvm.MainClass {

  public static int f();
    Code:
       0: iconst_0
       1: istore_0
       2: iinc          0, 1
       5: iload_0
       6: ireturn
}

函数 f 做了非常简单的事情——它只返回 1。它的翻译如此直接，以至于我很难相信 java 编译器会进行任何优化。为什么 java 编译器的创建者决定在编译阶段不做这样的优化？

【问题讨论】：

编译器不是唯一的优化器。 JIT 编译器可能会在以后对其进行优化。
我认为大多数优化都是由 JIT 在运行时完成的。

标签： java optimization javac

【解决方案1】：

翻译得这么直接，让我很难相信java编译器做了任何优化。

确实如此。大多数 Java 优化都是在 JIT 时间执行的。 Java 维护人员很久以前就发现，在许多情况下，在编译时执行的优化实际上阻碍了在 JIT 时进行的更重要的优化。

几年来，-O 命令行参数什么也没做——而且是故意的。

【讨论】：

但是，它不能只做iconst_1; ireturn吗？
@Marcin 可以，但这需要付出努力，而 JIT 已经做到了。
+1 恕我直言，javac 所做的一些优化既是诅咒也是祝福。例如内联编译时常量。
上次我有理由考虑 HotSpot，它只是 JIT 经常使用的方法 - 然后我突然想到，那些字节码在 VM 上直接执行的方法不会得到太多优化/有吗？
@jstephenson：Hotspot 逐步优化 - 它可能会在第一次执行方法时选择不 JIT（这适用于仅执行一次的启动代码），但随后它将适用逐步“更难”的优化。它也可以做出假设，例如“没有人会覆盖这个方法，所以它可以被内联”，然后如果以后有必要的话，unoptimize。美妙而坦率地可怕。

【解决方案2】：

此外，通过将优化转移到 JVM，所有基于 JVM 的语言都可以受益。编译器（不仅仅是 javac）的工作相对容易一些；语言发明者不必是优化专家。

【讨论】：