La JVM de Java 7 est plus lente que celle de JRockit 6 ?

Question

J'étais très intéressé par la mise à niveau vers Java 7 (pour mes propres raisons égoïstes de codage). Cependant, certains de nos utilisateurs sont très sensibles à la latence (tout doit être inférieur à la milliseconde). J'ai effectué un simple test de comparaison des performances entre 3 JVM différentes et j'ai constaté que Java 7 était beaucoup plus lent. Le test a poussé quelques messages simples à travers notre application. Il s'agit d'un test à faible charge et volume de charge, qui fait passer un seul message toutes les quelques secondes. Les résultats sont les suivants (en microsecondes) :

 - Hotspot 6 (build 24): msgs= 23 avg= 902 
 - JRockit 6 (R28 b 29): msgs= 23 avg= 481 
 - Hotspot 7 (build 04): msgs= 34 avg=1130

La stratégie d'Oracle est de fusionner JRockit et Hotspot à partir de Java 7 (JRockit 6 est donc le dernier disponible). Quelqu'un a-t-il une idée de la raison pour laquelle les performances sont tellement moins bonnes ? (Il est à noter que le code a été compilé sous Java 1.6. Je ne sais pas si cela peut l'expliquer...)

MISE À JOUR : J'ai voté pour fermer ma propre question car je vois dans les commentaires que je ne suis pas vraiment en mesure de communiquer suffisamment d'informations pour en faire une question constructive. Merci à tous ceux qui ont commenté.

MISE À JOUR : Après avoir reçu plus de commentaires, j'ai pensé fournir plus d'informations. Le test est toujours après un nouveau départ. Tous les facteurs sont égaux pour chaque test. La seule chose qui change est la JVM . La répétition du test plusieurs fois donne un résultat cohérent. Aucun GC ne s'est produit dans aucune itération du test.

Le graphique ci-dessous présente les valeurs de l'un des tests effectués. Pour JRockit et Hotspot 7, la toute première valeur de latence a été rejetée. La première valeur de JRockit est énorme, mais elle s'optimise ensuite très rapidement et se stabilise vers la moyenne. Hotspot 7 prend plus de temps pour optimiser, et ne descend jamais vers une moyenne aussi basse que JRockit. Chaque point de données représente des microsecondes pour lire un message à partir d'un socket TCP/IP, exécuter la logique commerciale et écrire le message sur un autre socket. Chaque message est identique, et aucun nouveau chemin de code n'est entré pour aucun message.

Answer 1

JRockit est sa propre base de code (pur C) différente de celle d'OpenJDK. Il contient des collecteurs de déchets différents et un compilateur JIT totalement différent. L'un des grands avantages monétaires, lorsqu'il appartenait à BEA, était le GC à faible latence, qui est assez avancé, même dans les variantes non commerciales. Une quantité importante de temps a été consacrée à JRockit en tant qu'implémentation de vm en salle blanche. Comme cela a été dit dans les commentaires, il ne s'agit pas tant de fusionner que de réimplémenter des choses dans la base de code HotSpot. C'est loin d'être un processus rapide et certaines choses n'y arriveront pas du tout, du moins pas dans leur forme JRockit. Les pièces d'un puzzle ne s'emboîtent pas facilement sans un certain limage des bords, pour ainsi dire. JDK7 Hotspot, sera bon pour d'autres choses, ou pour des versions différentes de systèmes similaires, mais cela pourrait compenser une partie de votre perte de performance. D'autres applications pourraient bien fonctionner plus rapidement qu'avec JRockit 6.

Si vous souhaitez en savoir plus sur les composants internes de JRockit (ou de toute autre JVM), le livre "Oracle JRockit the definitive guide" est une lecture hautement recommandée. Pour être tout à fait honnête, je recevrai probablement ~2$ avant taxes en redevance pour chaque copie et je l'utiliserai pour acheter de l'espresso :)

Answer 2

L'idée principale de cette question était, toutes choses étant égales par ailleurs (y compris les args de la JVM) pourquoi le même JAR de code Java s'exécute-t-il beaucoup plus lentement avec la JVM de Hotspot 7 qu'avec JRockit 6 et Hotspot 6.

Cela a donné lieu à quelques réponses préoccupées par la question de savoir si le chronométrage a été effectué correctement (apparemment en raison du scepticisme des gens quant à l'existence d'un système d'enregistrement des données). vraiment ont un résultat si différent entre les JVM). Sur la base de nombreux tests, il ne fait aucun doute dans mon esprit que les mesures sont correctes.

Les réponses potentielles que je pensais possibles étaient :

• La JVM de Java 7 n'exécute pas le code compilé sous Java 6 aussi rapidement que le même code compilé sous Java 7.
• de nouveaux args JVM sont nécessaires pour que Java 7 fonctionne dans le mode le plus optimisé possible
• D'autres personnes ont comparé Java 7 à JRockit 6 et ont obtenu le même résultat que moi.

Le fait est que le comportement de la nouvelle JVM de Java 7 est très différent de celui de notre application, toutes choses étant égales par ailleurs . La seule solution est de profiler le code par rapport à la VM Java 7, afin de découvrir où se trouvent les points faibles du code. (Et peut-être qu'à ce moment-là, la différence réelle entre la JVM de Java 6 et la JVM de Java 7 sera claire).

J'apprécie les commentaires de chacun et je m'excuse de ne pas avoir pu fournir suffisamment de détails pour une analyse/résolution claire.