Puzzled by a performance glitch? You might have to look at the generated code.
Examining generated code
The following HotSpot options (with -XX require OpenJDK 7 and an externally loadable disassembler plugin:
+PrintAssemblyprint assembly code for bytecoded and native methods
+PrintNMethodsprint nmethods as they are generated
+PrintNativeNMethodsprint native method wrappers as they are generated
+PrintSignatureHandlersprint native method signature handlers
+PrintAdapterHandlersprint adapters (i2c, c2i) as they are generated
+PrintStubCodeprint stubs: deopt, uncommon trap, exception, safepoint, runtime support
+PrintInterpreterprint interpreter code
These flags are "diagnostic", meaning that they must be preceded by
-XX:+UnlockDiagnosticVMOptions. On the command line, they must all be preceded by
-XX:. They may also be placed in a flags file,
.hotspotrc by default, or configurable as
The plugin is defined as part of the forthcoming bug fix 6667042.
Individual methods may be printed:
CompileCommand=print,*MyClass.myMethodprints assembly for just one method
CompileCommand=option,*MyClass.myMethod,PrintOptoAssembly(debug build only) produces the old print command output
CompileCommand=option,*MyClass.myMethod,PrintNMethodsproduces method dumps
Reading the compiler's mind
-XX:+LogCompilation flag produces a low-level XML file about compiler and runtime decisions, which may be interesting to some. The
-XX:+UnlockDiagnosticVMOptions must come first. The dump is to
hotspot.log in the current directory; use
-XX:LogFile=foo.log to change this.