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