views:

146

answers:

4

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?

+4  A: 

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

Thorbjørn Ravn Andersen
Hotspot would be the JVM implementation I'm most interested in.
soc
+4  A: 

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 finalhas 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

gpeche
Indeed the Server VM will inline special case code for two classes - bimorphic inlining. I believe this feature was implemented to support NIO direct and Java heap buffers.
Tom Hawtin - tackline
+2  A: 

The following is a very good resource:

http://wikis.sun.com/display/HotSpotInternals/Home

Particularly interesting are the "LogCompilation tool" and "LogCompilation overview" links (can't post direct links as I've just registered).

ijuma
Hi ijuma! Nice to see you here!
soc
+2  A: 

Here is a good page on HotSpot optimizations. Some of the optimizations can be seen by looking at the bytecode emitted by the compiler. Other optimizations are dynamic and only exist during run-time. For example, HotSpot can do on-stack replacement which modifies the stack directly during runtime.

Kelly French