PrintAssembly

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