La JVM expose de nombreux paramètres permettant de contrôler son exécution. L'en-semble de ses paramètres et les valeurs associées dénissent la conguration de la JVM. Comme détaillé dans la section précédente (cf. Section 3.3.2), les micro-benchmarks requiert un contrôle précis des paramètres d'exécution pour garantir la consistance des mesures. Cette section dresse la liste des diérents paramètres impliqués dans la conguration de la JVM HotSpot lors de l'exécution d'un micro-benchmark, avec pour chacun l'eet es-compté.
Les paramètres listés sont les paramètres servant de base à la conguration des micro-benchmarks. Ils ne constituent pas une liste exhaustive des paramètres pouvant être utili-sés pour contrôler le comportement de la JVM et l'état du code généré. Ils se déclinent en plusieurs catégories :
1. Réglage de la politique de compilation (cf. Table 3.4) ;
3. Directives au JIT (cf. Table 3.6) ;
4. Proling et désoptimisation (cf. Table 3.7).
Les catégories 1, 2 et 3 permettent de garantir et favoriser le contrôle du bon état d'exé-cution du code au moment des mesures (cf. Table 3.8). La catégories 4 regroupe les para-mètres de base permettant de contrôler la spécialisation du code due au proling ainsi que la désoptimisation (cf. Table 3.2).
Paramètre Eet
-XX:-TieredCompilation Désactive le mode étagé, actif par défaut, pour le mode non-étagé (cf Section 2.3.2.3 Chap. 2).
-XX:-BackgroundCompilation -XX:CICompilerCount=1
Désactive la compilation en arrière plan.
Fixe le nombre de threads du JIT à 1 ce qui garantit que deux méthodes distinctes ne seront pas compilées de manière concurrente.
Ces deux paramètres sont utilisés de manière combinée pour garantir la correspondance entre l'ordre des évènements a-chés sur la sortie standard (cf. Table 3.5) et l'ordre d'exécu-tion. Ils permettent ainsi de garantir l'état du code.
-XX:-UseOnStackReplacement
Désactive l'OSR.
Ore un meilleur contrôle sur la compilation.
Permet d'empêcher la compilation OSR de getBestTime pou-vant inliner compute et perturber les résultats.
D'autres paramètres peuvent être utilisés pour empêcher l'in-lining.
-XX:CompileThreshold=10000
En mode étagé et sans OSR, correspond au nombre d'occur-rences d'exécution d'une méthode avant qu'elle ne soit com-pilée par C2.
Par exemple, lorsque le paramètre vaut 10 000, la méthode ne sera plus interprétée mais exécutée avec le code généré par C2 à partir de la 10 001 ième occurrence.
Ainsi, pour garantir que la méthode compute soit compilée, le paramètre WU utilisé par getBestTime (cf. Figure 3.1) doit être supérieur à ce seuil.
Tab. 3.4: Conguration de la JVM HotSpot utilisée pour les micro-benchmarks : pa-ramètres permettant de régler la politique de compilation (sous fond bleu gurent les paramètres dont les valeurs dièrent de celles par défaut et servant de base xe à la con-guration)
Paramètre Eet
-XX:+PrintCompilation -XX:+PrintInlining7
Achent les logs du JIT sur la sortie standard lorsqu'une mé-thode est compilée, invalidée ou rendue inactive. Lorsqu'une méthode est compilée les méthodes inlinées sont également af-chées.
Sont utilisées conjointement aux options Table 3.4 pour garan-tir l'état du code au moment des mesures.
Peuvent-être désactivées lorsque les seuils sont bien ajustés. Tab. 3.5: Conguration de la JVM HotSpot utilisée pour les micro-benchmarks : para-mètres permettant de contrôler et de garantir le niveau d'exécution du code (sous fond bleu gurent les paramètres dont les valeurs dièrent de celles par défaut et servant de base xe à la conguration)
Paramètre Eet
-XX:CompileCommand=... -XX:CompileCommandFile=...
Permet, pour une méthode donnée, de passer des direc-tives au JIT. Parmi ces direcdirec-tives on a :
• dontinline : elle permet d'empêcher l'inlining d'une méthode. Elle est utilisée dans notre cas pour empê-cher l'inlining de compute (cf. Table 3.8) ou du code testé lorsqu'il est encapsulé dans une méthode ;
• dontcompile : elle permet d'empêcher la compilation d'une méthode. Elle peut être utilisée pour empêcher la compilation OSR de getBestTime lorsque l'OSR est activé pour respecté le bon état lors des mesures (cf. Table 3.8) ;
• print : elle permet d'acher le code assembleur gé-néré par le JIT pour une méthode donnée. Elle permet de scruter le code généré par le JIT pour l'analyse des performances.
Notons que cette option ne peut pas être utilisée pour visualiser le code des méthodes natives (i.e. le code ser-vant d'interface et appelant la fonction native depuis la libraire dynamique). Pour cela il faut utiliser l'op-tion -XX:+PrintNativeNMethods qui est cependant globale à toutes les méthodes natives.
Tab. 3.6: Conguration de la JVM HotSpot utilisée pour les micro-benchmarks : para-mètres permettant de passer des directives au JIT (sous fond bleu gurent les parapara-mètres dont les valeurs dièrent de celles par défaut et servant de base xe à la conguration)
Paramètre Eet -XX:-UseTypeProfile
Désactive le proling de type.
Permet de garantir que le JIT produira un code gé-nérique (non spécialisé aux données d'entrée) pour le code mesuré.
-XX:InterpreterProfilePercentage=33
En mode non-étagé et sans OSR, correspond au nombre d'occurrences d'exécution d'une mé-thode (en pourcentage de la valeur xée par -XX:CompileThreshold) avant que l'interpréteur ne commence à recueillir les données de proling pour cette méthode.
Ainsi, lorsque -XX:CompileThreshold=10000, l'in-terpréteur commencera à proler la méthode compute à partir de l'itération 3 300 durant l'exé-cution de getBestTime.
-XX:PerBytecodeTrapLimit=4 -XX:PerMethodTrapLimit=100
Nombre d'exécution minimal d'une branche de désoptimisation, par bytecode (cf. Table 3.3) et par méthode, avant que la méthode compilée ne soit invalidée ; son exécution bascule alors au niveau in-terpréteur.
Le paramètre -XX:+PrintCompilation permet de visualiser s'il y a invalidation.
-XX:-BlockLayoutByFrequency Désactive la réorganisation des blocs de base enfonction des fréquences prolées. Tab. 3.7: Paramètres principaux permettant de contrôler le proling et la désoptimisation
État de getBestTime État de compute
Interpréteur Interpréteur
Interpréteur C2-OSR
C2-OSR Inlinée
C2-OSR C2
Interpréteur C2
Tab. 3.8: États d'exécution possibles en mode non-étagé lors des mesures de performance lorsque le résultat est fourni par la première itération de getBestTime. L'état d'exécution dépend de la valeur des paramètres WU (cf. Figure 3.1) et IT (cf. Table 3.1) ainsi que de l'activation ou non de l'OSR. L'état en vert est celui garanti par l'implémentation et la conguration du micro-benchmark lors des mesures. Les états en rouge sont ceux pouvant fournir des mesures diérentes