Dans d'autres langues que vous avez un certain nombre de possibilités habituellement pour la récupération de la mémoire:Quel type d'algorithme de récupération de mémoire MRI Ruby 1.8 utilise-t-il?
Comment fonctionne Ruby?
Le collecteur d'ordures Ruby 1.8 est vraiment horrible. Chaque 7 Mo d'allocation, il effectuera une phase de marque de tous les objets racine et tentera de trouver ce qui peut être atteint. Ceux qui ne peuvent être atteints seront libérés. Toutefois, pour savoir quels objets sont accessibles, il vérifie la pile, les registres et la mémoire d'objets allouée. Cela permet des faux positifs mais facilite l'écriture des extensions C: les extensions C n'ont pas besoin de référence et de déférence, puisque la pile et ainsi de suite les extensions C utilisées sont automatiquement analysées.
En outre, l'état de l'objet (référencé ou non) est conservé dans l'état de chaque objet. Ceci est assez mauvais pour le comportement de cache et le comportement de copie sur écriture: beaucoup de lignes de cache sont touchées pendant ce processus, et les interpréteurs ruby ne partagent pas autant de mémoire qu'ils le pourraient si vous en avez plus d'un (utile pour le serveur déploiement comme Ruby on Rails). Par conséquent, d'autres implémentations existent (Ruby Enterprise Edition) qui le font dans une partie séparée de la mémoire pour accélérer le GC.
Les longues listes chaînées constituent également un problème. Puisque mark-and-sweep utilise la pile pour faire la récursion, une longue liste de liens segfaults ruby.
Le GC ne fait pas non plus de compactage et cela devient problématique à long terme.
Cependant, si vous exécutez JRuby, ces problèmes disparaîtront tout en conservant la compatibilité avec Ruby 1.8.
Ruby's GC uses themark-and-sweep strategy.
"marque conservatrice et balayage"
Voir this thread qui comprend la description « Matz, qui devrait être définitive.
pouvez-vous donner des détails sur le GC's 1.9? – rampion
GC de YARV (Ruby 1.9) ne diffère pas beaucoup de 1.8. Je n'ai trouvé aucune différence. –