JIT stands for "just in time". In JVM it's a neat mechanism that makes it easy to go from low execution speed, common to interpreters, to speed similar to native code execution, without involving any of software developer's work (at least in theory).
Whenever I wrote a utility script in Groovy, I soon found myself translating it to bash or python. Why? Because of the slow startup phase. This made me curious of what exactly makes Java so slow at the start time. One of the ideas was JIT. When you think of it - it's a kind of monitor, working alongside your application, counting method calls, compiling them to native code, skipping irrelevant code, etc. How expensive must that be, right?
Lately I noticed
-Xint flag to <code>java</code> command, which makes Java Virtual Machine to start in interpreter-only mode. This means that JIT compiler will be turned off in that Java process.
This way we may check what is the overhead of starting JIT. Let's start with a very simple example, which will cause JIT to drop some of the code (since
Math.sqrt doesn't have side effects, so it's safe for JIT to drop it).
After compilation we may run it with an insight to JIT actions:
What happened right there is out of this post's scope, so let's just execute that with
It works. JIT didn't generate any outputs as it was disabled.
Let's see how it influenced execution times:
|loops||jit enabled||jit disabled|
As expected - JIT dropped irrelevant code and ended up with a speed up for many loops. But that's not our target. When you look at the first scenario, you will notice there's no speedup in running that simple class. So JIT seems not to cause any overhead.
Next, let's check the same test for running a simple Groovy script (call system command, wait for it's finish, print output):
Results (on avarage):
|jit enabled||jit disabled|
On avarage disabling JIT even caused execution time to increase by 23%! Which means that even when running the tiniest Groovy script, JIT already makes a big improvement. How much exactly work is being involved? Take a look:
That's it for now. There's no reason to disable JIT in order to make JVM start faster. Soon I'll take a look at some other things.