Bref si les gc ne sont pas aussi performants que la RAII et qu'ils ne s'appliquent qu'à la gestion de la mémoire
Deux problèmes (vécus) des GCs :
- la latence : l’exécution du GC freeze le programme, dans certains contextes ce n’est pas acceptable
- l’occupation mémoire et la cohabitation avec du code non garbage collecté. Certains GC ont une fâcheuse tendance à ne libérer la mémoire que quand il n’y en a plus, ce qui pose problème dans le cas d’un environnement hybride (typiquement, asp.net avec appel de code non managé) --> si le malloc qui échoue est dans le code managé, le GC se lance, s’il est dans le code non-managé, le GC ne se lance pas, et le code non managé n’aura jamais accès à la mémoire qui lui manque. Après, ce problème pourrait se résoudre par l’utilisation de process séparés, comme tu le préconises, mais cela a un coût. Dans un contexte serveur, le coût d’exécution, c’est de l’argent.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Un langage complexe ?
Posté par whity . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 1.
Deux problèmes (vécus) des GCs :
- la latence : l’exécution du GC freeze le programme, dans certains contextes ce n’est pas acceptable
- l’occupation mémoire et la cohabitation avec du code non garbage collecté. Certains GC ont une fâcheuse tendance à ne libérer la mémoire que quand il n’y en a plus, ce qui pose problème dans le cas d’un environnement hybride (typiquement, asp.net avec appel de code non managé) --> si le malloc qui échoue est dans le code managé, le GC se lance, s’il est dans le code non-managé, le GC ne se lance pas, et le code non managé n’aura jamais accès à la mémoire qui lui manque. Après, ce problème pourrait se résoudre par l’utilisation de process séparés, comme tu le préconises, mais cela a un coût. Dans un contexte serveur, le coût d’exécution, c’est de l’argent.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0