Tutoriel pour comprendre la machine virtuelle Java

La JVM est une machine virtuelle multilangage et le nombre de langages supportés n'a pas cessé de grandir. Certains langages se limitent à de l'interprétation (même si elle est plus rapide sous Java 7 grâce au InvokeDynamic), mais les plus utilisés proposent également un compilateur pour passer du monde Scala, Groovy, Jruby, Jython, JavaScript à un fichier .class en bytecode.

De plus, d'autres outils proposent de générer des classes Java qui à leur tour s'exécuteront dans la JVM. Les JSP sont transformées en servlet .java via jspc (ou jasper sur tomcat) puis compilées en .class.

Pour les Web Service Soap, avec les fichiers XSD et WSDL, ce sont xjc et wsimport qui génèrent des classes java et .class à partir du XML. Il y a aussi des bascules entre JSON et sjava.

Enfin, il y a tout ce que l'on pourrait générer via de la génération de code maison avec du velocity et du freemarker. Le pire, c'est que ce code généré est très souvent ignoré dans les analyses de code statique de type Sonar, alors que la qualité du code généré ne lui permet pas toujours d'être optimisé par le compilateur JIT.

À la compilation en bytecode, aucune optimisation particulière n'est effectuée. C'est au moment de l'exécution qu'une optimisation dynamique sera effectuée sur les classes et les méthodes en ayant le plus besoin. Au début du lancement de la JVM, toutes les méthodes sont interprétées jusqu'à ce qu'un seuil en nombre d'exécutions soit atteint, et à condition que le code de la méthode à compiler ne soit pas trop long. C'est là qu'intervient le compilateur JIT (Just In Time) qui compile en assembleur, pour le processeur hôte (x86 ou x64 pour Intel), les instructions de bytecode.

Sur Android, le passage du mode interprété à un compilateur JIT a vu aussi une amélioration de performance, qui selon les benchmarks, passait sur le même appareil d'un facteur de 6 à 600, selon les tests dont en voici un sur le Nexus One (2010) lors du passage d'Android 2.1 à 2.2.

Sur les navigateurs Internet, ce compilateur JIT est également en place depuis quelques années pour que le code JavaScript soit lui aussi traduit en code assembleur. Firefox utilise le moteur IonMonkey qui possède un compilateur JIT, quant à Chrome avec le moteur V8, il utilise un autre moyen, la compilation dite “Ahead Of Time” (AoT) où toutes les classes JavaScript sont compilées en assembleur à leur première exécution.

Ce type de compilation AoT est également possible avec la JVM Oracle avec l'option -Xcomp. Cependant, nous y reviendrons plus tard, cela ajoute un temps de démarrage plus long et des optimisations précoces.

D'autres options sont possibles au lancement de la JVM :

• -Xint : pour un mode totalement interprété sans aucune traduction en assembleur par le JIT ;
• -Xmixed : qui est un compromis entre le tout compilé et le tout interprété. C'est aussi le mode par défaut de lancement de la JVM.

À noter que sur Android 4.4 (Kitkat), un nouveau mode d'exécution Java est disponible (mais non activé par défaut) : ART en remplacement de la JVM Dalvik. Ce que fait ART est une compilation Ahead Of Time au moment de l'installation de l'application.

Afin d'optimiser au mieux le code interprété (puis compilé en assembleur), la JVM a besoin d'obtenir des métriques sur les méthodes et ainsi de faire un profiling sur l'ensemble des méthodes des classes chargées.

Voici un aperçu avec neuf types d'optimisations différentes parmi plus de 64 proposés par la JVM de Java 7 :

• Inlining : c'est la fusion du code d'une méthode appelante avec le code de la méthode appelée. Il en existe quatre types différents, mais le plus courant est le “monomorphic inlining”, ex. System.currentTimeMillis() lors d'appel de méthodes statiques ;
• Escape analysis : analyse le code en profondeur et lorsque c'est possible, évite de créer des instances d'objets lorsque celles-ci pointent sur des valeurs qui ne bougent pas, et remplace l'expression par l'utilisation d'une constante ;
• CHA Class Hierarchy Analysis (analyse des héritages et du polymorphisme qui permet de dévirtualiser) : en cas de besoin de dévirtualiser une méthode polymorphe héritée. Cela permettra d'utiliser de l'inlining sur cette méthode ;
• Optimisation CPU x64, MMX, SSE : ajout dans le code assembleur des instructions x64 sur processeur 64 bits, et des optimisations MMX et SSE pour les calculs sur les types « float » et « double », et également la recopie de tableaux ⇒ après divers essais, SSE et MMX accélère surtout les JVM 32 bits, car cela leur met à disposition des registres 64 bits, alors qu'en passant à des JVM 64 bits, l'accélération est moins visible ;
• Loop unrolling : lorsqu'une boucle s'effectue sur peu d'éléments et de manière constante, l'optimiseur remplace la boucle par n-fois le corps de cette boucle ;
• Lock coarsening : lors d'une boucle où une méthode synchronisée est appelée n-fois (avec le mécanisme de verrou aussi appelé n-fois), l'optimiseur replace les “n synchronized” par un seul avant la boucle principale, ce qui optimise les ressources de verrous ;
• Lock eliding : élimine un bloc “synchronized” lorsque celui-ci n'est pas nécessaire ;
• Dead code elimination : élimination du code mort (ex. condition irréalisable) ;
• Duplication code elimination : suite à une première optimisation, simplification du code optimisé.

La JVM a deux types de stratégies correspondant à deux compilateurs JIT différents :

• Démarrage rapide et optimisation moyenne : c'est le mode -client ou Compilateur C1 ;
• Profiling plus long des méthodes, mais meilleure optimisation : c'est le mode -server ou Compilateur C2.

Sur le JDK Oracle, un nouveau mode a fait son apparition depuis Java 6, c'est le mode Tiered (nivelé en français). Il tente de regrouper les qualités des deux compilateurs C1 (-client) et C2 (-server). Après des benchmarks, les résultats que j'ai obtenus ne sont pas assez probants. On peut jouer sur les paramètres suivants : -XX:+TieredCompilation ; seul ou en ajoutant -XX:TieredStopAtLevel=1 (jusqu'à 4 qui est la valeur par défaut).

Autre type de compilation : l'OSR (On Stack Remplacement). C'est une compilation à la volée lors d'une boucle sur une méthode encore en bytecode avec un nombre élevé d'itérations. C'est le cœur de la méthode qui est alors transformé en code assembleur juste pour l'exécution en cours. C'est une compilation “éphémère”, mais qui peut accélérer des boucles répétées un nombre de fois très élevé.

Sinon, alors que côté Microsoft et sa CLR, il a fallu attendre le framework dotNet 4.5 pour avoir la compilation assembleur en tâche de fond, celle-ci est disponible par défaut depuis Java 5.

Un dernier moyen d'optimiser le temps de lancement de la JVM et de la compilation est d'avoir déjà sous la main le code assembleur des classes du noyau (RT) de la JVM, c'est ce que fait le JDK Sun, puis Oracle depuis la version 5 via l'utilisation des classes JSA. Par défaut, le système tente de les utiliser et continue à fonctionner s'il ne parvient pas à les utiliser (l'activation se fait par -Xshare:dump ou -Xshare:on).

La JVM IBM j9 utilise aussi un moyen équivalent via l'option de démarrage -Xshareclasses.

Avec Java 8, est prévu également le multitenant dont le but est de centraliser les classes communes entre applications tournant dans la JVM et aussi de n'avoir qu'une seule copie des méthodes transformées en assembleur par le JIT, et ainsi économiser du temps de compilation et de la mémoire. Cependant l‘utilisation de debug, de profiling et d'agent (instrumentation) est problématique dans ce mode.

À noter que dans le monde des machines virtuelles, Microsoft avec la CLR a aussi de la compilation “AoT” via l'outil ngen qui propose une version du bytecode dotNet (IL), compilée en assembleur, mais sans profiling et donc avec une optimisation moindre.

Une autre solution proposée par Microsoft n'existe pas encore dans la JVM est MPOG : Managed Profiled Guided Optimization, dont le but est de réconcilier les deux mondes JIT et AoT via la création d'un profiling JIT pendant l'exécution de l'application, puis une compilation “Ahead Of Time” prenant en compte les informations de profiling lors de la phase précédente. Le gain de performance pourrait être de 25 % par rapport à du “simple” AoT via ngen.

Ici s'arrête le 1er article de cette série sur les optimisations de la JVM. Le second article traitera des options permettant de constater toutes les compilations JIT.

Voici un test contenant de mauvaises pratiques sur la taille des méthodes. Le code possède volontairement une initialisation de tableau très longue (remplie de « Double.valueOf("445"),.. ») dans les méthodes à tester.

public static void tresGrosseMethode17643opcode() {
    double[] testBidon = new double[] {
        Double.valueOf("445"), Double.valueOf("445"),.. 
    };                       
    double sum = 0.0d;
    final int taille = 100;
    for (int i = 0; i < 10000; i++) {
        for (int idx = 0; idx < taille; idx++) {
            sum += testBidon[idx];
            sum /= 1.00001d;
        }
    }
}

Bilan sur le test de vitesse d'exécution selon la taille des méthodes.

• Plus les JVM sont récentes (java 7 et +), plus le gain en réduisant la taille des méthodes est perceptible.
• La taille idéale d'une méthode semble être vers les 80 à 300 octets de bytecode, ce qui est difficilement traduisible en nombre de lignes, mais disons autour des 20 à 30 lignes de code. Cependant, sans JVM java 7 ou 8 en -server, aucune amélioration de vitesse ne sera constatable.
• Le découpage à l'extrême des méthodes en sous-méthodes plus petites peut donner de mauvais résultats surtout avant compilation et optimisation globale de l'ensemble. Après une phase de "warm up" et lorsque la JVM le permet, les temps de réponse sont optimisés.
• Oracle Java 6 aussi bien 32 bits que 64 bits n'arrive pas à optimiser des méthodes de taille intermédiaire (entre 1 et 7999 octets de bytecode)
• L'option « -XX:DesiredLimitMethod=xxxx » activable uniquement en JDK 1.6 n'a aucune influence directe sur la rapidité d'exécution des méthodes contrairement à ce que l'option laisse supposer.
• Pour Oracle Java 7, entre la version -client et -server, il y a une différence de vitesse de 770 en faveur du mode -server. De même, Java 7 (en mode -server) a des performances bien meilleures que Java 6.
• Sur la JVM Oracle, les paramètres de tuning de l'inlining suivant semblent inefficaces : -XX:-ClipInlining, -XX:InlineSmallCode=xxx et -XX:MaxInlineSize=xxx et n'ont aucune influence directe.
• De même, l'inlining s'arrête lorsque la limite de « DesiredLimitMethod » (8 ko) de bytecode est atteinte. La JVM parle de « clipping » de l'inlining. En conséquence, si les méthodes fusionnées arrivent au total à moins de 8 ko, elles seront plus rapides que lorsqu'on a atteint la limite des 8 ko et qu'aucun inlining ne peut plus arriver en fin de méthode appelante.
• Depuis la version 7 (et supérieure), le paramètre « DesiredLimitMethod ) est en dur dans globals.hpp du code source du JDK (voir ligne 3553).
• Les options de compilation « -XX :TieredCompilation » et « -XX :TieredStopAtLevel=1 à 4 » sont dépendantes du -client ou -server. Globalement les performances sont meilleures avec le niveau 4 (qui est la valeur par défaut).
• Sur la JVM java 7 d'Oracle, une amélioration de vitesse se fait sentir lorsque celle-ci est en dessous du seuil de 2 ko de bytecode (jusqu'à 3 à 4 fois plus rapide par rapport à des méthodes comprises entre 2 ko et 8 ko) et encore plus vers 300 à 80 octets de bytecode.
• Sur la JVM 1.6 d'IBM (J9) en 32 bits, dès que la taille d'une méthode arrive en dessous du seuil de 4870 octets de bytecode, la méthode voit sa vitesse s'améliorer d'un facteur 54 minimum (268 fois après un "warm up" sur le test effectué).
• Sur la JVM 1.6 d'IBM (J9), le "warm up" d'une méthode fortement découpée peut être lent, mais une fois en place, la méthode peut être jusqu'à plus de 1000 fois plus rapide que si la méthode dépasse 4870 octets de bytecode.
• Sur la JVM IBM en java 7 64 bits, il n'y a pas de limitation de taille sur les méthodes à compiler en code assembleur. Les méthodes sont plus rapides qu'en Java 6 IBM. De même que pour Java 7 Oracle (en -server), en dessous de 2 ko de bytecode, les méthodes sont encore plus rapides.
• La JVM Jrockit Java 6 32 bits a également un seuil à 4 ko de bytecode ou, lorsqu'une méthode est en dessous de quelques octets de code, elle voit sa vitesse augmenter par 10 minimum.

Voici un autre test pour vérifier la réaction de l'inlining lors de fusion entre de grandes méthodes appelées ou appelantes avec des petites méthodes appelantes ou appelées.

public static void step1_grandCallerNotInline1165opcode() {
    double[] tmp = new double[] {
        Double.valueOf("445"), 
        Double.valueOf("445"),
        Double.valueOf("445"), 
        Double.valueOf("445"), ... Encore beaucoup ...
    };
    double[] testBidon = Arrays.copyOf(tmp , 100 );
    for (int i = tmp.length; i < 100; i++) {
        testBidon[i] = Double.valueOf("445");
    }
    step1_petitCalleeNotInline52opcode(testBidon);
}

public static void step1_petitCalleeNotInline52opcode(double[] testBidon) {
    double sum = 0.0d;
    final int taille = 100;
    for (int i = 0; i < 10000; i++) {
        for (int idx = 0; idx < taille; idx++) {
            sum += testBidon[idx];
            sum /= 1.00001d;
        }
    }
}

Bilan sur le test de vitesse d'exécution selon la taille des méthodes appelantes et appelées :

• indépendamment des versions de JDK, si la taille de la méthode appelée ou appelante devient trop grande, la vitesse est moindre ;
• sur l'ensemble des tests sur les JVM, le résultat est plus homogène lorsqu'on utilise une méthode appelante plus petite que la méthode appelée ; celle-ci peut être plus grande ou de taille quasi équivalente à la première ;
• même avec plusieurs essais et une séance de "warm up", les résultats sont parfois surprenants, il est donc peu évident de tirer des conclusions définitives ;
• en général, les JDK 32 bits (6 et 7) en mode -client sont incapables d'accélérer les petites méthodes appelées ou appelantes.

Le dernier test consiste à vérifier le comportement de la JVM lorsque les méthodes sont suffisamment courtes (environ moins de six lignes de code). En effet, les méthodes ne dépassant pas 35 octets de bytecode de code sont éligibles à un « Full Inlining » qui est une fusion directe des méthodes appelées et appelantes. L'idée du test est de vérifier le comportement de la JVM, sa capacité à fusionner plusieurs petites méthodes et l'influence des paramètres lors des appels de méthodes :

private static double[] step1_fullInlinableCreate2Values_Test1() {
    return new double[] {
        Double.valueOf("445"), Double.valueOf("445")
    };
}

private static void step1_fullInlinedFillArrayInLoop_Test1(final int nbElementsCrees,double[] testBidon, int i) {
    double[] tmpArray = step1_fullInlinableCreate2Values_Test1();
    for (int idx=0; idx < nbElementsCrees; idx++) {
        testBidon[(i*nbElementsCrees)+idx] = tmpArray[idx];
    }
}

/**
* Test inlining avec le corps de la méthode dans la boucle + plusieurs paramètres en E/S.
*/
public static void step1_methodeAvecTresPetitInlining_Test1() {
    final int nbElementsCrees = step1_fullInlinableCreate2Values_Test1().length;
    final int maxElements = 4200; // supérieur à 8000
    double[] testBidon = new double[maxElements*nbElementsCrees];
    for (int i = 0; i < maxElements; i++) {
        step1_fullInlinedFillArrayInLoop_Test1(nbElementsCrees, testBidon, i);
    }

    double sum = 0.0d;
    final int taille = 100;
    for (int i = 0; i < 10000; i++) {
        for (int idx = 0; idx < taille; idx++) {
            sum += testBidon[idx];
            sum /= 1.00001d;
        }
    }
}

Bilan sur le test de vitesse d'exécution selon la taille des méthodes appelantes et appelées.

• De manière générale, à trop découper les méthodes dans lesquelles on a des "for" imbriqués, on a des contre-performances. Exemple : une méthode de 30 lignes découpées en cinq méthodes de six lignes. On arrive aux limites de l'inlining des JVM actuelles et c'est finalement au moins 20 fois plus lent que des méthodes de taille intermédiaire d'environ 20 à 30 lignes de code.
• Plus on prend une version récente du JDK, plus c'est optimisé pour les petites tailles de méthodes.
• Il y a peu de différences dans l'appel des méthodes si la boucle "for" est en dehors ou à l'intérieur de la méthode appelée.
• Il y a peu de différences si l'appel d'une méthode utilise le passage par plusieurs paramètres ou le passage d'une référence de type databean. Sauf pour le JDK 7 et 8 en 64 bits où, après "warm up", l'utilisation d'un databean ou d'attributs privés semble être meilleurs que l'envoi de tableau en paramètre.

Bilan sur l'ensemble des trois tests.

• Les options Oracle qui marchent (mais à ne pas désactiver) : désactivation de l'OSR (-XX:-UseOnStackReplacement), désactivation d'une partie de l'inlining (-XX:-Inline), désactivation de l'Escape Analysis (-XX :-DoEscapeAnalysis).
• Sur la JVM Oracle, l'option -XX:+TieredCompilation ne réagit pas pareil lorsqu'on force -client ou -server. Dans la majorité des tests, les résultats sont meilleurs avec -server .
• La compilation AoT (via -Xcomp ou IBM -Xjit:count=0) n'est pas la meilleure idée pour de bonnes performances, car toutes les méthodes sont compilées à la 1re exécution. Il faut un temps de "warm up" beaucoup plus long pour des applications lancées avec cette option. L'option par défaut « -Xmixed » reste le meilleur compromis.
• Si vous travaillez sur une JVM en OS virtualisé, vérifiez bien que le mode SSE4 et 4.2 du CPU sont activés, le risque est de perdre en temps de réponse lors de calculs intensifs.
• Le paramètre pour changer le seuil de 1 ko pour l'inlining semble ne pas fonctionner ou être inefficace, car il n'y a aucun changement notable quand on le change
• La JVM a besoin d'un “warm up” pour tirer parti de sa quintessence. C'est à prendre en compte pour des tests de performance Web ou batch et également pour des "micro-benchmarks".

Pour information, en pièce jointe, se trouvent le code source des classes de tests. Je n'ai pas cherché à le rendre "beau", mais j'y ai mis l'essentiel pour les tests à effectuer.