Why doesn't Java's JIT compiler translate everything to native code?

Question

I have been looking into the Java JIT compiler and i cannot figure out why some of the code is still interpreted. Why doesn't the JIT compiler translate everything to native code? Interpretation is much slower, am I missing something?

Answer 1

It's all a matter of tradeoffs

• the time taken to compile + execute code can be longer than the time to interpret once
• you can often optimise things much more efficiently if you have statistics on branching, etc
• some things can't be compiled (anything that does RTTI, probably)
• some things you don't want compiled (line numbers for stack traces, etc)
• I'm sure there's others.

Answer 2

If you are running a JVM like HotSpot, it JIT-compiles opportunistically, only focusing on code that executes frequently. It determines which code to optimise on the fly by counting frequency of each code block (or method — I'm not sure which). Consequently, at startup time, everything is interpreted.

The intent behind this is allow for much more aggressive and expensive optimisations by only requiring a small fraction of the code to be optimised.

Answer 3

Two main reasons:

• Interpretation is not slower if code is only run a few times. The cost of compilation alone can be much more expensive than interpreting the code if it is only run a few times.
• While interpreting it is possible to gather statistics at runtime that are useful for optimising the code later. For example, you can count how many times a particular branch is taken and optimise the code to be faster for the more frequent case. This kind of trick can make JIT compilation better than ahead-of-time compilation (which doesn't have the opportunity to exploit the runtime statistics)

Hence the Java JIT takes a sensible strategy: don't compile until you observe that the same code is being run multiple times, at which point you have evidence that doing the compilation is probably worthwhile and you are able to make some additional optimisations.