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.
While there is a guarantee that you will always be using a JVM, there is no guarantee that you will always be using the same JVM. The hotspot optimized code is only valid for your machine.

With Java, there is no guarantee that the code is local to the JVM. Applets are a perfect example, and Webstart also illustrates this point. A generic "keep the optimization" would only clutter up caches in seldom run code, and creates issues in where to keep the optimized extensions. 

It would also create quite a puzzle in knowing how long to keep the on-disk cache, and wouldn't you have to recompile the 'class' file to verify that the cache was for the right "release" of the class file? Java doesn't have a "this version" of the same class file designator, with the exception of the optional serial version uid. 

Perhaps there's a workaround by check summing the class file and placing it in a field of the compiled class, but I'd hate to consider start up times of a JVM tasked with scanning all cached machine specific code, building a table, intervening in the class loader, and checking the check sum of the loaded class with the optimized code.