Java字节码中为何使用goto跳转而非直接执行ireturn返回？

我编译了如下Java方法：

public static final boolean equalTo(final int x, final int y) {
    return x == y;
}

使用javap反编译后，得到的对应字节码如下：

public static final boolean equalTo(int, int);
    descriptor: (II)Z
    flags: (0x0019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL
    Code:
      stack=2, locals=2, args_size=2
         0: iload_0
         1: iload_1
         2: if_icmpne     9
         5: iconst_1
         6: goto          10
         9: iconst_0
        10: ireturn
      LineNumberTable:
        line 72: 0
      StackMapTable: number_of_entries = 2
        frame_type = 9 /* same */
        frame_type = 64 /* same_locals_1_stack_item */
          stack = [ int ]

我使用ASM框架生成和上述一致的字节码时，尝试将其中的goto 10指令替换为ireturn，调整后的字节码功能完全一致，还消除了一次跳转，减小了StackMapTable的体积。我知道字节码仅为中间表示，不代表最终机器执行逻辑，但想了解javac编译器为何默认生成带goto跳转的字节码，而非更精简的直接返回版本？

解答 #

javac默认生成带goto的字节码而非更精简版本，主要有以下几个原因：

• 字节码优化优先级极低，优化逻辑全部下沉到JIT
  javac作为前端编译器，核心职责是把Java源码转换成符合虚拟机规范的字节码，默认几乎不做任何字节码层面的性能优化，所有优化工作都交给运行时的JIT编译器处理。JIT能拿到程序运行时的实际调用数据、CPU架构信息，优化效果远好于前端编译器，这种字节码里的冗余goto在JIT编译成机器码的时候会被直接消除，完全不会影响最终执行性能，前端做这种优化没有实际收益。
• 通用代码生成模板的固定输出，降低javac自身复杂度
  你看到的这个goto是javac生成条件返回逻辑的通用模板产物：不管if分支的返回值是简单的true/false常量，还是复杂的计算表达式、方法调用，javac都会统一走「条件跳转到else分支→then分支生成返回值计算逻辑→跳转到统一的return出口→else分支生成返回值计算逻辑→执行return」的逻辑。如果要针对当前这种简单场景做特殊优化，把goto替换成ireturn，需要额外增加语法树判断、字节码生成的特殊分支，反而会提升javac自身的代码复杂度，增加出bug的概率，投入产出比极低，javac开发团队完全没必要做这种优化。
• 通用模板生成的字节码兼容性、稳定性更高
  通用模板生成的字节码结构固定，StackMapTable也按照固定规则生成，不会出现字节码校验失败的问题，能兼容所有符合规范的JVM版本。如果要针对特殊场景做精简，反而需要额外调整StackMapTable等辅助信息的生成逻辑，得不偿失。

内容的提问来源于stack exchange，提问作者dminuoso