基于逃逸分析的优化是Proguard计划中的一个功能。与此同时,是否已经存在像Proguard一样需要逃逸分析的优化工具?
基于逃逸分析的优化是Proguard计划中的一个功能。与此同时,是否已经存在像Proguard一样需要逃逸分析的优化工具?
是的,我认为Soot框架执行逃逸分析。
你对编译器级别的逃逸分析有什么期望?Java类更像是C语言中的目标文件 - 它们在JVM中链接,因此逃逸分析只能在单个方法级别上执行,这具有有限的实用性,并且会妨碍调试(例如,您将无法通过某些代码行)。
在Java的设计中,编译器相当愚蠢 - 它检查正确性(如Lint),但不尝试进行优化。聪明的部分放在JVM中 - 它使用多种优化技术,在当前平台和条件下产生良好的性能代码。由于JVM知道当前加载的所有代码,因此它可以假设比编译器更多,并执行推测性优化,一旦假设无效即可撤销。HotSpot JVM可以在函数运行时(例如,在循环的中间,随着代码变得“热”)动态地用更优化的版本替换代码。
当不在调试器中时,具有非重叠生命周期的变量会被折叠,不变量会被提升出循环,循环会被展开等。所有这些都发生在JIT编译的代码中,并且取决于在该函数中花费的时间(在从未运行的代码上花费时间进行优化没有多大意义)。如果我们预先执行其中一些优化,JIT将拥有更少的自由度,整体结果可能是净负面。
另一个优化是堆栈分配不逃逸当前方法的对象 - 在某些情况下会执行此操作,尽管我在某个地方读到过一篇论文,其中详细的逃逸分析所需的时间与通过优化获得的时间之间的比较表明它不值得,因此当前策略更具启发性。
总的来说,JVM对您的原始代码了解越多,它就能够更好地优化它。而JVM所做的优化不断改进,因此我认为只有在谈论像手机这样非常受限和基本的JVM时才考虑编译代码优化。在这些情况下,您无论如何都要通过混淆器运行应用程序(缩短类名等)。
-XX:+DoEscapeAnalysis
来启用它。详情请参阅:http://java.sun.com/javase/6/webnotes/6u14.html - Jesper