静态java字节码优化器（如proguard）与转义分析？

Question

基于逃逸分析的优化是Proguard的计划功能。与此同时，是否有像proguard这样的现有工具已经进行了需要转义分析的优化？

Answer 1

是的，我认为Soot framework执行转义分析。

Answer 2

您对编译器级别的转义分析有何期待？ Java类更像是C中的目标文件 - 它们在JVM中链接，因此只能在单一方法级别执行转义分析，这种方法具有有限的可用性并且会妨碍调试（例如，您将通过代码行完成你不能一步）。

在Java的设计中，编译器非常愚蠢 - 它检查正确性（如Lint），但不尝试优化。智能部件放在JVM中 - 它使用多种优化技术在当前条件下在当前平台上生成性能良好的代码。由于JVM知道当前加载的所有代码，因此它可以承担比编译器更多的代码并执行推测优化，这些优化会在假设失效时恢复。当函数运行时，HotSpot JVM可以动态地替换具有更优化版本的代码（例如，当代码变得“更热”时，在循环的中间）。

当不在调试器中时，具有非重叠生存期的变量将被折叠，不变量从循环中提升，循环被展开等等。所有这些都发生在JIT-ted代码中，并且取决于花费了多少时间。这个功能（花时间优化从未运行的代码没有多大意义）。如果我们预先执行其中一些优化，那么JIT将具有较少的自由度，并且整体结果可能是净负值。

另一个优化是不会逃避当前方法的对象的堆栈分配 - 这在某些情况下已经完成，尽管我在某处读过一篇论文，表明执行严格逃逸分析的时间与优化所获得的时间相比，这表明它不值得它，所以目前的策略更具启发性。

总体而言，JVM对原始代码的信息越多，就越能对其进行优化。 JVM所做的优化也在不断改进，因此我只会在讨论非常受限制的基本JVM（如手机）时考虑编译代码优化。在这些情况下，您希望通过混淆器运行您的应用程序（缩短类名等）。