C'est exactement ça le problème. La mémoire se remplis de tout ce qui ne peut pas être libéré on-the-fly et à un moment, après une utilisation suffisamment longue, il y a un mark-and-sweep total qui a tendance à bloquer le truc en entier.
En fait les GC Java sont un poil plus malin qu'un bête mark & sweep stop the world et c'est assez intéressant de regarder comment CMS/G1/C4 fonctionnent exactement en pratique car ce sont les meilleurs GC actuels à ma connaissance. Très loin devant ceux des autres langages/runtimes. Je peux te filer des pointeurs si ca t'intéresse.
Dans le fond je serais moins "extremiste que toi". Un GC est pratique et fait le job dans 90% des cas. Maintenant il faut savoir le dégager quand y'a besoin et la dessus la sémantique de Java est mauvaise puisqu'il faut bidouiller alors que ca pourrait être plus clean. Après des produits mal branlés restent des produits mal branlés.
[^] # 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é à 6.
En fait les GC Java sont un poil plus malin qu'un bête mark & sweep stop the world et c'est assez intéressant de regarder comment CMS/G1/C4 fonctionnent exactement en pratique car ce sont les meilleurs GC actuels à ma connaissance. Très loin devant ceux des autres langages/runtimes. Je peux te filer des pointeurs si ca t'intéresse.
Dans le fond je serais moins "extremiste que toi". Un GC est pratique et fait le job dans 90% des cas. Maintenant il faut savoir le dégager quand y'a besoin et la dessus la sémantique de Java est mauvaise puisqu'il faut bidouiller alors que ca pourrait être plus clean. Après des produits mal branlés restent des produits mal branlés.