i know that java programs are first compiled and a bytecode is generated which is platform independent. But my question is why is this bytecode interpreted in the next stage and not compiled even though compilation is faster than interpretation in general??
You answered your own question. Byte code is platform independent. If the compiled code was executed then it would not work on every OS. This is what C does and it is why you have to have one version for every OS.
As others have suggested, the JVM does actually compile the code using JIT. It is just not saved anywhere. Here is a nice quote to sum it up
In a bytecode-compiled system, source code is translated to an
intermediate representation known as bytecode. Bytecode is not the
machine code for any particular computer, and may be portable among
computer architectures. The bytecode may then be interpreted by, or
run on, a virtual machine. The JIT compiler reads the bytecodes in
many sections (or in full rarely) and compiles them interactively into
machine language so the program can run faster
The Java bytecode normally is compiled via Just-In-Time (JIT) compilation.
So you still end up with fully compiled native code being executed, the only difference is that this native code is generated by the JVM at runtime, rather than being statically generated at the time the source code is compiled (as would happen with C/C++).
This gives Java two big advantages:
By delaying the compilation until runtime, the bytecode remains fully portable across platforms
In some cases the JIT compiler can actually generate more optimised native code because it is able to exploit statistics gathered by examining the execution parths of the code at runtime.
The downside, of course, is that the JIT compiler needs to do it's work at application start-up, which explains why JVM applications can have a slightly long start-up time compared to natively compiled apps.
The basic premise of your question is not true. Most modern Java virtual machines do compile frequently-executed parts of the code into native machine code.
This is known as just-in-time compilation, or JIT for short.
A pretty good introduction to relevant Sun's (now Oracle's) technology can be found here.
The JVM uses Just in time compilation http://en.wikipedia.org/wiki/Just-in-time_compilation, so it's much faster than pure interpretation.
Byte code is platform independent. Once compiled into bytecode, it could run on any system.
As it says on Wikipedia,
Just-in-time compilation (JIT), also known as dynamic translation, is
a method to improve the runtime performance of computer programs.
I recommend you to read this article. Its gives the basic working of JIT compiler for Java VM.
JIT compilers alter the role of the VM a little by directly compiling
Java bytecode into native platform code, thereby relieving the VM of
its need to manually call underlying native system services. The
purpose of JIT compilers, however, isn't to allow the VM to relax. By
compiling bytecodes into native code, execution speed can be greatly
improved because the native code can be executed directly on the
underlying platform.
When JIT compiler is installed, instead of the VM calling the
underlying native operating system, it calls the JIT compiler. The JIT
compiler in turn generates native code that can be passed on to the
native operating system for execution. The primary benefit of this
arrangement is that the JIT compiler is completely transparent to
everything except the VM.
Related
What does a JIT compiler specifically do as opposed to a non-JIT compiler? Can someone give a succinct and easy to understand description?
A JIT compiler runs after the program has started and compiles the code (usually bytecode or some kind of VM instructions) on the fly (or just-in-time, as it's called) into a form that's usually faster, typically the host CPU's native instruction set. A JIT has access to dynamic runtime information whereas a standard compiler doesn't and can make better optimizations like inlining functions that are used frequently.
This is in contrast to a traditional compiler that compiles all the code to machine language before the program is first run.
To paraphrase, conventional compilers build the whole program as an EXE file BEFORE the first time you run it. For newer style programs, an assembly is generated with pseudocode (p-code). Only AFTER you execute the program on the OS (e.g., by double-clicking on its icon) will the (JIT) compiler kick in and generate machine code (m-code) that the Intel-based processor or whatever will understand.
In the beginning, a compiler was responsible for turning a high-level language (defined as higher level than assembler) into object code (machine instructions), which would then be linked (by a linker) into an executable.
At one point in the evolution of languages, compilers would compile a high-level language into pseudo-code, which would then be interpreted (by an interpreter) to run your program. This eliminated the object code and executables, and allowed these languages to be portable to multiple operating systems and hardware platforms. Pascal (which compiled to P-Code) was one of the first; Java and C# are more recent examples. Eventually the term P-Code was replaced with bytecode, since most of the pseudo-operations are a byte long.
A Just-In-Time (JIT) compiler is a feature of the run-time interpreter, that instead of interpreting bytecode every time a method is invoked, will compile the bytecode into the machine code instructions of the running machine, and then invoke this object code instead. Ideally the efficiency of running object code will overcome the inefficiency of recompiling the program every time it runs.
JIT-Just in time
the word itself says when it's needed (on demand)
Typical scenario:
The source code is completely converted into machine code
JIT scenario:
The source code will be converted into assembly language like structure [for ex IL (intermediate language) for C#, ByteCode for java].
The intermediate code is converted into machine language only when the application needs that is required codes are only converted to machine code.
JIT vs Non-JIT comparison:
In JIT not all the code is converted into machine code first a part
of the code that is necessary will be converted into machine code
then if a method or functionality called is not in machine then that
will be turned into machine code... it reduces burden on the CPU.
As the machine code will be generated on run time....the JIT
compiler will produce machine code that is optimised for running
machine's CPU architecture.
JIT Examples:
In Java JIT is in JVM (Java Virtual Machine)
In C# it is in CLR (Common Language Runtime)
In Android it is in DVM (Dalvik Virtual Machine), or ART (Android RunTime) in newer versions.
As other have mentioned
JIT stands for Just-in-Time which means that code gets compiled when it is needed, not before runtime.
Just to add a point to above discussion JVM maintains a count as of how many time a function is executed. If this count exceeds a predefined limit JIT compiles the code into machine language which can directly be executed by the processor (unlike the normal case in which javac compile the code into bytecode and then java - the interpreter interprets this bytecode line by line converts it into machine code and executes).
Also next time this function is calculated same compiled code is executed again unlike normal interpretation in which the code is interpreted again line by line. This makes execution faster.
JIT compiler only compiles the byte-code to equivalent native code at first execution. Upon every successive execution, the JVM merely uses the already compiled native code to optimize performance.
Without JIT compiler, the JVM interpreter translates the byte-code line-by-line to make it appear as if a native application is being executed.
Source
JIT stands for Just-in-Time which means that code gets compiled when it is needed, not before runtime.
This is beneficial because the compiler can generate code that is optimised for your particular machine. A static compiler, like your average C compiler, will compile all of the code on to executable code on the developer's machine. Hence the compiler will perform optimisations based on some assumptions. It can compile more slowly and do more optimisations because it is not slowing execution of the program for the user.
After the byte code (which is architecture neutral) has been generated by the Java compiler, the execution will be handled by the JVM (in Java). The byte code will be loaded in to JVM by the loader and then each byte instruction is interpreted.
When we need to call a method multiple times, we need to interpret the same code many times and this may take more time than is needed. So we have the JIT (just-in-time) compilers. When the byte has been is loaded in to JVM (its run time), the whole code will be compiled rather than interpreted, thus saving time.
JIT compilers works only during run time, so we do not have any binary output.
A just in time compiler (JIT) is a piece of software which takes receives an non executable input and returns the appropriate machine code to be executed. For example:
Intermediate representation JIT Native machine code for the current CPU architecture
Java bytecode ---> machine code
Javascript (run with V8) ---> machine code
The consequence of this is that for a certain CPU architecture the appropriate JIT compiler must be installed.
Difference compiler, interpreter, and JIT
Although there can be exceptions in general when we want to transform source code into machine code we can use:
Compiler: Takes source code and returns a executable
Interpreter: Executes the program instruction by instruction. It takes an executable segment of the source code and turns that segment into machine instructions. This process is repeated until all source code is transformed into machine instructions and executed.
JIT: Many different implementations of a JIT are possible, however a JIT is usually a combination of a compiler and an interpreter. The JIT first turn intermediary data (e.g. Java bytecode) which it receives into machine language via interpretation. A JIT can often measures when a certain part of the code is executed often and the will compile this part for faster execution.
Just In Time Compiler (JIT) :
It compiles the java bytecodes into machine instructions of that specific CPU.
For example, if we have a loop statement in our java code :
while(i<10){
// ...
a=a+i;
// ...
}
The above loop code runs for 10 times if the value of i is 0.
It is not necessary to compile the bytecode for 10 times again and again as the same instruction is going to execute for 10 times. In that case, it is necessary to compile that code only once and the value can be changed for the required number of times. So, Just In Time (JIT) Compiler keeps track of such statements and methods (as said above before) and compiles such pieces of byte code into machine code for better performance.
Another similar example , is that a search for a pattern using "Regular Expression" in a list of strings/sentences.
JIT Compiler doesn't compile all the code to machine code. It compiles code that have a similar pattern at run time.
See this Oracle documentation on Understand JIT to read more.
You have code that is compliled into some IL (intermediate language). When you run your program, the computer doesn't understand this code. It only understands native code. So the JIT compiler compiles your IL into native code on the fly. It does this at the method level.
I know this is an old thread, but runtime optimization is another important part of JIT compilation that doesn't seemed to be discussed here. Basically, the JIT compiler can monitor the program as it runs to determine ways to improve execution. Then, it can make those changes on the fly - during runtime. Google JIT optimization (javaworld has a pretty good article about it.)
just-in-time (JIT) compilation, (also dynamic translation or run-time compilation), is a way of executing computer code that involves compilation during execution of a program – at run time – rather than prior to execution.
IT compilation is a combination of the two traditional approaches to translation to machine code – ahead-of-time compilation (AOT), and interpretation – and combines some advantages and drawbacks of both. JIT compilation combines the speed of compiled code with the flexibility of interpretation.
Let's consider JIT used in JVM,
For example, the HotSpot JVM JIT compilers generate dynamic optimizations. In other words, they make optimization decisions while the Java application is running and generate high-performing native machine instructions targeted for the underlying system architecture.
When a method is chosen for compilation, the JVM feeds its bytecode to the Just-In-Time compiler (JIT). The JIT needs to understand the semantics and syntax of the bytecode before it can compile the method correctly. To help the JIT compiler analyze the method, its bytecode are first reformulated in an internal representation called trace trees, which resembles machine code more closely than bytecode. Analysis and optimizations are then performed on the trees of the method. At the end, the trees are translated into native code.
A trace tree is a data structure that is used in the runtime compilation of programming code. Trace trees are used in a type of 'just in time compiler' that traces code executing during hotspots and compiles it. Refer this.
Refer :
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html
https://en.wikipedia.org/wiki/Just-in-time_compilation
A non-JIT compiler takes source code and transforms it into machine specific byte code at compile time. A JIT compiler takes machine agnostic byte code that was generated at compile time and transforms it into machine specific byte code at run time. The JIT compiler that Java uses is what allows a single binary to run on a multitude of platforms without modification.
Jit stands for just in time compiler
jit is a program that turns java byte code into instruction that can be sent directly to the processor.
Using the java just in time compiler (really a second compiler) at the particular system platform complies the bytecode into particular system code,once the code has been re-compiled by the jit complier ,it will usually run more quickly in the computer.
The just-in-time compiler comes with the virtual machine and is used optionally. It compiles the bytecode into platform-specific executable code that is immediately executed.
20% of the byte code is used 80% of the time. The JIT compiler gets these stats and optimizes this 20% of the byte code to run faster by adding inline methods, removal of unused locks etc and also creating the bytecode specific to that machine. I am quoting from this article, I found it was handy. http://java.dzone.com/articles/just-time-compiler-jit-hotspot
Just In Time compiler also known as JIT compiler is used for
performance improvement in Java. It is enabled by default. It is
compilation done at execution time rather earlier.
Java has popularized the use of JIT compiler by including it in
JVM.
JIT refers to execution engine in few of JVM implementations, one that is faster but requires more memory,is a just-in-time compiler. In this scheme, the bytecodes of a method are compiled to native machine code the first time the method is invoked. The native machine code for the method is then cached, so it can be re-used the next time that same method is invoked.
JVM actually performs compilation steps during runtime for performance reasons. This means that Java doesn't have a clean compile-execution separation. It first does a so called static compilation from Java source code to bytecode. Then this bytecode is passed to the JVM for execution. But executing bytecode is slow so the JVM measures how often the bytecode is run and when it detects a "hotspot" of code that's run very frequently it performs dynamic compilation from bytecode to machinecode of the "hotspot" code (hotspot profiler). So effectively today Java programs are run by machinecode execution.
I read that, a java source code is compiled into 'bytecode' then it is 'Compiled' again by JIT into 'machine code'. That is, the source code is first compiled into a platform independent bytecode and then compiled again to a machine specific code. Then why it is called as both interpreted and compiled language? Where the interpretation takes place?
There is a bit of misunderstanding here.
In normal circumstances java compiler(javac) compiles java code to bytecodes and java interpreter(java) interpretes these bytecodes(line by line), convert it into machine language and execute.
JIT(Just in time) compiler is a bit different concept. JVM maintains a count of times a function is executed. If it exceeds the limit then JIT comes into picture. java code is directly compiled into machine language and there on this is used to execute that function.
Java is a programming language.
It has a specification (the JLS) that defines how Java programs should act.
As a language itself, it does not specify how it should be executed on different platforms. The way it runs, with a JIT or without a JIT is entirely implementation based.
If I write a Java runtime tomorrow that does not do JIT compilation at all I can call Java interpreted.
If I take a Java machine (and people seriously made those) that uses Java bytecode as assembly, I can call Java strictly compiled.
A lot of other languages do this:
Is python an interpreted language? (CPython) or is it JITed (PyPy)?
Is Lua interpreted (old lua interpreters) or is it compiled (LuaJIT)?
Is JavaScript interpreted (IE6 style) or is it compiled (v8)?
For the sake of precision, let's make clear this is not a Java programming language question, but a JVM feature.
In JVM first implementations, JIT didn't exist and bytecode was always interpreted. This was due to a design decision to make compiled code independent of the physical machine and OS running java, and is still valid today.
As a later refinement, JIT was introduced in the JVM implementation for a faster execution, but the bytecode must still be valid and pass all the validations before being translated to binary. This way you keep the platform independence, all the sanity and security checks and you gain performance.
Java is Hybrid Language i.e. it is both Compiled(work done upfront) and Interpreted(work done receiving-end).
Byte code is an IL(Intermediate Language) to Java. Java source code compiles to Bytecode by javac. Sometimes this byte code again compiles into Machine language which is referred as JIT(Just-In-Time) compilation.
JIT compilation is a way of executing computer code that involves compilation during execution of a program – at run time – rather than prior to execution. source
JVM(without JIT) interprets the java Intermediate Language byte code to native machine language as follows:
Source
JVM is an abstract computing machine, it has several implementations:
HotSpot (Interpreter + JIT compiler) : the primary reference Java VM implementation. Used by both Oracle Java and OpenJDK.
JamVM (Interpreter) Developed to be an extremely small virtual machine compared to others. Designed to use GNU Classpath. Supports several architectures. GPL.
ART (Interpreter + AOT compiler i.e. Ahead-of-time compilation) Android RunTime is an application runtime environment used by the Android operating system replacing Dalvik (interpreter + JIT compiler).
List of Java virtual machines
javac is a compiler and it converts java code into bytecode (see bytecode) which is easy to run on any machine if we have a JVM (java Virtual Machine). and interpreter converts java bytecode into machine code.
It serves two purposes. The first is to ensure that the code is syntactically and semantically correct. Secondly, the compilation process produces byte-code. As you note, this is an architecture-agnostic intermediate language that can be interpreted or just-in-time compiled to native code by the JVM for a specific machine architecture. By compiling to byte-code, much of the overhead associated with compilation can be done in advance, leaving the JVM to generate native code from or interpret byte-code that has been thoroughly and rigorously checked beforehand.
Unlike other programming language java is compiled and interpreted language. Java IDE acts as a compiler and JVM(java virtual machine) behave like an interpreter. i.e. when any program let say Hello, is saved after compiling as Hello.java and after compiling this file we get Hello.Class extension file is called as class-file, byte-code or intermediate code. Byte-code is not dependent for any specific machine so it is also called as intermediate code.
To convert this byte-code into machine code or machine understandable format JVM is used which is different for different operating system. JIT(Just in Time Compiler) is a part of JVM that is enabled by default compiles the bytecode into the native machine code compiling in 'just in time'.
I heard many times that Java implemments JIT(just-in-time) compilation, and its bytecodes which are portable across platforms get "interpreted" by JVM. However, I don't really know what the bytecodes are, and what the JVM actually mean in Java language architecture; I would like to know more about them.
The JVM (Java Virtual Machine) has an instruction set just like a real machine. The name given to this instruction set is Java Bytecode. It is described in the Java Virtual Machine Specification. Other languages are translated into a bytecode before execution, for example ruby and python. Java's bytecode is at a fairly low level while python's is much more high level.
Interpretation and JIT compilation are two different strategies for executing bytecode. Interpretation processes bytecodes one at a time making the changes to the virtual machine state that are encoded in each instruction. JIT compilation translates the bytecode into instructions native to the host platform that carry out equivalent operations.
Interpretation is generally quick to start but slow during execution, while JIT has more startup overhead but runs quicker afterwards. Modern JVMs use a combination of interpretation and JIT techniques to get the benefit of both. The bytecode is first interpreted while the JIT is translating it in the background. Once the JIT compilation is complete, the JVM switches to using that code instead of the interpreter. Sometimes JIT compilation can produce better results than the ahead-of-time compilation used for C and C++ because it is more dynamic. The JVM can keep track of how often code is called and what the typical paths through the code are and use this information to generate more efficient code while the program is running. The JVM can switch to this new code just like when it initially switches from the interpreter to the JIT code.
Just like there are other languages that compile to native code, like C, C++, Fortran; there are compilers for other languages that output JVM bytecode. One example is the scala language. I believe that groovy and jruby can also convert to java bytecode.
Bytecode is a step between your source code and actual machine code. The JVM is what takes the bytecode and translates it into machine code.
JIT refers to the fact that the JVM does this translation on the fly when the program is executed, rather than in a single step (like in a traditionally compiled/linked language like C or C++)
The point of bytecode is that you get better performance than a strictly interpreted language (like PHP for example) because the bytecode is already partially compiled and optimized. Also, since the bytecode doesn't need to be directly interpreted by the CPU, it doesn't need to be tied to any specific CPU architecture which makes it more portable.
The disadvantage of course is that it will generally be a bit slower than a natively compiled application since the JVM still has to do some work in translating the bytecode to machine code.
When you compile something in Java, the compiler generates bytecode. This is native code for the Java Virtual Machine. The JVM then translates the bytecode to native code for your processor/architecture, this is where the JIT happens. Without JIT, the JVM would translate the program one instruction at a time, which is very slow.
Bytecode is the JVM equivalent of machine language instructions.
jcyang already provided a link to wikipedia, but this one is a better match to your question:
Java Bytecode
The Java Compiler compiles Java Source code to class files. The class's methods are translated to Byte Code and the Java virtual machine (JVM) interpretes this byte code. A Just In Time compiler (JIT) may be used to translate the byte code to machine code to speed up execution of class methods.
JVM is a virtual machine which is used to run Java code. We can compare JVM with a compiler as without it we cannot compile Java code and make applications. JVM is nothing but a piece of code that will testify your Java code. The main task of JVM is to convert the Java code into Java bytecode and compile it. This makes Java development easy. Check out this article if you want to know more about how does Java Virtual Machine Works?
Why we do we say that Java is a compiled and interpreted language?
What is the advantage of this (being compiled and interpreted)?
Java is compiled to an intermediate "byte code" at compilation time. This is in contrast to a language like C that is compiled to machine language at compilation time. The Java byte code cannot be directly executed on hardware the way that compiled C code can. Instead the byte code must be interpreted by the JVM (Java Virtual Machine) at runtime in order to be executed. The primary drawback of a language like C is that when it is compiled, that binary file will only work on one particular architecture (e.g. x86).
Interpreted languages like PHP are effectively system independent and rely on a system and architecture specific interpreter. This leads to much greater portability (the same PHP scripts work on Windows machines and Linux machines, etc.). However, this interpretation leads to a significant performance decrease. High-level languages like PHP require more time to interpret than machine-specific instructions that can be executed by the hardware.
Java seeks to find a compromise between a purely compiled language (with no portability) and a purely interpreted language (that is significantly slower). It accomplishes this by compiling the code into a form that is closer to machine language (actually, Java byte code is a machine language, simply for the Java Virtual Machine), but can still be easily transported between architectures. Because Java still requires a software layer for execution (the JVM) it is an interpreted language. However, the interpreter (the JVM) operates on an intermediate form known as byte code rather than on the raw source files. This byte code is generated at compile time by the Java compiler. Therefore, Java is also a compiled language. By operating this way, Java gets some of the benefits of compiled languages, while also getting some of the benefits of interpreted languages. However, it also inherits some limitations from both of these languages.
As Bozho points out, there are some strategies for increasing the performance of Java code (and other byte code languages like .Net) through the use of Just in Time (JIT) compilation. The actual process varies from implementation to implementation based on the requirements, but the end-result is that the original code is compiled into byte code at compile time, but then it is run through a compiler at runtime before it is executed. By doing this, the code can be executed at near-native speeds. Some platforms (I believe .Net does this) save the result of the JIT compilation, replacing the byte code. By doing this, all future executions of the program will execute as though the program was natively compiled from the beginning.
Why do we say Java is compiled and interpreted language.
Because source code (.java files) is compiled into bytecode (.class files) that is then interpreted by a Java Virtual Machine (also known as a JVM) for execution (the JVM can do further optimization but this is anoher story).
What is the advantage over this(being compiled/interpreted)
Portability. The same bytecode can be executed on any platform as long as a JVM is installed ("compile once, run anywhere").
This is a long topic and you'd better read about JIT. In short, Java is compiled to bytecode, and the bytecode is later compiled (in the JVM) to machine code.
Java is considered a "compiled" language because code is compiled into bytecode format that is then run by the Java Virtual Machine (JVM). This gives several advantages in the realm of performance and code optimization, not to mention ensuring code correctness.
It is considered an "interpreted" language because, after the bytecode is compiled, it is runnable on any machine that has a JVM installed. It is in this way that Java is much like an interpreted language in that, for the most part, it doesn't depend on the platform on which is is being run. This behavior is similar to other interpreted languages such as Perl, Python, PHP, etc.
One theoretical downside to the fact that Java programs can be run on any system in absence of the source code is that, while this method of distribution ensures cross-platform compatibility, the developers have one less reason to release their source code, driving a wedge between the ideological meanings of the phrases "cross-platform" and "open source".
Java is compiled, into byte code not binaries. The byte codes are not executable directly, they need the Java Virtual Machine to do a just in time compile and compile them again into machine code at runtime.
At a very basic level, it separate the code that programmers write from the local machine where the JVM operates on, hence better portability. While compiling to bytecode helps the performance of just in time compile, reduce file sizes, and more or less help conceal real code. (it also eliminates some compile time error)
Compiled: Your program is syntactically a correct Java program, before the program starts.
Interpreted: Run on different platforms the same (byte-)code.
Compiled: When your program has compiled correctly you can be shure to have 80% of software bugs under control. And your code will not stop because you have not correctly closed a code block, etc.
Interpreted: You know what Applets are ? It was the "killer" application when Java came out. Your browser downloads the applet from the website and run the applet code in your browser. That is not very cool. But, the same applet runs on Windows, Linux, Macs, Solaris, ... because runs/interpreted an intermedium language: the byte code.
I heard many times that Java implemments JIT(just-in-time) compilation, and its bytecodes which are portable across platforms get "interpreted" by JVM. However, I don't really know what the bytecodes are, and what the JVM actually mean in Java language architecture; I would like to know more about them.
The JVM (Java Virtual Machine) has an instruction set just like a real machine. The name given to this instruction set is Java Bytecode. It is described in the Java Virtual Machine Specification. Other languages are translated into a bytecode before execution, for example ruby and python. Java's bytecode is at a fairly low level while python's is much more high level.
Interpretation and JIT compilation are two different strategies for executing bytecode. Interpretation processes bytecodes one at a time making the changes to the virtual machine state that are encoded in each instruction. JIT compilation translates the bytecode into instructions native to the host platform that carry out equivalent operations.
Interpretation is generally quick to start but slow during execution, while JIT has more startup overhead but runs quicker afterwards. Modern JVMs use a combination of interpretation and JIT techniques to get the benefit of both. The bytecode is first interpreted while the JIT is translating it in the background. Once the JIT compilation is complete, the JVM switches to using that code instead of the interpreter. Sometimes JIT compilation can produce better results than the ahead-of-time compilation used for C and C++ because it is more dynamic. The JVM can keep track of how often code is called and what the typical paths through the code are and use this information to generate more efficient code while the program is running. The JVM can switch to this new code just like when it initially switches from the interpreter to the JIT code.
Just like there are other languages that compile to native code, like C, C++, Fortran; there are compilers for other languages that output JVM bytecode. One example is the scala language. I believe that groovy and jruby can also convert to java bytecode.
Bytecode is a step between your source code and actual machine code. The JVM is what takes the bytecode and translates it into machine code.
JIT refers to the fact that the JVM does this translation on the fly when the program is executed, rather than in a single step (like in a traditionally compiled/linked language like C or C++)
The point of bytecode is that you get better performance than a strictly interpreted language (like PHP for example) because the bytecode is already partially compiled and optimized. Also, since the bytecode doesn't need to be directly interpreted by the CPU, it doesn't need to be tied to any specific CPU architecture which makes it more portable.
The disadvantage of course is that it will generally be a bit slower than a natively compiled application since the JVM still has to do some work in translating the bytecode to machine code.
When you compile something in Java, the compiler generates bytecode. This is native code for the Java Virtual Machine. The JVM then translates the bytecode to native code for your processor/architecture, this is where the JIT happens. Without JIT, the JVM would translate the program one instruction at a time, which is very slow.
Bytecode is the JVM equivalent of machine language instructions.
jcyang already provided a link to wikipedia, but this one is a better match to your question:
Java Bytecode
The Java Compiler compiles Java Source code to class files. The class's methods are translated to Byte Code and the Java virtual machine (JVM) interpretes this byte code. A Just In Time compiler (JIT) may be used to translate the byte code to machine code to speed up execution of class methods.
JVM is a virtual machine which is used to run Java code. We can compare JVM with a compiler as without it we cannot compile Java code and make applications. JVM is nothing but a piece of code that will testify your Java code. The main task of JVM is to convert the Java code into Java bytecode and compile it. This makes Java development easy. Check out this article if you want to know more about how does Java Virtual Machine Works?