Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

Is AOT same as direct native compilation?

share|improve this question

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

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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
up vote 7 down vote accepted

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.

share|improve this answer

protected by gnat Sep 9 '15 at 20:45

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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