我在弄乱Java中的玩具解释器，在考虑尝试编写一个可以为Java虚拟机生成字节码的简单编译器。是什么让我想到了，针对虚拟机(例如JVM和CLI)的编译器需要完成多少优化？

准时(JIT)编译器会进行不断折叠，窥孔优化等工作吗？

解决方案

回答

在大多数情况下，优化字节码可能是矛盾的。除非我们控制VM，否则不知道它将如何加快代码执行速度(如果有的话)。编译器需要了解VM的详细信息才能生成优化的代码。

回答

Optimising bytecode is probably an oxymoron in most cases

我认为那不是真的。诸如提升循环不变式和传播常量之类的优化，即使JVM足够聪明，可以通过使代码减少工作量来简单地自己完成，也永远不会受到损害。

回答

我将添加两个链接，这些链接很好地解释了Java的字节码以及运行时JVM的各种优化。

回答

优化是使JVM在长时间运行的应用程序环境中可行的原因，我们可以打赌SUN，IBM和朋友正在尽最大努力确保他们可以以有效的方式优化字节码和JIT编译的代码。

话虽如此，如果我们认为我们可以预先优化字节码，那么它可能不会造成太大的伤害。

值得一提的是，当仅使用Java编译器倾向于构造的字节码来呈现JVM时，JVM往往会表现得更好(并且不会崩溃)。当字节码发生正确排列但与javac产生的排列不同时，会错过优化甚至使JVM崩溃都是未知的。希望这种事情现在已经过去了，但是可能需要注意。

回答

ProGuard等混淆器将为字节码执行许多静态优化。

回答

毕竟，HotSpot编译器将在运行时更好地优化代码，而编译时它可能会提供更多信息。仅当针对移动设备(例如Blackberry)时，才需要优化字节码而不是仅优化算法，而该平台的JVM的功能不足以在运行时优化代码，而仅执行字节码。

回答

请注意Aseraphim：

在某些有限的情况下，为非嵌入式应用程序优化字节码也很有用：

• 当通过有线方式传递代码时(例如，对于WebStart应用程序)，以最小化可传递内容/缓存的大小，并且因为我们不一定了解客户端的功能/速度。
• 对于我们知道的性能至关重要的代码，这些代码在HotSpot有时间收集任何统计信息之前(例如)在启动时使用。

同样，良好的优化器/混淆器执行的转换可能非常有帮助。