7

Optimizations based on escape analysis is a planned feature for Proguard. In the meantime, are there any existing tools like proguard that already do optimizations which require escape analysis?

Jeremy Bell
  • 5,253
  • 5
  • 41
  • 63
  • 2
    Sun's HotSpot JVM has escape analysis built-in since Sun Java 6 Update 14. You need to enable it with `-XX:+DoEscapeAnalysis`. See: http://java.sun.com/javase/6/webnotes/6u14.html – Jesper Jun 10 '10 at 20:28
  • 1
    Escape analysis is disabled on u18 and later. – gustafc Jun 10 '10 at 20:50
  • 1
    It is also only available on the server VM, and not available at all on the android's dalvik vm, nor any javaME variant that I'm aware of. The point is to do escape analysis ahead of time so you get the benefits even if it's not enabled in the VM. – Jeremy Bell Jun 10 '10 at 20:55
  • Are you sure that those optimizations would make a difference? I'd suggest you try benchmarking your code on HotSpot with and without escape analysis. – Dmitry Leskov Jul 02 '10 at 14:33
  • 2
    It's reenabled in u21 and is now enabled by default: http://download.java.net/jdk6/6u21/promoted/b05/changes/JDK6u21.list.html (see id 6873799) – Mene Jul 15 '10 at 15:27
  • That's good, but it doesn't help me. I'm not using HotSpot, I'm using dalvik VM on android, which will likely never have an expensive JIT optimization such as escape analysis (they favor speedy startup times over absolute performance). – Jeremy Bell Jul 16 '10 at 20:15
  • Jeremy, did you make progress on whole program analysis of Android application? Anything to share here? – dacongy Apr 08 '12 at 20:01

2 Answers2

3

Yes, I think the Soot framework performs escape analysis.

Joa Ebert
  • 6,565
  • 7
  • 33
  • 47
  • 1
    How do you configure soot to do whole program optimizations (such as escape analysis), on android applications? It appears the framework simply assumes you have a main function and builds the call tree from there only, but android applications don't have main functions. Proguard lets you keep multiple classes, so that each method in the class becomes a new "root" in the call tree analysis for whole program optimization. I can't find a similar option for soot. – Jeremy Bell Jun 21 '10 at 10:44
  • Going to mark this as the answer. I opened a new question specifically about soot and whole program optimization without a main function here: http://stackoverflow.com/questions/3093648/how-to-use-soot-to-do-whole-program-optimizations-on-android-applications – Jeremy Bell Jun 22 '10 at 13:42
1

What do you expect from escape analysis on compiler level? Java classes are more like object files in C - they are linked in the JVM, hence the escape analysis can be performed only on single-method level, which is of limited usability and will hamper the debugging (e.g. you will have lines of code through which you can not step).

In Java's design, the compiler is quite dumb - it checks for correctness (like Lint), but doesn't try to optimize. The smart pieces are put in the JVM - it uses multiple optimization techniques to yield well performing code on the current platform, under the current conditions. Since the JVM knows all the code that is currently loaded it can assume a lot more than the compiler and perform speculative optimizations which are reverted the moment the assumptions are invalidated. HotSpot JVM can replace code with more optimized version on the fly while the function is running (e.g. in the middle of a loop as the code gets 'hotter').

When not in debugger, variables with non-overlapping lifetimes are collapsed, invariants are hoisted out of loops, loops are unrolled, etc. All this happens in the JIT-ted code and is done dependent on how much time is spent in this function (it does not make much sense to spend time optimizing code that never runs). If we perform some of these optimizations upfront, the JIT will have less freedom and the overall result might be a net negative.

Another optimization is stack allocation of objects that do not escape the current method - this is done in certain cases, though I read a paper somewhere that the time to perform rigorous escape analysis vs the time gained by optimizations suggests that it's not worth it, so the current strategy is more heuristic.

Overall, the more information the JVM has about your original code, the better it can optimize it. And the optimizations the JVM does are constantly improving, hence I would think about compiled code optimizations only when speaking about very restricted and basic JVMs like mobile phones. In these cases you want to run your application through obfuscator anyway (to shorten class names, etc.)

ddimitrov
  • 3,293
  • 3
  • 31
  • 46
  • I am only interested in the dalvik VM, and I am locked into targeting the 1.5/1.6 platform for at least another 6 months, and 2.1 for at least a year. Even if I could target 2.2, the JIT is specifically tuned to have very fast startup times and spend as little time as possible in JIT, so expensive optimizations like escape analysis plus scalar replacement are completely out. What I am looking for specifically is a static bytecode optimizer which can do scalar replacement based off of escape analysis for short-lived temporary objects. – Jeremy Bell Jun 21 '10 at 10:42