Lors de la deuxième journée de JCrete 2013, Kirk Pepperdine nous a proposé une session dédiée aux mensonges de nos profilers.
Cette session était motivée par la présence d’experts en performances et aussi pour tordre le cou à certaines idées reçues encore appliquées. Ces dernières sont appelées "Tuning by folklore" et consistent en l’application d’astuces dont la seule justification est "j’ai lu quelque part que c’était bien".
Pour avoir des résultats corrects, il faut au moins avoir une plateforme similaire à la production, le bon profiler et les bons réglages de ce dernier. Et encore, cela ne suffit pas toujours car nos profilers sont des éternels insatisfaits. Ils trouveront toujours quelques problèmes à signaler en rouge dans une belle interface.
Comment pouvons-nous nous assurer que ces points sont réellement importants ?
Kirk explique avoir utilisé cinq profilers différents sur une application à problèmes. Sur les cinq, seuls deux ont trouvé le problème majeur, les trois autres ont relevé d’autres points moins importants.
Il faut être extrêmement critique vis-à-vis des résultats fournis par nos outils. La meilleure approche consiste d’ailleurs à savoir ce que l’on recherche avant de démarrer un profiler. Pour cela, il faut observer le comportement du système pour savoir quel outil utiliser. Par exemple, si le principal problème semble venir de la mémoire, il est inutile de démarrer un lock profiler, même si l’application souffre (dans une moindre mesure) de problèmes de locks.
La discussion s’oriente ensuite vers les safepoints, qui sont le mécanisme utilisé par Hotspot pour tout un tas d’opération (passage du GC, stratégies de locking, optimisation et désoptimisation du code, …). Martin Thompson explique que le code est parsemé de safepoints par le compilateur de sorte que chaque thread demande régulièrement à la JVM s’il doit s’interrompre.
Problème : personne ne sait réellement à quels endroits ces safepoints sont introduits. Il est d’ailleurs possible d’écrire une boucle infinie qui n’a pas de safepoints. Dans ce cas de figure, le thread qui exécute la boucle ne s’interrompra jamais, le GC ne passera donc jamais et cela pourra amener un freeze complet de la JVM.
Autre problème : les profilers qui utilisent le sampling sont également basés sur ces safepoints. Il est donc tout à fait possible de manquer les événements majeurs du système car tous les threads ne sont pas encore interrompus au moment où il se déclenche.
Enfin, les profilers génèrent des objets temporaires dans nos applications pour pouvoir fonctionner et créent donc artificiellement du travail pour le GC. Leur seule présence peut donc causer (et bien sûr indiquer) un problème mémoire.
Pour finir cette discussion de très haut niveau, nous avons été amenés à réfléchir sur la pertinence de l’hypothèse générationnelle faible (Weak Generational Hypothesis). Cette hypothèse pose les bases des algorithmes de GC actuels et dit que la plupart des objets meurent jeunes. Avec l’arrivée des caches de plus en plus volumineux, cette hypothèse est de moins en moins valide. Il faudra donc à terme revoir ces algorithmes pour s’y adapter.