L'utilitaire OpenJDK Microbenchmark Suite (JEP 230), construit sur le Java Microbenchmark Harness (JMH) est une nouvelle fonctionnalité du JDK 12. L'objectif de la JEP 230 est de fournir des benchmarks stables et corrects. Elle comporte un ensemble initial d'environ 100 benchmarks, importés du projet jmh-jdk-microbenchmarks. Avec la JEP 230 il devient facile de créer de nouveaux benchmarks et de s'appuyer sur ceux qui existent déjà.
La construction de la suite de microbenchmark sera intégrée au système de construction du JDK. Cette construction sera une cible séparée qui ne sera pas exécutée lors des constructions normales du JDK qui ont lieu toutes les nuits, de façon à avoir des temps de construction courts pour les développeurs et les personnes qui ne sont pas intéressés par cet outil.
Le microbenchmark est l'art de mesurer la performance de petits morceaux de code Java. Implémenté de façon incorrecte, le microbenchmark peut produire des résultats non fiables et non représentatifs de la réalité. Il y a de nombreuses choses à prendre en compte lors de l'écriture de microbenchmarks. Dans le chapitre 5 Optimizing Java, les auteurs : Ben Evans, James Gough, et Chris Newland parlent des difficultés que l'on rencontre en écrivant des microbenchmarks.
On ne peut pas complètement séparer l'exécution du code Java de la compilation juste-à-temps, de la gestion de la mémoire et des autres sous-systèmes fournis par la machine Java. Non plus que l'on peut ignorer les effets du système d'exploitation, du matériel ou des conditions d'exécution (par exemple la charge de la machine) durant l'exécution des tests.
Brian Goetz, Java language architect chez Oracle, a déclaré, à propos de l'organisation d'un benchmark de mauvaise qualité :
La chose effrayante à propos des microbenchmarks est qu'ils produisent toujours un résultat, même si ce résultat n'a aucun sens. Ils mesurent toujours quelque chose, simplement nous ne sommes pas sûrs de ce qu'ils mesurent.
Très souvent, ils mesurent uniquement les performances du microbenchmark spécifiquement, et rien de plus. Mais il est très facile de se convaincre que votre benchmark mesure les performances d'un code spécifique, et d'en conclure, de façon fausse, la qualité des performances de ce code.
Aleksey Shipilëv, principal software engineer chez Red Hat, a répondu sur Twitter à une question sur les performances :
Un test de type nanobenchmark qui ne comporte pas une analyse du code assembleur généré n'est pas fiable. Point final.
Claes Redestad, principal member of technical staff chez Oracle, a parlé à InfoQ sur l'utilitaire de Microbenchmark.
InfoQ : Quelle a été l'inspiration pour créer cet utilitaire de Microbenchmark ?
Claes Redestad : l'utilitaire de Microbenchmark a fait partie du processus de développement de l'OpenJDK depuis de nombreuses années, et cet utilitaire est juste une étape dans la longue route de l'intégration de l'utilisation des microbenchmarks dans le processus de développement de l'OpenJDK.
La plupart, pour ne pas dire tous les microbenchmarks qui font partie de cette publication initiale sont présents depuis longtemps, et parmi les utilitaires que ces benchmarks utilisent se trouve JMH, présent depuis plusieurs années maintenant. La seule vraie nouveauté est son intégration dans le système de construction de l'OpenJDK et dans le repository principal de l'OpenJDK.
Au moment où cette JEP a été écrite, le projet OpenJDK était distribué dans plusieurs repositories, ce qui rendait pénible l'écriture de tests et de microbenchmarks. La proposition originale de cette JEP était d'ajouter un nouveau repository pour ces microbenchmarks. Mais cet effort a été arrêté, en partie du fait de désaccords sur le fait que cela en valait la peine.
Depuis cette époque, l'OpenJDK s'est organisé autour d'une structure en un unique repository, de nombreuses suites de tests ont été développées séparément, ont été consolidées dans le repository principal, etc... De nombreux obstacles auxquels se heurtait le projet il y a 5 ans ont simplement disparus.
Ce qui a finalement motivé l'avancement final de la JEP 230 a été le succès des autres efforts d'intégration des tests fonctionnels dans le repository principal de l'OpenJDK. Cela ne signifie pas que tous les benchmarks s'appuieront sur des micro-benchmarks co-localisés avec le code, comme le sont les suites de tests. Ca serait même le contraire. Mais avoir tout intégré et disponible dans un unique repository est vraiment pratique quand ce que vous devez tester est une nouvelle API qui n'est disponible que sur votre branche de travail.
InfoQ : Pourquoi la suite de microbenchmarks n'est-elle pas un utilitaire propre, comme java, javac, jdeps, jconsole, etc... ?
Claes Redestad : ce que fournit la JEP 230 est une façon de construire et d'exécuter des microbenchmarks, en tant que partie intégrante du développement de l'OpenJDK lui-même. Cette suite ne constitue pas naturellement un outil susceptible de devenir un livrable du JDK. Un peu de la même façon que les tests, qui ne sont pas fournis avec les distributions binaires du JDK.
InfoQ : Quelle est la meilleure façon pour les développeurs de se lancer dans l'utilisation de la Suite de Microbenchmarks, où peut-on trouver le code source, etc... ?
Claes Redestad : mon sentiment est que la plupart des développeurs Java veulent benchmarker leurs propres projets, plutôt que de contribuer à l'OpenJDK. Donc cette suite peut être une source d'inspiration pour eux. Je recommanderais de commencer par lire des choses sur JMH. JMH fournit quelques exemples, et c'est assez facile de créer un projet et de commencer à voir comment les choses fonctionnent. Aleksey Shipilëv a vraiment fait un bon travail en s'occupant de ce projet depuis plusieurs années, et il y a un bon corpus de ressources disponibles.
Si ce que vous souhaitez c'est construire, tester et peut-être même contribuer à l'OpenJDK lui-même, vous pouvez commencer ici : https://openjdk.java.net/. Prenez le code source ici http://hg.openjdk.java.net/jdk/jdk, et lisez la documentation sur les tests ici : http://hg.openjdk.java.net/jdk/jdk/raw-file/96d290a7e94f/doc/testing.html.
InfoQ : Qu'aimeriez-vous encore partager avec nos lecteurs sur la Suite de Microbenchmark ?
Claes Redestad : une façon de contribuer à l'OpenJDK est en fait de construire et exécuter ces microbenchmarks dans votre propre structure d'intégration continue et de nous faire part des régressions quand vous en constatez. Il y a de nombreuses configurations matérielles et systèmes, et nous n'exécutons probablement pas ces microbenchmarks à chaque modification sur toutes les configurations qui existent. Il y a donc des chances que vous puissiez détecter un problème que nous n'avons pas vu.
InfoQ : Que voyez-vous pour l'avenir de la Suite de Microbenchmark ?
Claes Redestad : pour le moment je suis à la recherche de retours d'expérience et j'encourage les développeurs de l'OpenJDK à la regarder, à l'utiliser et à l'améliorer. Je suis très heureux de voir que déjà de nouveaux microbenchmarks ont été ajoutés, et que de nouvelles contributions externes vraiment bonnes, sur de nouvelles fonctionnalités, telles que le support des librairies natives (https://bugs.openjdk.java.net/browse/JDK-8219393).
J'espère que nous allons améliorer les choses suffisamment pour que le fait d'exécuter des microbenchmarks quand on ajoute des fonctionnalités, devienne aussi naturel que d'ajouter des tests fonctionnels.
InfoQ : Quelles sont vos responsabilités actuellement, que faites-vous au quotidien ?
Claes Redestad : ma responsabilité principale est d'aider les nombreux développeurs de l'OpenJDK à faire progresser les performances dans la bonne direction. Contribuer à la JEP 230 en fait partie. Faire le tri dans les régressions détectées lors des constructions de nuit fait aussi partie de mon travail.
Au quotidien je tente de fournir des correctifs et des améliorations partout où je peux. J'ai pris beaucoup de plaisir ces dernières années à réduire le temps de démarrage et les surcharges en mémoire de l'OpenJDK. J'ai repris et amélioré l'exécution des lambdas en interne pour démarrer beaucoup plus vite qu'en JDK 8.
D'autres nouvelles fonctionnalités viennent en complément de la Suite de Microbenchmark en JDK 12, telles que Shenandoah, un nouveau ramasse-miettes expérimental (JEP 189), des expressions switch améliorées (JEP 325) et une nouvelle API de gestion de constantes pour la JVM (JEP 334).
Ressources
- JMH - Java Microbenchmark Harness - a tutorial by Jenkov.com
- JEP 230 - Microbenchmarks Suite by Claes Redestad (16 novembre 2018)