我正在使用Java 中的玩具解释器,我正在考虑尝试编写一个可以为 Java 虚拟机生成字节码的简单编译器。这让我想到,针对 JVM 和 CLI 等虚拟机的编译器需要做多少优化?
即时 (JIT) 编译器是否进行常量折叠、窥孔优化等?
我正在使用Java 中的玩具解释器,我正在考虑尝试编写一个可以为 Java 虚拟机生成字节码的简单编译器。这让我想到,针对 JVM 和 CLI 等虚拟机的编译器需要做多少优化?
即时 (JIT) 编译器是否进行常量折叠、窥孔优化等?
我将添加两个链接,它们很好地解释了Java 的字节码以及运行时 JVM 的一些各种优化。
优化是使 JVM 成为长时间运行应用程序的环境的原因,您可以打赌,SUN、IBM 和朋友正在尽最大努力确保他们能够以尽可能高效的方式优化您的字节码和 JIT 编译的代码。
话虽如此,如果你认为你可以预先优化你的字节码,那么它可能不会造成太大的伤害。
然而,值得注意的是,当仅使用 Java 编译器倾向于构造的那种字节码时,JVM 往往会表现得更好(而不是崩溃)。当发生正确但不同于 javac 产生的字节码排列时,错过优化甚至 JVM 崩溃的情况并非未知。希望这种事情现在已经成为过去,但可能需要注意。
在大多数情况下,优化字节码可能是矛盾的
我不认为那是真的。提升循环不变量和传播常量之类的优化永远不会受到伤害,即使 JVM 足够聪明,可以通过减少代码的工作量来独立完成这些优化。
ProGuard 之类的混淆器将为您执行许多静态优化您的字节码。
HotSpot 编译器在运行时会比在编译时更好地优化你的代码——毕竟它有更多的信息可以使用。唯一应该优化字节码而不是算法的情况是,当您针对移动设备(例如黑莓)时,该平台的 JVM 功能不足以在运行时优化代码,只能执行字节码。
在大多数情况下,优化字节码可能是矛盾的。除非您控制虚拟机,否则您不知道它如何加速代码执行(如果有的话)。编译器需要了解 VM 的详细信息才能生成优化的代码。
阿塞拉芬注意事项:
在某些有限的情况下,优化非嵌入式应用程序的字节码也很有用:
当通过网络交付代码时,例如对于 WebStart 应用程序,以最小化交付/缓存大小,因为您不一定知道客户端的能力/速度。
对于您知道对性能至关重要并在(例如)HotSpot 有时间收集任何统计信息之前在启动时使用的代码。
同样,一个好的优化器/混淆器执行的转换可能非常有用。