New Relic a publié un nouveau rapport sur les JVM basé sur une analyse des données rapportées par les JVM des clients en cours d'exécution en production à travers le monde. Contrairement aux autres sondages autodéclarés, les données produites ici proviennent de JVM utilisées en production. Comme on pouvait s'y attendre, l'ensemble de données provient de clients de New Relic, mais il brosse un tableau de ce qui est utilisé en production par opposition à ce que les développeurs utilisent et testent.
En particulier, le rapport souligne que la majorité des JVM en cours d'utilisation en production sont des versions LTS de Java; et seule une fraction de plus de 11% s'exécute sur Java 11. La majorité des JVM (plus de 85%) s'exécutent sur Java 8, avec Java 7 qui suit avec quelques pour cent. Les versions non LTS sont utilisées dans un peu plus de 1% des machines exécutées. De plus, le rapport souligne que les utilisateurs de JVM sont souvent lents à faire des mises à jour en production; il y a plus de versions de Java fonctionnant avant 7 que sur 9 ou 10 (qui sont toutes les deux EOL) ou 12 et 13 (qui sont toutes les deux EOL ou sur le point de devenir EOL). Le rapport souligne également qu'un certain nombre de JVM s'exécutent sur des versions obsolètes de Java 8, dont certaines sont connues pour présenter des failles de sécurité.
L'autre aspect intéressant des données est qu'elles montrent qu'Oracle, tout en restant le principal fournisseur de JVM avec un peu moins de 75%, a vu un certain nombre d'autres fournisseurs se mobiliser pour fournir des runtimes. Adopt OpenJDK est le second fournisseur le plus utilisé avec 7%, suivi par Iced Tea avec un peu plus de 5% (utilisé par les distributions GNU), et Azul, IBM et Amazon prenant chacun un peu moins de 3%, suivi par une liste d'autres fournisseurs.
Le rapport souligne également l'utilisation des ramasse-miettes utilisés en production; Parallel reste le ramasse-miettes de choix dans plus de 57% des JVM, G1 occupant un peu moins de 25% des configurations et CMS un peu plus de 17%. Ces différences peuvent en partie s'expliquer par les versions de la JVM, car le collecteur G1 est devenu par défaut dans Java 9, mais sa maturité a augmenté depuis sa sortie. Bien qu'un résultat se dégage - CMS est utilisé dans un peu plus de 14% des JVM sur Java 8, avec G1 13% - pouvoir voir comment les changements ont évolué au fil des versions Java aurait été une statistique intéressante. Sans surprise, aucune utilisation sérieuse en production de Shenandoah ou ZGC n'a été observée dans les résultats, avec seulement une fraction d'un pour cent constatée avec l'une ou l'autre configuration.
Enfin, les configurations de mémoire des JVM affichent une variété de tailles de mémoire, allant de 256 Mo à 16384 Mo - bien que, curieusement, environ 2,5% des JVM utilisent une taille maximale de 819 Mo, ce qui est probablement une erreur de copier-coller de 8192 Mo, comme vu ici par exemple. Plus d'un tiers des JVM s ont rapportés être exécutées avec les mêmes indicateurs -Xmx et -Xms ; la suggestion est que, même si cela était nécessaire pour les anciennes JVM, les heuristiques plus récentes du ramasse-miettes peuvent mieux fonctionner lorsque les tailles initiale et maximale sont différentes.
InfoQ a demandé s'il était possible d'obtenir une copie anonyme des données pour une analyse plus approfondie, et mettra à jour cet article si elle est publiée.