Tout ça correspond aux différentes passes d'optimisation de la JVM : on passe graduellement d'une méthode utilisée une fois donc entièrement interprétée, à une méthode identifiée comme critique pour le fonctionnement de l'application donc compilée et optimisée à fond par la JVM.
Et maintenant tu vas passer aux choses sérieuses et faire une vraie analyse ou des vrais tests ? ;-)
Si tu veux essayer de comprendre un peu ce qu'il se passe en vrai JITWatch est un excellent outil.
tl;dr:
Tu récupères linux-hsdis-amd64.so quelque part. Historiquement via le projet Kenai mais le site est down maintenant. Si tu le trouves pas, tu te frappes une compilation d'OpenJDK en debug. Tu le places dans $JDK/jre/lib/amd64/server/hsdis-amd64.so. hsdis te permet de sortir sortir le code assembleur généré par HotSpot
Tu tournes ton appli -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly -XX:-UseCompressedOops -XX:LogFile=mylogfile.log
Tu lances JitWatch
Ça te permettra de comprendre les différentes phases de compilation d'une même méthode, explorer la compile chain (ie. ce qui a été compilé, pas compilé, inliné, appels virtuels etc.), voir l'assembleur généré à chaque étape, voir les intrinsics utilisés etc.
En général le combo JITWatch / JMH bien utilisé te permettent de comprendre beaucoup de choses. Côté JMH, souvent la clé pour se genre de truc c'est de jouer avec les options de la JVM pour prendre différentes mesures. Ici tu pourrais tester un -Xint pour empêcher toute compilation, puis -XX:TieredStopAtLevel=X si tu penses que ce tu observes est lié aux 5 niveaux de compilation d'HotSpot. Les logs de compilations sont aussi super utiles, de même que la sortie assembleur.
Avec ces deux outils tu peux mettre en place un joli cycle d'itérations ou tu appliques bêtement la méthode scientifique. Attention un bench sert à valider un modèle de performance et pas à le découvrir. Voilà, tu viens de découvrir comment occuper tes 5 prochaines années ! Si j'ai 5 minutes a tuer je regarderais ton test.
Note: Je ne rentre pas sur le terrain de la pertinence de ton test, savoir expliquer ce que l'on observe est déjà bien rigolo :-)
# Et maintenant ?
Posté par ckyl . En réponse au journal Optimisation, microbenchmark et compilation Just In Time : quand 1 + 1 ne font pas 2. Évalué à -1.
Et maintenant tu vas passer aux choses sérieuses et faire une vraie analyse ou des vrais tests ? ;-)
Si tu veux essayer de comprendre un peu ce qu'il se passe en vrai JITWatch est un excellent outil.
tl;dr:
linux-hsdis-amd64.soquelque part. Historiquement via le projet Kenai mais le site est down maintenant. Si tu le trouves pas, tu te frappes une compilation d'OpenJDK en debug. Tu le places dans$JDK/jre/lib/amd64/server/hsdis-amd64.so. hsdis te permet de sortir sortir le code assembleur généré par HotSpot-XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly -XX:-UseCompressedOops -XX:LogFile=mylogfile.logÇa te permettra de comprendre les différentes phases de compilation d'une même méthode, explorer la compile chain (ie. ce qui a été compilé, pas compilé, inliné, appels virtuels etc.), voir l'assembleur généré à chaque étape, voir les intrinsics utilisés etc.
En général le combo JITWatch / JMH bien utilisé te permettent de comprendre beaucoup de choses. Côté JMH, souvent la clé pour se genre de truc c'est de jouer avec les options de la JVM pour prendre différentes mesures. Ici tu pourrais tester un
-Xintpour empêcher toute compilation, puis-XX:TieredStopAtLevel=Xsi tu penses que ce tu observes est lié aux 5 niveaux de compilation d'HotSpot. Les logs de compilations sont aussi super utiles, de même que la sortie assembleur.Avec ces deux outils tu peux mettre en place un joli cycle d'itérations ou tu appliques bêtement la méthode scientifique. Attention un bench sert à valider un modèle de performance et pas à le découvrir. Voilà, tu viens de découvrir comment occuper tes 5 prochaines années ! Si j'ai 5 minutes a tuer je regarderais ton test.
Note: Je ne rentre pas sur le terrain de la pertinence de ton test, savoir expliquer ce que l'on observe est déjà bien rigolo :-)