Clever Geek Handbook

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

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

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

Can someone explain the meanings of each information (I assume it means the number of bytes, for example the main code is 288 bytes). Also, what do the various categories mean: "move", "stub code", "metadata", "scope data", "scopes", "handler table", and so on. 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)
...
+3


source to share


1 answer


The hexadecimal numbers between the square brackets are the beginning and end of the memory range that contains the data. As you might have guessed, the number after =

is the size of the data in bytes.

About categories:



  • total in heap

    is all the compiled code and metadata. It includes all other categories. This is actually more than the sum of all the other categories, because there are a bunch of other fields that are not covered in this table (this table only describes the variable-sized portions of an object).
  • relocation

    is metadata that allows the virtual machine to correct the code as needed: for example, if the code injects a pointer to an object, that pointer needs to be changed 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 inline code compiled for this method.
  • stub code

    This is another machine code associated with this method. These are usually small pieces of code that are used to support the main code during some run-time events (for example, linking or rebinding call sites or inline caches, de-optimization, exception handling ...)
  • oops

    An array of ordinary pointers to objects (i.e., pointers to garbage collection). They can be referenced from the main code or scopes data

    below.
  • metadata

    Since the removal of persistent generation in JDK 8, VM metadata about classes and methods are no longer standard garbage collectors, as they still need to be tracked, they got their own section. Thus, they metadata

    are pointers to metadata objects (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 allows you to go from the program counter in the main native code to the location of the code in Java: native PCs are mapped to the Java method and bytecode index ("bci"). Because of embedding, one PC is actually connected to a pair of pairs (method, bci).
  • scopes data

    It contains metadata that further describes the state of the Java Virtual Machine on these PCs. It contains data that maps JVM locations (like locals or stack slots) to local locations (like registers or native stack slots). This allows the VM to know where to look for oops during GC, as well as restore the interpreter state during de-optimization.
  • dependencies

    This is a list of "assumptions" made by the compiler when compiling this method. Such an assumption might be "the class Foo has no subclasses". This lets the VM know that this method should be invalidated if something later violates this assumption (for example, loading a new class that subclasses Foo in the previous example).
  • handler table

    This is a table that lets the VM know where to continue execution when unpacking due to an exception.
+4


source






More articles:


All Articles