The point of the JIT is that the JVM itself doesn't execute the native code - as in, not in the way it executes bytecode (though interpret is the right word for this, I guess).ok. the JIT output native machine code, then it is the JVM runtime to execute it.
JVM = (Java Source) --compile-to- (byecode) -- precompile-to- (Nativecode)
(User Java Code) --compile-to- (Bytecode)
the JVM now load bytecode, calls the JIT to translate it native code, and execute the native code.
So how the JVM execute the native code? it is compiled by the JIT compiler also, but it looks that it is something magic.
To my understanding a very over-simplified outline of process to doing JIT is:-
1) Take your JVM bytecode and step through it op by op for the bit we want to JIT.
2) For ops that we know how to generate native code for, spit out (native) machine code into a chunk of memory. For those you don't, put in a call to a chunk of code in the JVM that does that op. (This also means you can build up JIT support op by op - and some ops will probably always be to complex to JIT - I may be wrong here though).
3) Put some magic machine code on the end of the chunk of machine code the JIT just generated that returns control to the JVM when execution is complete.
4) Write some code that causes the CPU to jump to the chunk of machine code that was generated. At this point, the CPU itself is doing all of the instruction fetch and execute, which is why with JIT you can (in theory) get a bytecode instruction done in one CPU instruction - there is no overhead from the JVM.
You can do further "tricks", like caching machine code that was generated for quick execution again later, or spotting very frequently executed chunks of machine code and deciding to try doing some optimizations on them.
Sorry if everyone knew this already, but hope it might help those less familiar with JIT. Oh, and hi from yet another list newbie. :-)
Jonathan
