Discussion :

[Mickael Baron]

Bonjour,

Antonio Gomes Rodrigues nous propose un tutoriel Java pour comprendre les dangers d'utiliser explicitement la méthode System.gc()

L'URL de l'article est : http://arodrigues.developpez.com/tut...ter-system-gc/

Profitez de cette discussion pour donner vos commentaires

Mickael

[kolodz]

Bonjour,

Il est dommage de ne pas avoir le détail sur l'instrumentation du bytecode.
De même, il semble que le problème, soit l'appel d'une fonctionnalité gourmande (pour le coup le gc) en ressource lors du traitement d'un formulaire. (Ce qui n'est jamais une bonne idée.) Plus que l'appel du gc en lui même !

Cordialement,
Patrick Kolodziejczyk.

[ra77]

Bonjour,

Il est dommage de ne pas avoir le détail sur l'instrumentation du bytecode.

Bonjour,
J'ai utilisé byteman pour afhicher un message et récupérer la stackstrace

De même, il semble que le problème, soit l'appel d'une fonctionnalité gourmande (pour le coup le gc) en ressource lors du traitement d'un formulaire. (Ce qui n'est jamais une bonne idée.) Plus que l'appel du gc en lui même !

Cordialement,
Patrick Kolodziejczyk.

Je ne comprend pas bien votre raisonnement

C'est l'appel du GC (avec system.gc()) qui pose problème comme on peut le voir en comparant les mesures avant/après.

Antonio

[kolodz]

Je ne comprend pas bien votre raisonnement

C'est l'appel du GC (avec system.gc()) qui pose problème comme on peut le voir en comparant les mesures avant/après.

Oui, la comparaison des mesures avant/après montre une mauvaise utilisation de system.gc(). Cependant, ce n'est pas une mauvaise utilisation spécifique à cette méthode.

En effet, dans la trace on constat bien qu'on se trouve directement dans un traitement d'une requête :

org.springframework.samples.petclinic.web.FindOwnersForm.processSubmit(FindOwnersForm.java:50)

Or, c'est une erreur courant de placer un traitement "consommateur de ressource" dans un traitement front-end et que cela pose des problèmes de ralentissement. Car, il est impossible de prédire le nombre d'appel à traiter. Que cela soit, dans ce cas, system.gc() n'est qu'anecdotique.
Personnellement, j'ai déjà à cette endroit l'appel à des traitements métiers type "batch" ou la mise à jour quasi-systématique d'un cache quelconque. Et au final le temps de réponse est celui de ce "gros traitement" qui n'a rien à faire là.

Certains, c'est une mauvaise utilisation du GC. Mais, pour moi, c'est surtout le nom respect d'un principe de base d'un développement d'IHM.

Cordialement,
Patrick Kolodziejczyk.

[Invité]

Bonjour,

Il me semble tout à fait logic que le GC ne doit pas être appelé dans une boucle, par exemple dans un endroit ou la performance est critique. On peux essayer de gérer la création de ses instances, les réutiliser si possible, faire des pools. Mais rien n'empêche l'utilisation de cette méthode bien que cela doit-être utilisé dans des cas très spécifique, les jeux vidéo après certaines opérations coûteuse en mémoire éventuellement, ou après un traitement important ayant généré beaucoup d'objets devenu obsolètes depuis.


Première mauvaise nouvelle, System.gc() ne réalise pas forcément un GC (il peut ne rien faire) et surtout on ne sait pas quand.

Comme décrit dans la doc java, cela n'est en aucun cas une méthode utilisé pour lancer une passe du GC. C'est juste un "hint" pour le système, afin de lui indiquer qu'on aimerais bien qu'il passe le GC, et c'est pour cela qu'il ce peux que cette appelle n'appelle pas le GC, justement. Vous auriez pu le préciser dans votre article.


"Nous avons vu dans cet article les méfaits de l'utilisation explicite de la méthode System.gc(). Mon conseil en guise de conclusion est de ne pas utiliser de System.gc()."

C'est donc aussi simple que ça. Parce que dans UN programme on détecte un bottleneck lié au GC, pour ne pas prendre de risque, on utilise plus jamais System.gc().

[ra77]

Bonjour,

Il me semble tout à fait logic que le GC ne doit pas être appelé dans une boucle, par exemple dans un endroit ou la performance est critique. On peux essayer de gérer la création de ses instances, les réutiliser si possible, faire des pools. Mais rien n'empêche l'utilisation de cette méthode bien que cela doit-être utilisé dans des cas très spécifique, les jeux vidéo après certaines opérations coûteuse en mémoire éventuellement, ou après un traitement important ayant généré beaucoup d'objets devenu obsolètes depuis.


Première mauvaise nouvelle, System.gc() ne réalise pas forcément un GC (il peut ne rien faire) et surtout on ne sait pas quand.

Comme décrit dans la doc java, cela n'est en aucun cas une méthode utilisé pour lancer une passe du GC. C'est juste un "hint" pour le système, afin de lui indiquer qu'on aimerais bien qu'il passe le GC, et c'est pour cela qu'il ce peux que cette appelle n'appelle pas le GC, justement. Vous auriez pu le préciser dans votre article.

Comme vous pouvez le voir, la Javadoc est juste au dessus et dit exactement ce que vous dites. Moi de mon coté j'ai résumé avec la phrase que vous cité pour éviter de répéter mot pout mot ce qu'il y a juste au dessus dans la Javadoc

"Nous avons vu dans cet article les méfaits de l'utilisation explicite de la méthode System.gc(). Mon conseil en guise de conclusion est de ne pas utiliser de System.gc()."

C'est donc aussi simple que ça. Parce que dans UN programme on détecte un bottleneck lié au GC, pour ne pas prendre de risque, on utilise plus jamais System.gc().

Petite précisions (valable aussi pour kolodz), le but de l'article est de montrer qu'il est dangereux (ce que j'ai déjà vu dans des outils en production) d'utiliser un System.gc() et qu'il vaut mieux laisser faire la JVM pour la libération de la mémoire (ce qui n’empêche pas de la tuner).

Pour cela j'ai utilisé une application démo appelé Spring PetClinic, puis j'ai crée un script JMeter pour réaliser de la charge. Puis j'ai modifié le code source pour ajouter System.gc() dans une des fonctions testé par notre script JMeter. Pour accentuer et bien montrer le problème, ce System.gc() est appelé dans une fonction souvent appelé.

Donc (pour kolodz) je suis d'accord avec vous mais le but de l'article est de montrer qu'il ne faut pas utiliser System.gc(). Ce qui est fait.

Pour romain1337, comme indiqué, le but de l'article est de ....Je me focalise sur un problème (que j'ai vue en prod et que donc certain développeurs pensent que cela est une bonne pratique et/ou n'a pas d'impact négatif) et je démontre avec des chiffres (je l'accorde que le test est la pour exagérer les résultats pour que le message soit percutant) ce que je préconise.

Pour info, JClarity Censum (outils d'analyse de log GC) fait par des spécialistes (dont Kirk Pepperdine) préconise la même chose

Antonio

[tchize_]

Bon déjà je vais le garder sous le coude pour mettre leur nez dans le caca aux petits nouveaux qui font des appels à System.gc(). Par contre, je serais curieux de voir le même genre de test, mais sur une méthode qui consomme 30 à 40% de la mémoire disponible dans la JVM en objets de petite taille. Pour savoir si il y a des cas où ça donnerais du positif