Any interpreter has to translate statements into binary code which in turn is run by the CPU. In Java's case the statements to be interpreted are semi-compiled, much comprised "byte-code" statements which are very much like lines of assembly code.

Every time the interpreter comes across such a statement it will be parsed and translated into real binary code the CPU understands. The core of JIT compiling is to set up a hashtable of pieces of ready-to-run, native binary code that can be called the next time the interpretor has to execute that same sequence again.

A prima facie condition: the recallable code has to be exactly the same before it can qualify as a candidate for the compilers internal log and therewith as a truly speed-optimizing element. Experimental techniques however showed positive results where it comes to loosening even this stern precondition.

An important implication of JIT interpreting is the extra though small amount of time it takes to run a method for the very first time (Java methods are the chunks of input which are translated into native code that is stored in the local table). The gains in speed however outweigh this "bookkeeping".