How to interpret the output of -XX:CompileCommand="print Class::Method" in java

Question

Here is an excerpt of the output that I get when I run the following command (40 is just an arg to the Fibonacci program) :

java -XX:+UnlockDiagnosticVMOptions -XX:CompileCommand="print Fibonacci::fibonacci" Fibonacci 40

Can someone explain the meanings of each data (I presume it means the number of bytes, e.g., main code takes 288 bytes). Also what do the various categories mean - relocation, stubs code, metadata, scopes data, scopes pcs, handler table etc mean ?

...
Compiled method (c2)      93   16       4       Fibonacci::fibonacci (22 bytes)
total in heap  [0xfff8000108113dd0,0xfff8000108114440] = 1648
relocation     [0xfff8000108113f00,0xfff8000108113f48] = 72
main code      [0xfff8000108113f60,0xfff8000108114080] = 288
stub code      [0xfff8000108114080,0xfff80001081141e0] = 352
oops           [0xfff80001081141e0,0xfff80001081141e8] = 8
metadata       [0xfff80001081141e8,0xfff8000108114210] = 40
scopes data    [0xfff8000108114210,0xfff8000108114298] = 136
scopes pcs     [0xfff8000108114298,0xfff80001081143d8] = 320
dependencies   [0xfff80001081143d8,0xfff80001081143e0] = 8
handler table  [0xfff80001081143e0,0xfff8000108114440] = 96
----------------------------------------------------------------------
Fibonacci.fibonacci  [0xfff8000108113f60, 0xfff80001081141e0]  640 bytes
[Entry Point]
[Verified Entry Point]
[Constants]
# {method} {0xfff80001036243b8} 'fibonacci' '(I)J' in 'Fibonacci'
# parm0:    I0        = int
#           [sp+0x90]  (sp of caller)
...

Bondy

I don't have a good explanation, but they are coming from nmethod::print. Most of the fields are declared in CodeBlob, which does have some comments as to what they are. – Flaming

Answer 1

The hexadecimal numbers between square brackets are the start and end of the memory range that contain the data. As you guessed, the number after the = is the size of the data in bytes.

Regarding the categories:

• total in heap is the whole compiled code and metadata. It includes all the other categories. It is actually bigger than the sum of all other categories because there are a bunch of other fields that are not described in this table (This table only describes the parts of the object that have variable size).
• relocation is metadata that allows the VM to patch the code if necessary: for example if the code embeds an object pointer, that pointer needs to be modified if the GC moves the object. It also contains information about inline caches, any reference to external constants, runtime calls etc.
• main code is the bulk of the native code compiled for that method.
• stub code this is some more machine code associated with this method. It is usually little pieces of code that are used to support the main code during some runtime events (e.g., linking or re-linking call sites or inline caches, deoptimization, exception handling...)
• oops An array of Ordinary Object Pointers (i.e., pointers to garbage collected objects). They can be referenced from the main code or scopes data below.
• metadata Since the removal of the permanent generation in JDK 8, the VM's metadata about classes and methods are no longer standard garbage collected oops, since they still need to be tracked they got their own section. So metadata are pointers to metadata objects (the VM objects representing classes and methods for example). They can also be referenced from the main code or scopes data below.
• scopes pcs This contains metadata that allow to go from a program counter in the main native code to a code location in Java: native PCs are mapped to a Java method and bytecode index ("bci"). Because of inlining, a single PC is actually associated with a stack of (method, bci) pairs.
• scopes data This contains metadata further describing the state of the Java VM at those PCs. It contains data that maps JVM locations (e.g., locals or stack slots) to native locations (e.g., registers or native stack slots). This allows the VM to know where to look for oops during GC as well as to reconstruct the state of the interpreter during deoptimization.
• dependencies This is a list of "assumptions" the compiler made while compiling this method. Such an assumption could be "class Foo has no subclasses". This allows the VM to know that this method needs to be invalidated if something later violates this assumption (such as loading a new class which is a subclass of Foo in the previous example).
• handler table This is a table that allows the VM to know where to continue execution when unwinding because of an exception.

Quizzical

we absolutely need more answers like this! thank you for the time – Neubauer

@Gilles how do you know this? – Manometer

@Manometer By working on the HotSpot code-base, especially on JIT related topics. – Quizzical