CODEWITHSUNDEEP
javajvmjit
kmdent
kmdent

Reputation: 1587

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

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?

Upvotes: 7

Views: 1097

Answers (4)

pazukdev
pazukdev

Reputation: 133

JIT compiler optimizes code on the fly using program execution statistics. For example, "hotpath" optimization counts the number of hits in one part of the program and generates machine code only for those parts of the code where the program is executed frequently. This allows the JIT optimizer to place pieces of frequently executed machine code close together so that they fit into the processor's cache. This allows the JIT compiler to outperform precompiled machine code.

Upvotes: 0

mikera
mikera

Reputation: 106351

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.

Upvotes: 2

Burleigh Bear
Burleigh Bear

Reputation: 3314

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.

Upvotes: 5

Marcelo Cantos
Marcelo Cantos

Reputation: 185852

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.

Upvotes: 2

Related Questions