Question: > 
> **Possible Duplicate:**  
> 
> [Why doesn't the JVM cache JIT compiled code?](https://stackoverflow.com/questions/1992486/why-doesnt-the-jvm-cache-jit-compiled-code) 
> 
> 
> 

I understand that JIT compilation is compilation to native code using hotspot mechanisms, which can be very very fast as it is optimization to the OS, Hardwards, etc.

My question is, why does Java not store that JIT complied code somewhere in file and use the same for future purposes? This can reduce the 'initial warm-up' time as well. 

Please let me know what I am missing here.

To add to my question: 
Why does not Java complie the complete code to native and use that always(for a specific JVM,OS, platform)? Why JIT?

Answer: 
If I remember correctly, caching and sharing of JIT-compiled code has been tried, and found to be not a good idea.

On the one hand, a modern HotSpot JIT compiler generates and optimizes code in the context of the current CPU model, and the usage patterns of the current execution. If it were to cache compiled code, then there is a good chance that the code would not be optimal.

On the other hand, there are apparently a variety of tricking technical problems. For instance, the cached code becomes a potential security hole, For instance, the code area needs to be writeable by all applications / users that share it. But that means that one user could potentially interfere with the running of another user's applications.
Some JVMs (like the IBM one) do have "[ahead of time shared JIT code](http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/index.jsp?topic=/com.ibm.java.win.70.doc/diag/understanding/aot.html)". It's quite difficult to do (as other answers point out) because the class files used at one time by one JVM may not be the same ones as used next time, even if they have the same names. Thus there's a lot of logic required to prove that "class A I saw earlier is really the same as class A I now have".

The other issue is that JITed code very often includes address-space specific values (eg: the address of a given static variable, or entry point for another JITed method) and those can (and certainly will!) change on every JVM invocation, so again, care must be taken in dealing with those issues.

The performance wins that AOT code provides are real, and the feature is very much worth using depending on the circumstance. (specifically: things won't be changing run to run, etc.. - like invoking the same version of an app server, or Eclipse, for example)