Tutoriel sur la compréhension de la machine virtuelle Java

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 « valeur »2 é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 le 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.

Comme nous l'avons vu dans la partie Part II - Introduction à la JVM, la JVM utilise les variables locales pour passer des paramètres à la méthode appelée. Lorsqu'une méthode de classe (statique) est appelée, tous les paramètres sont stockés dans les variables locales de manière consécutive à partir de l'index zéro. Lorsqu'une méthode d'instance est appelée, la variable à l'index zéro est toujours une référence de l'objet (this) sur laquelle la méthode a été appelée. Les paramètres sont quant à eux stockés de manière consécutive à partir de l'index 1.

Néanmoins, les variables locales étant aussi utilisées pour stocker des résultats partiels, les paramètres d'une méthode ou this peuvent être remplacés.

À noter que pour l'instant, PJBA permettant uniquement de générer des méthodes statiques, leurs paramètres sont accessibles à partir de l'index 0 des variables locales.

Les instructions suivantes permettent de récupérer des valeurs depuis les variables locales. Les valeurs sont ajoutées au sommet de la pile (mais sont toujours disponibles dans les variables locales).

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

Voyons quelques exemples :

Empile une chaîne de caractères avec aload:

.class org/isk/jvmhardcore/bytecode/partfour/Aload
  .method getThird(BILjava/lang/String;J)Ljava/lang/String;
    aload 2
    areturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void aload() {
  final String result = Aload.getThird((byte)1, 2, "Hello", 4l);
 
  Assert.assertEquals("Hello", result);
}

Source

Empile un long avec lload :

.class org/isk/jvmhardcore/bytecode/partfour/Lload
  .method getFourth(BILjava/lang/String;J)J
    lload 3
    lreturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void lload() {
  final long result = Lload.getFourth((byte)1, 2, "Hello", 4l);
 
  Assert.assertEquals(4l, result);
}

Source

Empile l'int dans les variables à l'index 0 avec iload_0 :

.class org/isk/jvmhardcore/bytecode/partfour/Iload_0
  .method getFirst(III)I
    iload_0
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iload_0() {
  final int result = Iload_0.getFirst(1, 2, 3);
 
  Assert.assertEquals(1, result);
}

Source

Empile l'int dans les variables à l'index 0 avec iload_0 et retourne un byte :

.class org/isk/jvmhardcore/bytecode/partfour/Iload_0_Byte
  .method getFirst(BII)B
    iload_0
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iload_0_byte() {
  final byte result = Iload_0_Byte.getFirst((byte) 1, 2, 3);
 
  Assert.assertEquals(1, result);
}

Source

Empile l'int dans les variables à l'index 0 avec iload_0 et retourne un char :

.class org/isk/jvmhardcore/bytecode/partfour/Iload_0_Char
  .method getFirst(CII)C
    iload_0
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iload_0_char() {
  final char result = Iload_0_Char.getFirst((char) 1, 2, 3);
 
  Assert.assertEquals(1, result);
}

Source

Empile l'int dans les variables à l'index 0 avec iload_0 et retourne un short :

.class org/isk/jvmhardcore/bytecode/partfour/Iload_0_Short
  .method getFirst(SII)S
    iload_0
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iload_0_short() {
  final short result = Iload_0_Short.getFirst((byte) 1, 2, 3);
 
  Assert.assertEquals(1, result);
}

Source

Essaie de retourner la valeur à l'index 0 des variables locales.

.class org/isk/jvmhardcore/bytecode/partfour/Iload_0_NoArgs
  .method getFirst()I
    iload_0
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iload_0_noargs() {
  try {
    Iload_0_NoArgs.getFirst();
    Assert.fail();
  } catch (VerifyError e) {
    // Assertion
    // Message retourné par la JVM:
    //   (class: org/isk/jvmhardcore/bytecode/partfour/Iload_0_NoArgs, 
    //   method: getFirst signature: ()I) Accessing value from uninitialized register 0"
  }
}

Source

La méthode n'ayant pas de paramètre et aucune instruction de stockage dans les variables locales n'ayant été effectuée, il n'y a rien à l'index 0. Par conséquent, une exception est levée.

Empile l'int dans les variables à l'index 1 avec iload_1 :

.class org/isk/jvmhardcore/bytecode/partfour/Iload_1
  .method getSecond(III)I
    iload_1
    ireturn
  .methodend
.classend

Source

Test unitaire :

@Test
public void iload_1() {
  final int result = Iload_1.getSecond(1, 2, 3);
 
  Assert.assertEquals(2, result);
}

Source

Les instructions suivantes permettent de stocker la variable au sommet de la pile dans les variables locales. La valeur au sommet de la pile est supprimée.

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

Contrairement à Java, les variables sont typées dynamiquement. Par conséquent, il est possible de stocker les cinq types connus de la JVM à n'importe quel index des variables locales. Une variable locale peut donc avoir des valeurs différentes à différents moments.

Prenons le code suivant :

.class org/isk/jvmhardcore/bytecode/partfour/Reassign
  .method reassign()D
    ldc "ma chaîne"
    astore_0
    aload_0
    dconst_1
    dstore_0
    dload_0
    dreturn
  .methodend
.classend

Source

Voyons ce qu'il se passe dans le cadre contenant la méthode reassign() :

Pour finir testons la méthode reassign() :

@Test
public void reassign() {
  final double result = Reassign.reassign();
 
  Assert.assertEquals(1.0, result, 0.00001);
}

Source

Tout comme de nombreuses instructions que nous avons vues dans la partie précédente, load et store sont liées à des types. Ces types sont identifiables - le plus souvent - grâce à la première lettre de la mnémonique de l'instruction. De fait, il est nécessaire de faire attention à utiliser l'instruction correspondant aux types des valeurs présentes dans la pile et qui seront utilisées comme opérandes.

ldc  "ma chaîne"
istore 0            # Erreur! astore doit être utilisé

Les variables de type long et double prennent deux entrées dans la pile et les variables locales.

ldc  "ma chaîne"
astore_2
ldc2_w 3.14d
dstore_1
aload_2         # Erreur! Une partie du double a remplacé "ma chaîne"

Pour finir notre tour des points d'attention, il est important de noter qu'une variable locale doit être initialisée avant d'être utilisée.

iconst_5    # Empile 5
istore_3    # Stocke 5 dans la variable locale à l'index 3
iload_3     # Récupère la valeur (5) stockée dans la variable locale à l'index 3

Pour rappel, le tableau des variables locales - d'un cadre - est automatiquement initialisé par la JVM avec les paramètres de la méthode en cours d'exécution, si elle en a.

Dans la partie suivante, nous verrons des instructions permettant d'effectuer des opérations sur des nombres, mais aussi de changer le type des nombres.