The JVM (especially the HotSpot VM) is famous for having a huge number of optimizations it can apply at runtime.
Is there a way to look at a certain piece of code and see what the JVM has actually done to it?
The compiled code is placed into a part of the JVM process space called the code cache; the location of the method in the code cache is recorded, so that future calls to it will call the compiled code.
More importantly, the javac compiler does not perform simple optimizations like loop unrolling, algebraic simplification, strength reduction, and others. To get these benefits and other simple optimizations, the programmer must perform them on the Java source code and not rely on the javac compiler to perform them.
JIT compiler monitors the java program and compiles the bytecode of hot methods (i.e. methods that get called frequently) into machine specific code (i.e. platform binary or native code). This compilation of bytecode into native code occurs as the program executes.
JIT is one of the components of JVM. JVM compiles complete byte code to machine code. JIT compiles only the reusable byte code to machine code. JVM provides platform independence.
One problem is that "what JVM has actually done to it" changes between invocations as the JVM is free to re-generate code.
As an example I investigated some days ago what Hotspot does with final
methods compared to virtual methods. Judging by microbenchmarks, my conclusions were:
Client JVM: If the method is effectively final
(there is not any loaded class that overrides it), the JVM uses a nonvirtual call. Afterwards, if you load a class that overrides this method, the JVM will change the JIT'ed code to make the calls virtual. So declaring as final
has no significant relevance.
Server JVM: Here final
seems to have no relevance either. What seems to happen is that the JVM generates a non virtual call for whatever class you are using the first time, independently of whatever classes are loaded. Afterwards, if you make a call from an object of another class, the JVM will patch all calls with something similar to this (I guess that it will also profile calls so it can change fast-path and slow-path if it did not get it right the first time):
if (object instanceof ClassOfNonVirtualCall) { do non-virtual call to ClassOfNonVirtualCall.method } else { do virtual call to object.method }
If you are really interested in seeing generated code, you may play with DEBUG JVMs from OpenJDK:
http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html
http://wikis.sun.com/display/HotSpotInternals/PrintAssembly
This is highly JVM specific, and you will most likely need to do some serious investigation in the particular JVM you are looking at.
You can see the available HotSpot VM options here http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With