Par : Laurent M.
Article très intéressant, comme le premier. Il serait intéressant d’avoir un cas d’utilisation avec un outil d’analyse des logs et sur le tunning appliqué pour atteindre moins de 5% de full GC....
View ArticlePar : Fabian
+1 pour les 2 articles! J’ai appris plein de choses. En tant qu’utilisateur Java, il est toujours instructif de savoir ce qui se cache sous le capot et je pense que très peu de gens le savent!
View ArticlePar : tda
+1 également pour les 2 articles très instructifs ! Cependant, quelqu’un pourrait m’éclairer sur la notion d’ »overhead » ? « Ces garbage collectors offrent le meilleur ratio entre overhead et mémoire...
View ArticlePar : Pierre Laporte
L’overhead est le temps durant lequel le GC bloque l’application mais ne libère pas de mémoire. Lorsque CMS est utilisé, le GC dans la young generation (ParNew ou DefNew) doit informer CMS de la...
View ArticlePar : Clément H
Comme mentionné par les précédents intervenants, 2 articles fort instructifs et surtout d’une clarté exemplaire. Je ne manque pas d’en faire la promotion. J’attends avec impatience de vous lire de...
View ArticlePar : Jean-Philippe BEMPEL
La justification pour le ms=mx est surtout que, comme tu l’indiques, le resize se fait lors d’un FullGC. Donc si on suit le leitmotiv « on essaye d’obtenir le moins de Full GC possible » on ne va pas...
View ArticlePar : Pierre Laporte
Effectivement, le réglage ms!=mx va provoquer des Full GC pendant le temps de chauffe de la JVM, mais seulement jusqu’à atteindre le point d’équilibre, après quoi le sizing de la mémoire est stable....
View Article
