Quelle est la différence entre la collecte des ordures dans les langues pures?

Dans un langage pur comme Haskell, toutes les données sont immuables et aucune structure de données existante ne peut être modifiée de quelque façon que ce soit. De plus, de nombreux algorithmes sur les données immuables et les modèles de programmation fonctionnelle génèrent de grandes quantités de déchets par nature (chaînes de mapcréation de listes intermédiaires par exemple).

Quelles stratégies et techniques les ramasseurs d'ordures utilisent-ils face à la pureté qu'ils n'auraient pas autrement? Qu'est-ce qui fonctionne très bien dans le GC d'un langage impur qui ne fonctionne pas dans un contexte pur? Quels autres nouveaux problèmes les langages purs créent-ils pour les GC?

L'implémentation actuelle de ghc utilise une stratégie qui ne fonctionne que parce que le langage est purement fonctionnel et que les données sont immuables: car aucune variable ne peut jamais être modifiée pour faire référence à quelque chose de plus récent, les objets ne contiennent que des références à des objets plus anciens, donc il exécute un ramasse-miettes générationnel ; puisqu'un objet référencé par une génération supérieure ne peut pas être supprimé tant que cette génération n'est pas GCd, il promeut les objets auprès des générations supérieures avec impatience; et puisque rien ne va altérer les références pendant que le GC les balaye, il peut fonctionner en parallèle.

Voici un document plus détaillé .

Dans un langage pur comme Haskell, toutes les données sont immuables et aucune structure de données existante ne peut être modifiée de quelque façon que ce soit

En fait, ce n'est généralement pas vrai. Les langages purs utilisent une évaluation non stricte (paresseuse), de sorte que l'évaluation de potentiellement toutes les sous-expressions est différée. Les expressions non évaluées sont généralement attribuées en tas en tant que "thunk". Si nécessaire, l'expression est évaluée et le thunk est muté en la valeur résultante.

Quelles stratégies et techniques les ramasseurs d'ordures utilisent-ils face à la pureté qu'ils n'auraient pas autrement?

La seule chose à laquelle je peux penser, ce sont les trous noirs . Je ne me souviens pas avoir vu autre chose de nouveau du côté du GC dans les documents de recherche de Haskell.

Qu'est-ce qui fonctionne très bien dans le GC d'un langage impur qui ne fonctionne pas dans un contexte pur?

La barrière d'écriture GC. Les langages impurs ont tendance à écrire beaucoup plus de pointeurs dans le tas, de sorte qu'ils ont tendance à voir leurs barrières en écriture plus fortement optimisées.

D'autres algorithmes GC tels que mark-region sont beaucoup plus viables dans le contexte des langages impurs car ils peuvent avoir des taux d'allocation beaucoup plus bas que les langages purs.

Quels autres nouveaux problèmes les langages purs créent-ils pour les GC?

Les langages purs sont très rares, donc il y a beaucoup moins de données sur la façon dont les programmes purs utilisent la mémoire et, par conséquent, vous commencez dans une position pire lorsque vous essayez d'écrire un GC pour un langage pur.