5

In which respects "Just In Time" compilation is better than "Ahead Of Time" compilation? And vice versa.

Is AOT same as direct native compilation?

closed as too broad by Ixrec, user40980, durron597, gbjbaanb, jwenting Sep 10 '15 at 11:14

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    I assume you mean "Just-In-Time" vs. "Ahead-Of-Time" compilers? – Dean Harding Apr 7 '11 at 4:45
  • @Dean Harding You are right. Edited the question for clarity. – Gulshan Apr 7 '11 at 5:59
8

Just-in-time compilation usually uses profiling information (like "how many times has this method been executed up to now") to determine how aggressively a given method should be compiled, and is usually included in the execution platform. JIT was brought into focus with the early versions of Java as they could only do simple interpretation, but with hooks allowing for external JIT modules to be plugged in allowing for vast improvements of execution speed.

Ahead-of-time compilation is - to my knowledge - a term coined to complement the JIT concept, and usually reflects a compilation step done before execution which rarely includes profiling information (so all methods are compiled equally hard). The optimization step is finished at runtime, so it does not need to be present at execution time. This mean that the execution environment does not need to be as big as in the JIT-environment.

One of the big advantages of JIT-compilation, is that it allows directly targetting the exact hardware at each run utilizing things like SSE3 or AltiVec, instead of having to compile to a common subset available on all platforms.

Note, however, that the JIT-process is usually hard to predict what it will do. You generally cannot figure out how to "trick" it to do something special with gnarly code, as it may change in the next release. This means that it is very important to write clean, simple code giving the JIT the best possible conditions to do its work.

Not the answer you're looking for? Browse other questions tagged or ask your own question.