3 ms·
JIT'd code isn't just about specific CPUs, but about optimizing hot paths. For example, you don't want to inline a commonly used function all over the place, b
by mdasen 7y ago
JIT'd code isn't just about specific CPUs, but about optimizing hot paths. For example, you don't want to inline a commonly used function all over the place, but if there's one area that calls it 10,000 times per second while the others call it once a minute at most, you can re-write the program at runtime having observed that hot code path.
To get an intuition for JITs: there are pieces of your code that you know will always be run in a certain way (or mostly run in that way), but it isn't provable at compile time that it will always be that way. JITs can notice that pattern and optimize it (or even provide optimizations for common, but not exclusive paths).
- gdxhyrd 7y agoNote that some compilers do the same at compile time by using profiling information.
- ncmncm 7y agoWhile they could, in principle, do this, does anybody actually do it in production?
- Jimmy123456789 7y agoThey are referring to the HotSpot VM default behaviour. That is how the HotSpot VM works. It's happening right now, while you read this sentence, in millions of production deployments.
- jacques_chester 7y agoYes, if you have Java code that runs for more than a few minutes in production.