Tutoriel sur la compréhension de la machine virtuelle Java

• Stack = Pile = Liste Last In First Out (LIFO).
• Empiler (push) : ajouter un élément en tête de liste.
• Dépiler (pop) : retirer l'élément en tête de liste.

La JVM supporte seulement cinq types de données :

• int ;
• long ;
• float ;
• double ;
• reference.

Les quatre premiers types sont identiques aux types Java du même nom. Les types Java boolean, byte, short et char sont tous traités comme des int par la JVM.

En revanche, il est possible d'avoir des tableaux de bytes, short et char comme nous le verrons plus tard.

Les types long et double prennent deux entrées dans la pile, alors que tous les autres n'en prennent qu'une.

Une reference est une référence à un objet Java. Une référence pointe vers un objet présent dans le tas (heap). Contrairement aux types numériques, un objet a des propriétés indépendantes de la référence à l'objet.

Contrairement au C (une référence pouvant être comparée à un pointeur) une fois qu'une référence pointe vers un objet, elle pointe toujours vers le même objet et par conséquent, il n'est pas possible d'effectuer une quelconque opération sur une référence.

Une mnémonique est une forme textuelle (simplifiant la lecture/écrire du code pour un être humain) représentant une opération (additionne, charge, stocke, etc.). Chaque mnémonique correspond à un nombre entre 0 et 255 dans un fichier .class. Ce nombre est appelé le code d'opération (opcode).

Les mnémoniques utilisées par PJBA sont celles définies dans la JVMS. Généralement, le premier caractère d'une mnémonique indique le type sur lequel il opère. Par exemple, iadd permet d'ajouter des int et rien d'autre. Néanmoins, il n'existe pas forcément une mnémonique pour chaque type. Certaines opérations sont possibles uniquement sur un nombre réduit de types, par exemple les opérations bit à bit qui ne fonctionnent qu'avec des int ou des long.

Pour rappel 1 byte = 1 octet = 8 bits et 1 word = 2 bytes = 16 bits.

* l'espace mémoire utilisé pour une référence d'un objet est de 32 bits ou 64 bits en fonction de la JVM utilisée.

Écrire un programme, c'est exécuter deux différentes tâches : définir des structures de données et définir des opérations à effectuer sur ces données. Dans la JVM, l'unité fondamentale d'opération est l'instruction.

En bytecode, tout comme en assembleur, une instruction effectue des opérations atomiques. En d'autres termes, il est généralement nécessaire d'avoir plusieurs instructions pour effectuer une opération prenant une ligne en Java (au tout autre langage de haut niveau).

En bytecode, les instructions sont présentes uniquement dans des méthodes.

Dans cette partie et les suivantes, nous étudierons les quelque 203 instructions de la JVM.

Nous commencerons par voir les instructions permettant de retourner une valeur à une méthode appelante, de manipuler des données des variables locales et de la pile.

Une mnémonique peut avoir des arguments qui le suivent tels que :

ldc "Hello World"

Le nombre d'arguments dépend de la mnémonique. Certains n'en prennent aucun et d'autres plusieurs. Ce nombre est fixe pour chaque mnémonique.

En revanche, les opérandes sont récupérés de la pile :

iadd

l'opération iadd prend les deux premiers éléments de la pile est les additionne. Les opérandes ne sont donc pas passés en arguments.

La JVM étant basée sur le modèle de la pile, il est essentiel de connaître quel est l'impact des instructions. Pour représenter l'état avant/après l'exécution d'une instruction, nous allons reprendre le format utilisé par la JVMS et qui est le suivant :

…, valeur1, valeur2 → …, résultat, où les valeurs le plus à droite sont au sommet de la pile. valeur1 et valeur2 étant les deux valeurs utilisées pour le calcul et résultat le résultat.

Il est important de noter que dans cette représentation les long et le double sont considérés comme une seule valeur. Par conséquent, lorsque nécessaire nous présenterons les différents cas d'utilisation d'une instruction en utilisant plusieurs formes.

Quand une méthode a terminé de s'exécuter, elle doit rendre le contrôle à la méthode appelante. L'appelant attend généralement une valeur/référence de la méthode appelée. Après qu'une instruction xreturn (où x est un type) soit exécutée, le contrôle est transféré à l'instruction suivant l'une des instructions invoke (utilisées pour appeler un méthode, nous étudierons les instructions invoke en détail dans une prochaine partie). La valeur au sommet de la pile avant l'exécution d'une instruction xreturn est retournée à l'appelant et est placée au sommet de la pile du cadre contenant la méthode appelante comme nous l'avons vu dans la partie JVM Hardcore - Introduction à la JVM.

La valeur retournée doit être du type indiqué dans le descripteur de la méthode.

Les instructions suivantes retournent la valeur/référence présente au sommet de la pile à l'appelant :

État de la pile avant → après exécution : …, valeur → [vide]

Les instructions suivantes ajoutent une constante au sommet de la pile :

État de la pile avant → après exécution : … → …, constante

La JVM supporte des constantes de type int, float, long, double et String.

La JVM est optimisée pour utiliser de petites constantes en fournissant des instructions spéciales pour les charger. Cela évite de rajouter des entrées supplémentaires dans le pool de constantes.

Pour les nombres les plus communs, il y a les instructions xconst_n où x est le type et n la valeur à empiler.

Pour ajouter une référence nulle au sommet de la pile, nous pouvons utiliser l'instruction aconstant_null :

.class org/isk/jvmhardcore/bytecode/partthree/Aconst_null
  .method get()Ljava/lang/Object;
    aconst_null
    areturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void aconst_null() {
  final Object obj = Aconst_null.get();
 
  Assert.assertNull(obj);
}

Source

La méthode suivante retourne un int ayant pour valeur -1 :

.class org/isk/jvmhardcore/bytecode/partthree/Iconst_m1
  .method get()I
    iconst_m1
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iconst_m1() {
  final int num = Iconst_m1.get();
 
  Assert.assertEquals(-1, num);
}

Source

La méthode suivante retourne un double ayant pour valeur 1 :

.class org/isk/jvmhardcore/bytecode/partthree/Dconst_1
  .method get()D
    dconst_1
    dreturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void dconst_1() {
  final double num = Dconst_1.get();
 
  Assert.assertEquals(1.0, num);
}

Source

Dans les trois exemples précédents, les éléments à prendre en compte sont les suivants :

• le descripteur des méthodes et notamment leur type de retour ;
• les préfixes des instructions.

Essayons de retourner un type différent de ce qui est défini dans le descripteur :

class org/isk/jvmhardcore/bytecode/partthree/WrongReturnType
  .method get()I
    dconst_1
    dreturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void wrongReturnType() {
  try {
    WrongReturnType.get();
    Assert.fail();
  } catch (VerifyError e) {
    // Assertion
    // Message retourné par la JVM:
    //   (class: org/isk/jvmhardcore/bytecode/partthree/WrongReturnType,
    //   "method: get signature: ()I) Wrong return type in function
  }
}

Source

Lors de l'étape de vérification de la JVM une exception de type VerifyError est levée, nous indiquant que le type de retour de la méthode get() est incorrect. Il s'agit d'un entier alors que l'on utilise l'instruction dreturn retournant un double.

De même, si l'instruction xreturn ne correspond pas au type de l'élément au sommet de la pile, une exception est levée :

.class org/isk/jvmhardcore/bytecode/partthree/WrongTypeReturned
  .method get()D
    dconst_1
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void wrongTypeReturned() {
  try {
    WrongTypeReturned.get();
    Assert.fail();
  } catch (VerifyError e) {
    // Assertion
    // Message retourné par la JVM:
    //   (class: org/isk/jvmhardcore/bytecode/partthree/WrongTypeReturned, 
    //   method: get signature: ()D) Expecting to find integer on stack
  }
}

Source

Nous verrons l'étape de vérification effectuée par la JVM dans quelques parties.

Pour de petits entiers n'étant pas disponibles sous la forme xconst_n, il y a les instructions bipush et sipush. Ces deux instructions prennent les valeurs en arguments comme les instructions ldc. En bytecode bipush et sipush prennent en arguments les valeurs à empiler (sur 1 byte pour bipush et 2 bytes sur sipush) et non des index contrairement aux instructions ldc. Par conséquent, si une constante est incluse dans l'intervalle [-32 768; 32 767] il est préférable de ne pas utiliser l'instruction ldc.

Utilisation de l'instruction bipush :

.class org/isk/jvmhardcore/bytecode/partthree/Bipush
  .method get()B
    bipush 117
    ireturn
 .methodend
.classend

Source

Test unitaire :

@Test
public void bipush() {
  final byte num = Bipush.get();
 
  Assert.assertEquals(117, num);
}

Source

Utilisation de l'instruction sipush :

.class org/isk/jvmhardcore/bytecode/partthree/Sipush
  .method get()S
    sipush 14909
    ireturn
 .methodend
.classend

Source

Test unitaire :

@Test
public void sipush() {
  final short num = Sipush.get();
 
  Assert.assertEquals(14909, num);
}

Source

Dans les deux exemples précédents, l'instruction de retour utilisée est ireturn et le type de retour des méthodes est respectivement B et S, puisque comme nous l'avons vu, la JVM ne manipule pas ces types. Par conséquent, nous pouvons aussi utiliser I comme type de retour :

.class org/isk/jvmhardcore/bytecode/partthree/Bipush_int
  .method get()I
    bipush -117
    ireturn
 .methodend
.classend

Source

Test unitaire :

@Test
public void bipush_int() {
  final int num = Bipush_int.get();
 
  Assert.assertEquals(-117, num);
}

Source

Pour les instructions de type ldc, en PJBA, n représente une valeur littérale alors qu'en bytecode, il s'agit d'un index dans le pool de constantes de la classe (que nous verrons un peu plus tard).

La partie _w des instructions ldc_w et ldc2_w signifie « wide » (large). Concrètement, l'index sur lequel pointent ces instructions prend 2 bytes, au lieu d'un.

Les instructions ldc et ldc_w sont équivalentes, à l'exception que ldc_w pointe sur un index prenant 2 bytes, au lieu d'un pour ldc. PJBA générant le pool de constantes, il choisit l'instruction convenant à la situation. Dans un fichier .pjb, il est possible d'utiliser uniquement l'instruction ldc.

Dans l'instruction ldc2_w, le 2 signifie que la constante prend deux entrées dans la pile.

Voyons quelques exemples.

L'instruction ldc peut prendre toute chaîne de caractères UTF-8 entre guillemets. Pour pouvoir insérer un guillemet au milieu d'une chaîne de caractère, il faut l'échapper (\”).

.class org/isk/jvmhardcore/bytecode/partthree/Ldc_String
  .method getString()Ljava/lang/String;
    ldc "Привет \\\" мир по-русски"    @ Hello world " en russe
    areturn    @ Une chaîne de caractères est de type java/lang/String
  .methodend
.classend

Source

Test unitaire :

@Test
public void ldc_string() {
  final String result = Ldc_String.getString();
 
  Assert.assertEquals("Привет \\\" мир по-русски", result);
}

Source

L'instruction ldc avec un int :

.class org/isk/jvmhardcore/bytecode/partthree/Ldc_Integer
  .method getInteger()I
    ldc 1000
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void ldc_integer() {
  final int result = Ldc_Integer.getInteger();
 
  Assert.assertEquals(1000, result);
}

Source

L'instruction ldc avec un float :

.class org/isk/jvmhardcore/bytecode/partthree/Ldc_Float
  .method getFloat()F
    ldc -15.56e-12
    freturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void ldc_float() {
  final float result = Ldc_Float.getFloat();
 
  Assert.assertEquals(-15.56e-12f, result);
}

Source

L'instruction ldc2_w avec un long :

.class org/isk/jvmhardcore/bytecode/partthree/Ldc_Long
  .method getLong()J
    ldc2_w 1324
    lreturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void ldc2_w_long() {
  final long result = Ldc_Long.getLong();
 
  Assert.assertEquals(1324l, result);
}

Source

L'instruction ldc2_w avec un double :

.class org/isk/jvmhardcore/bytecode/partthree/Ldc_Double
  .method getDouble()D
    ldc2_w -14.70e-43
    dreturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void ldc2_w_double() {
  final double result = Ldc_Double.getDouble();
 
  Assert.assertEquals(-14.70e-43, result);
}

Source

Dans la partie suivante, nous verrons des instructions permettant de manipuler les variables locales.