Comment interpréter la sortie de -XX: CompileCommand = "print Class :: Method" en java

Question

Voici un extrait de la sortie que je reçois quand j'exécute la commande suivante (40 est juste un arg au programme Fibonacci) :

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

quelqu'un peut-il expliquer la signification de chaque donnée (je suppose que cela signifie que le nombre d'octets, par exemple, principale le code prend 288 octets). En outre, que signifient les différentes catégories - relocalisation, code de stubs, métadonnées, données d'étendues, étendues pcs, handler table etc?

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

Answer 1

Les nombres hexadécimaux entre crochets représentent le début et la fin de la plage de mémoire contenant les données. Comme vous l'avez deviné, le nombre après le = est la taille des données en octets.

En ce qui concerne les catégories:

• total in heap est l'ensemble du code compilé et les métadonnées. Il comprend toutes les autres catégories. Il est en fait plus grand que la somme de toutes les autres catégories car il y a un tas d'autres champs qui ne sont pas décrits dans ce tableau (Ce tableau ne décrit que les parties de l'objet qui ont une taille variable).
• relocation est une métadonnée qui permet à la VM de patcher le code si nécessaire: par exemple si le code intègre un pointeur d'objet, ce pointeur doit être modifié si le GC déplace l'objet. Il contient également des informations sur les caches en ligne, toute référence aux constantes externes, les appels d'exécution, etc.
• main code est la majeure partie du code natif compilé pour cette méthode.
• stub code Il s'agit d'un code machine supplémentaire associé à cette méthode. Ce sont généralement de petits morceaux de code qui sont utilisés pour supporter le code principal pendant certains événements d'exécution (par exemple, relier ou relier des sites d'appel ou des caches en ligne, désoptimisation, gestion des exceptions ...)
• oops Un tableau d'objets ordinaires Pointeurs (c.-à-d., Pointeurs vers des objets récupérés). Ils peuvent être référencés à partir du code principal ou scopes data ci-dessous. Depuis la suppression de la génération permanente dans JDK 8, les métadonnées de la machine virtuelle à propos des classes et des méthodes ne sont plus normalisées, car elles doivent toujours être suivies. Donc metadata sont des pointeurs vers des objets de métadonnées (les objets VM représentant des classes et des méthodes par exemple). Ils peuvent également être référencés à partir du code principal ou scopes data ci-dessous.
• Ceci contient des métadonnées qui permettent de passer d'un compteur de programme dans le code natif principal à un emplacement de code en Java: les PC natifs sont mappés à une méthode Java et un index bytecode ("bci"). En raison de l'inlining, un seul PC est en fait associé à une pile de paires (méthode, bci).
• scopes data Ceci contient des métadonnées décrivant davantage l'état de la machine virtuelle Java sur ces PC. Il contient des données qui mappent les emplacements JVM (par exemple locaux ou emplacements de pile) vers des emplacements natifs (par exemple, des registres ou des emplacements de pile natifs). Cela permet à la machine virtuelle de savoir où rechercher Oops pendant GC ainsi que de reconstruire l'état de l'interprète pendant la désoptimisation.
• dependencies Ceci est une liste des "hypothèses" faites par le compilateur lors de la compilation de cette méthode. Une telle hypothèse pourrait être "la classe Foo n'a pas de sous-classes".Cela permet à la VM de savoir que cette méthode doit être invalidée si quelque chose viole plus tard cette hypothèse (comme charger une nouvelle classe qui est une sous-classe de Foo dans l'exemple précédent).
• handler table Cette table permet à la machine virtuelle de savoir où poursuivre l'exécution lors du déroulement en raison d'une exception.