HotSpots?!


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:

  1.  Inline, replacing method call with the code of the called method
  2. Eliminating null-verification’s (e.g. removing “if(x!=null)”)
  3. 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..
  4. Solving polymorphic calls, instead of using a virtual table, the JIT perdict which type of object is referencing at.
  5. 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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s