What are the differences between a Just-in-Time-Compiler and an Interpreter?

What are the differences between a Ju开发者_StackOverflow中文版st-in-Time-Compiler and an Interpreter, and are there differences between the .NET and the Java JIT compiler?

I've always found that a more abstract explanation sometimes helps. Let's say that you are trying to ask everyone in Mexico "Hello. How are you?" (your source language) Of course, you'll first need to translate it to Spanish (the native language of the country). That translation would be "Hola. Como estas?"

If you know Spanish, there would be no need for you to translate (native code / assembler). You just ask "Hola. Como estas?"

If you don't know Spanish, there are 3 ways to deal with it.

The first is to get a Spanish Dictionary (a compiler) and look up what the Spanish words are before you go. Perhaps you realize that "Hola. Que tal?" is one syllable shorter (compiler optimization) and use that instead. This is language compilation; you are converting the information to the native language beforehand.

The second is where you look up the words in the Spanish Dictionary while you are standing in front of the first person and then store the result (looking up the words just-in-time). The advantage here is that you could get a Mandarin Dictionary and then do the same experiment in China without having to keep ten sticky notes (binaries for different platforms) of translated phrases.

The third is where you look up the words while you are standing in front of each person. In essence, you interpret the words for each person separately (you act as an interpreter). The advantage here is that any changes are instantly reflected with the next person (you could change to asking "Hello. What color is your dog?" without having to fly home and restart - you don't need to recompile the phrases).

• Translating beforehand means you can ask people fastest (pre-compiliation); you don't need to even bring the dictionary with you.
• Translating when you see the first person in each country is almost as fast as translating beforehand but still allows you to travel to multiple countries without needing to go home to get a dictionary but means that you need to bring several dictionaries with you (a platform independent runtime).
• Translating on demand is much slower but allows you to change the words without traveling home (source distributed language).

Just-in-time compilation is the conversion of non-native code, for example bytecode, into native code just before it is executed.

From Wikipedia:

JIT builds upon two earlier ideas in run-time environments: bytecode compilation and dynamic compilation. It converts code at runtime prior to executing it natively, for example bytecode into native machine code.

An interpreter executes a program. It may or may not have a jitter.

Again, from Wikipedia:

An interpreter may be a program that either

1. executes the source code directly
2. translates source code into some efficient intermediate representation (code) and immediately executes this
3. explicitly executes stored precompiled code made by a compiler which is part of the interpreter system

Both the standard Java and .NET distributions have JIT compilation, but it is not required by the standards. The JIT compiler in .NET and C# are of course different because the intermediate bytecode is different. The principle is the same though.

An interpreter generates and executes machine code instructions on the fly for each instruction, regardless of whether it has previously been executed.
A JIT caches the instructions that have been previously interpreted to machine code, and reuses those native machine code instructions thus saving time & resources by not having to re-interpret statements that have already been interpreted.

tl;dr

Interpreter: takes only one instruction at a time for execution

Just-in-time: takes a block of code at once and compile it before execute. so has plenty room for optimization

The question of whether an execution engine is a compiler or an interpreter can be answered very simply by considering what happens if a routine is executed 1,000 times. If code within the execution engine will have to examine some particular representation of the code 1,000 times, the execution engine is an interpreter of that representation. If code within the execution the execution engine will only have to examine that particular representation of the code some smaller number of times (typically, though not necessarily, once), it is a compiler or translator of that representation. Note that it is very common for an execution engine to take input code and convert it to some other form which can be examined more readily. Such an execution engine would combine a compiler or translator of the former form with an interpreter of the latter form.

Note that interpreters very seldom produce any form of machine code. Just about the only time an interpreter will produce machine code is when a statement is supposed to perform some operation that really cannot be done any other way. For example, if a BASIC interpreter running on the 8080 encounters the instruction "OUT 100,5", it would typically perform that operation by storing D3 64 C9 (OUT 64h / RET) into three consecutive bytes at some fixed address, loading A with 5, and CALLing that address. The interpreter may technically be generating machine code, but if one were to perform the same OUT instruction 500 times, the interpreter would have to re-generate the machine code every time.

JIT compiler produces binary machine codes translating block source code. Interpreter translates line by line.

When the first time a class is referenced the JIT Execution Engine re-compiles the .class files (primary Binaries) generated by Java Compiler containing JVM Instruction Set to Binaries containing HOST system’s Instruction Set. JIT stores and reuses those recompiled binaries from Memory going forward, there by reducing interpretation time and benefits from Native code execution.

On the other hand a plain old java interpreter interprets one JVM instruction from class file at a time and calls a procedure against it.

Find a detail comparison here http://bitshub.blogspot.com/2010/01/Flavors-of-JVM.html

When you compile a Microsoft.NET language, the complier generates code written in the Microsoft Intermediate Language (MSIL). MSIL is a set of instructions that can quickly be translated into native code.

A Microsoft.NET application can be run only after the MSIL code is translated into native machine code. In .NET Framework, the intermediate language is complied "just in time" (JIT) into native code when the application or component is run instead of compiling the application at development time.

more info