Puzzled by a performance glitch? You might have to look at the generated code.
Examining generated code
The following HotSpot options (with an -XX: prefix on the command line) 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 method
- CompileCommand=option,*MyClass.myMethod,PrintOptoAssembly (debug build only) produces the old print command output
- CompileCommand=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.
Labels
Sign up or Log in to add a comment or watch this page.
