Java 优化：仅字节码与 JIT
为 Android 设备开发游戏，我需要针对根本没有 JIT、仅依赖字节码优化的设备。我想知道这些优化的集合是否为空...
实际上，java编译器（最难的，javac，不是JIT）是否会进行任何优化，例如将a / 4转换为a >> > 2 ?或者说每一次优化都是 JIT 的工作？
Developping games for android devices, I need to target devices that have no JIT at all, and only rely on bytecode optimizations. I wonder if the set of these optimization is empty or not...
Actually, does the java compiler (the hard one, javac, not a JIT) makes any optimization like transforming a / 4 into a >> 2 ? Or is every optimization a work for the JIT ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
标准 Java 编译器会进行一些优化，但将大部分优化留给 JIT。
JIT 确切地知道程序正在哪个处理器上运行，并且还可以访问运行时信息，因此它可以比 Java 编译器提前进行更多的优化。此外，提前进行广泛的优化可能会在一定程度上“混淆”字节代码，从而使 JIT 更难对其进行优化。
我不知道 Google 编译器在将 Java 字节代码转换为 Dalvik 代码时会做什么 - 它可能会进行更广泛的优化。
也许这个工具对您有用：Dalvik Optimization and Verification With dexopt
顺便说一下，你提到的例子并不总是有效；将
a / 4转换为a >>> 2不保证您的程序在任何处理器上运行得更快。我曾经在某处读过一篇文章（抱歉，现在找不到......），它解释了在（我认为）现代 x86 处理器上，a >> 2甚至可能比a / 4慢。无论如何，不要进行过早的优化，例如将
a / 4转换为a >>> 2在源代码中手动执行，除非您有真正的证据（来自性能测量）表明值得这样做。The standard Java compiler does some optimizations, but it leaves most of them to the JIT.
The JIT knows on which processor exactly the program is running and also has access to runtime information, and therefore it can do more optimizations than the Java compiler could do in advance. Also, doing extensive optimizations in advance could "obfuscate" the byte code somewhat, making it harder for the JIT to optimize it.
I don't know what Google's compiler does when it translates your Java byte code to Dalvik code - it might be doing more extensive optimizations.
Maybe this tool will be useful for you: Dalvik Optimization and Verification With dexopt
By the way, the example you mention is not always valid; transforming
a / 4intoa >> 2is not guaranteed to make your program run faster on any processor. I read an article somewhere once (sorry, can't find it right now...) that explained that on (I think) modern x86 processors,a >> 2might even be slower thana / 4.In any case, don't do premature optimizations like transforming
a / 4toa >> 2by hand in your source code unless you have real evidence (from performance measurements) that it's worthwhile to do it.如果您的执行平台确实执行字节码，那么您对诸如
a / 4之类的东西的直觉会比a >>> 更快。 2可能是错误的。您需要进行一些认真的应用程序分析，以弄清楚：FWIW，
javac编译器不太可能尝试微优化算术。最佳的本机代码取决于实际执行平台的硬件，如果 javac 尝试优化字节码，则可能会使 JIT 编译器的任务变得更加困难。If your execution platform is really executing bytecodes, your intuitions about things like
a / 4being faster thana >> 2are likely to be wrong. You need to do some serious application profiling to figure out:FWIW, the
javaccompiler is unlikely to attempt to micro-optimize arithmetic. The optimal native code depends on the hardware of the actual execution platform, and if javac attempted to optimize the bytecodes it is likely to make the task of the JIT compiler more difficult.