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:
+PrintAssembly
print assembly code for bytecoded and native methods+PrintNMethods
print nmethods as they are generated+PrintNativeNMethods
print native method wrappers as they are generated+PrintSignatureHandlers
print native method signature handlers+PrintAdapterHandlers
print adapters (i2c, c2i) as they are generated+PrintStubCode
print stubs: deopt, uncommon trap, exception, safepoint, runtime support+PrintInterpreter
print 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 -XX:Flags=myhotspotrc.txt
.
The plugin is defined as part of the forthcoming bug fix 6667042.
Individual methods may be printed:
CompileCommand=print,*MyClass.myMethod
prints assembly for just one methodCompileCommand=option,*MyClass.myMethod,PrintOptoAssembly
(debug build only) produces the old print command outputCompileCommand=option,*MyClass.myMethod,PrintNMethods
produces method dumps
Reading the compiler's mind
The -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.