The basic bytecode interpreter VM executes by decoding and executing bytecodes. This is slow,and is pure overhead, adding nothing to the functionality of the application. A just-in-time ( JIT)compiler in a virtual machine eliminates much of this overhead by doing the bytecode fetch and
decode just once. The first time the method is loaded, the decoded instructions are converted intomachine code native for the CPU the system is running on. After that, future invocations of aparticular method no longer incur the interpreter overhead. However, a JIT must be fast atcompiling to avoid slowing the runtime, so extensive optimizations within the compile phase areunlikely. This means that the compiled code is often not as fast as it could be. A JIT also imposes asignificantly larger memory footprint to the process.

Without a JIT, you might have to optimize your bytecodes for a particular platform. Optimizing the bytecode for one platform can conceivably make that code run slower on another platform (though a speedup is usually reflected to some extent on all platforms). A JIT compiler can theoretically
optimize the same code differently for different underlying CPUs, thus getting the best of all worlds.

In tests by Mark Roulo (Accelerate your Java apps! - Java World), he found that a good JIT speeded up the overhead of method calls from a best of 280 CPU clock cycles in the fastest non-JIT VM, to just 2 clock cycles in the JIT VM. In a direct comparison of method
call times for this JIT VM compared to a compiled C++ program, the Java method call time was found to be just one clock cycle slower than the C++: fast enough for almost any application.

However, object creation is not speeded up by anywhere near this amount, which means that with a JIT VM, object creation is relatively more expensive (and consequently more important when tuning) than with a non-JIT VM.