Many folks were asking me about the Just In Time(aka JIT) heuristics after reading my One Java Two Compilers post
The basic thing that the JIT does is deciding weather a specific portion of the code should get compiled or get executed by the interpreter.
The portions that better get compiled called hotspots – “Once the … optimizer has gathered information during execution about program hot spots, it not only compiles the hot spot into native code”
The JIT has to consider what would be faster, notice that compiling a hot spot takes time, running code line by line is faster than compiling it and execute the compiled native-code, yet in case the code will be called many times in the future, getting the compiled native code out of the cache and execute it is faster than interpreting it
The JIT select hotspots to be compiled based on the prediction of how often they are likely to be called during the rest of the program’s execution.
This prediction is usually done by taking into account two major factors (1) the size of the code (2) the so-far execution statistics
Moreover: upon compiling, the JIT might optimize the code, those optimization’s sometime proven to be wrong and even cause internal JVM errors which get fixed by going back to the beginning of the hotspot and interpreting it line by line (while removing the erroneous compiled code from the memory).
You probably figure by now that the JVM is taking sophisticated statics while running.
Here is a list of possible optimization’s:
- Inline, replacing method call with the code of the called method
- Eliminating null-verification’s (e.g. removing “if(x!=null)”)
- Stack-allocation (I learned this cool feature about a week ago): JIT tries to identify local variables that are almost surely local to a specific method and allocate them on the stack instead of the heap, this way the GC works faster as it has less garbage to clean..
- Solving polymorphic calls, instead of using a virtual table, the JIT perdict which type of object is referencing at.
- Array range check, when iterating an array, instead of checking for each index if it’s in the approved range of the array, it check only the first and last indices <- this makes numeric calculations run faster
Extra reading: http://java.sun.com/products/hotspot/whitepaper.html