JIT compilers alter the role of the VM a little by directly compiling Java bytec ode into native platform

code, thereby relieving the VM of its need to manually call underlying native system services. The purpose of JIT compilers, however, i sn't to allow the VM to relax. By compiling bytecodes into native code, executio n 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. Stage 1: JIT compiler maintains a internal table called as V-Table (Virtual Table) that h as pointer to the methods in a Class. In case of derived classes only the Derive d method are taken into consideration. When a JIT compiler is first loaded, the VM pulls a little trick with the V-table to make sure that methods are compiled into native code rather than executed. What happens is that each bytecode addres s in the V-table is replaced with the address of the JIT compiler itself. Stage 2: When the VM calls a method through the address in the V-table, the JIT compiler is executed instead. The JIT compiler steps in and compiles the Java bytecode in to native code and then patches the native code address back to the V-table. Fro m now on, each call to the method results in a call to the native version. Metho ds are compiled only when they are called. The first time a method is called, it is compiled; subsequent calls result in the native code being executed. Stage 3: For Backward compatilibily purposes, VM actually maintains two V-Tables. One for Native Code and the other for original Bytecode, so that when methods needs to be executed with JIT compiler off, then they are executed from V-table having Me thods in Bytecode