Non c'est vrai (même si c'est pas aussi noir qu'il le dit)
Ce que tu décris c'est un code qui fait de la fuite mémoire écris par des développeurs qui s'imaginent que le gc supprime les fuites mémoire ce qui est faux. Un gc récent ne pause pas ce genre de problème.
Si. Sauf si tu as la chance de jouer avec Azul C4 (malheureusement on a toujours réussi à trouver des workaround avec CMS/G1 avant que quelqu'un veuille signer le chèque) tu finis par avoir des pauses conséquentes dès que ta heap grossie. En dessous de 4/6GB tu n'as aucun soucis. Au dessus les temps de pause peuvent rapidement devenir un problème en fonction de la latence maxi que tu veux obtenir.
Par exemple en Java, tu sais qu'après un full-gc tu repars d'une mémoire propre
Sauf qu'avant d'arriver à un full GC tes perfs peuvent se dégrader lentement et surement.
Pour te donner un exemple précis, on a eu le cas en prod sur un cluster Cassandra avec un CMS et >8GB de heap. Pas de full GC avant 2/3 jours par contre le stop-the-world des minors collections montaient lentement jusqu'à 3/5 secondes avant de qu'un full GC ne passe. Domage quand tu dois garantir des temps de réponse en dessous de 50ms...
mais en réalité c'est un problème de fuite mémoire, pas de garbage collector.
En vrai c'est un peu plus compliqué que ca.
Avec des heap non ridicules, c'est un mélange de bien comprendre comment fonctionne les différentes implémentations de GC (et je peux te garantir que très très peu de monde sait comment ca marche vraiment), le hardware, et de désigner son application pour être GC friendly en fonction de ses besoins précis. Entre une latence <1ms en HFT, un stock exchange qui prend en plus quelques millions d'ordres secondes, ou un gros batch data il y a un monde, mais tous demandent de savoir ce que l'on fait. Ca peut vouloir dire faire du garbage free dans certaines portitions, de faire du off-the-heap avec allocation/libération manuelle, utiliser des fly-weight, de réutiliser des zones mémoires préallouées avec des structures type ring buffer etc.
Bref le GC marche bien pour la plupart des besoins simples, par contre il faut savoir quand on va tapper ses limites et désigner en conséquence (et c'est un truc qu'on essai de faire assez tôt sinon tu pleures pendant longtemps). En Java les solutions sont assez crado mais ca se fait.
Maintenant les perfs ne se limitent clairement pas au GC et au layout mémoire. Par exemple tu vas avoir l'absence actuelle de SIMD qui peut faire très mal selon ce que tu fais. Tu vas aussi voir que pas mal d'API du JDK sont clairement pas orientées performances mais sont gardées par compat.
Bref comme souvent il y a un compromis à faire. Il n'y a pas de techno géniale ou tout est gratuit.
BTW: RedHat bosse actuellement sur un nouveau GC type C4 pour hotspot. A voir si il sorte un truc moins bouseux que G1.
[^] # Re: la réponse est évidente
Posté par ckyl . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 4.
Non c'est vrai (même si c'est pas aussi noir qu'il le dit)
Si. Sauf si tu as la chance de jouer avec Azul C4 (malheureusement on a toujours réussi à trouver des workaround avec CMS/G1 avant que quelqu'un veuille signer le chèque) tu finis par avoir des pauses conséquentes dès que ta heap grossie. En dessous de 4/6GB tu n'as aucun soucis. Au dessus les temps de pause peuvent rapidement devenir un problème en fonction de la latence maxi que tu veux obtenir.
Sauf qu'avant d'arriver à un full GC tes perfs peuvent se dégrader lentement et surement.
Pour te donner un exemple précis, on a eu le cas en prod sur un cluster Cassandra avec un CMS et >8GB de heap. Pas de full GC avant 2/3 jours par contre le stop-the-world des minors collections montaient lentement jusqu'à 3/5 secondes avant de qu'un full GC ne passe. Domage quand tu dois garantir des temps de réponse en dessous de 50ms...
En vrai c'est un peu plus compliqué que ca.
Avec des heap non ridicules, c'est un mélange de bien comprendre comment fonctionne les différentes implémentations de GC (et je peux te garantir que très très peu de monde sait comment ca marche vraiment), le hardware, et de désigner son application pour être GC friendly en fonction de ses besoins précis. Entre une latence <1ms en HFT, un stock exchange qui prend en plus quelques millions d'ordres secondes, ou un gros batch data il y a un monde, mais tous demandent de savoir ce que l'on fait. Ca peut vouloir dire faire du garbage free dans certaines portitions, de faire du off-the-heap avec allocation/libération manuelle, utiliser des fly-weight, de réutiliser des zones mémoires préallouées avec des structures type ring buffer etc.
Bref le GC marche bien pour la plupart des besoins simples, par contre il faut savoir quand on va tapper ses limites et désigner en conséquence (et c'est un truc qu'on essai de faire assez tôt sinon tu pleures pendant longtemps). En Java les solutions sont assez crado mais ca se fait.
Maintenant les perfs ne se limitent clairement pas au GC et au layout mémoire. Par exemple tu vas avoir l'absence actuelle de SIMD qui peut faire très mal selon ce que tu fais. Tu vas aussi voir que pas mal d'API du JDK sont clairement pas orientées performances mais sont gardées par compat.
Bref comme souvent il y a un compromis à faire. Il n'y a pas de techno géniale ou tout est gratuit.
BTW: RedHat bosse actuellement sur un nouveau GC type C4 pour hotspot. A voir si il sorte un truc moins bouseux que G1.