Pourquoi pas de comptage de référence + collecte des ordures en C#?

Question

Je viens d'un environnement C++ et je travaille avec C# depuis environ un an. Comme beaucoup d'autres, je suis perplexe quant au fait que la gestion déterministe des ressources ne soit pas intégrée au langage. Au lieu de destructeurs déterministes, nous avons le modèle de disposable. Les gens commencent à se demander s'il vaut la peine de propager le cancer IDisposable dans leur code.

Dans mon cerveau biaisé par le C++, il semble qu'utiliser des pointeurs intelligents avec comptage de références et destructeurs déterministes soit un grand pas en avant par rapport à un ramasse-miettes qui nécessite l'implémentation de IDisposable et l'appel de Dispose pour nettoyer vos ressources autres que la mémoire. Admettons, je ne suis pas très intelligent... donc je pose la question uniquement dans le but de mieux comprendre pourquoi les choses sont comme elles sont.

Et si C# était modifié de manière à ce que :

Les objets soient comptés par référence. Lorsque le nombre de références d'un objet atteint zéro, une méthode de nettoyage des ressources est appelée de manière déterministe sur l'objet, puis l'objet est marqué pour le ramasse-miettes. Le ramassage des ordures se produit à un moment non déterministe à l'avenir, moment où la mémoire est récupérée. Dans ce scénario, vous n'avez pas à implémenter IDisposable ou à vous souvenir d'appeler Dispose. Vous implémentez simplement la fonction de nettoyage des ressources si vous avez des ressources autres que la mémoire à libérer.

• Pourquoi est-ce une mauvaise idée?
• Cela ne contredirait-il pas le but du ramasse-miettes?
• Serait-il possible de mettre en œuvre une telle chose?

ÉDIT: D'après les commentaires jusqu'à présent, c'est une mauvaise idée car

1. Le ramasse-miettes est plus rapide sans comptage de références
2. Problème de gestion des cycles dans le graphe d'objets

Je pense que le premier point est valable, mais le deuxième est facile à résoudre en utilisant des références faibles.

Alors, est-ce que l'optimisation de la vitesse l'emporte sur les inconvénients que vous:

1. pourriez ne pas libérer une ressource non mémoire en temps opportun
2. pourriez libérer une ressource non mémoire trop tôt

Si votre mécanisme de nettoyage des ressources est déterministe et intégré au langage, vous pouvez éliminer ces possibilités.

Answer 1

Brad Abrams a publié un e-mail de Brian Harry écrit pendant le développement du framework .Net. Il détaille bon nombre des raisons pour lesquelles le comptage des références n'a pas été utilisé, même lorsque l'une des priorités initiales était de maintenir une équivalence sémantique avec VB6, qui utilise le comptage des références. Il examine des possibilités telles que le fait d'avoir certains types comptés par référence et d'autres non (IRefCounted!), ou de compter par référence des instances spécifiques, et pourquoi aucune de ces solutions n'a été jugée acceptable.

Parce que [la question de la gestion des ressources et de la finalisation déterministe] est un sujet si sensible, je vais essayer d'être aussi précis et complet que possible dans mon explication. Je m'excuse pour la longueur du mail. Les 90 % de ce mail tentent de vous convaincre que le problème est vraiment difficile. Dans la dernière partie, je parlerai des choses que nous essayons de faire, mais vous avez besoin de la première partie pour comprendre pourquoi nous examinons ces options.

...

Nous avons initialement pensé que la solution prendrait la forme d'un comptage automatique des références (afin que le programmeur ne puisse pas oublier), plus quelques autres éléments pour détecter et gérer automatiquement les cycles. ...nous avons finalement conclu que cela n'allait pas fonctionner dans le cas général.

...

En résumé :

• Nous estimons qu'il est très important de résoudre le problème des cycles sans obliger les programmeurs à comprendre, suivre et concevoir des solutions pour ces problèmes complexes de structure de données.
• Nous voulons nous assurer d'avoir un système haute performance (à la fois en vitesse et en taille de travail) et notre analyse montre que l'utilisation du comptage des références pour chaque objet du système ne nous permettra pas d'atteindre cet objectif.
• Pour diverses raisons, y compris des problèmes de composition et de conversion, il n'y a pas de solution transparente simple pour ne compter par référence que les objets qui en ont besoin.
• Nous avons choisi de ne pas opter pour une solution qui offre une finalisation déterministe pour un seul langage/contexte car cela entrave l'interopérabilité avec d'autres langues et provoque une scission des bibliothèques de classes en créant des versions spécifiques à chaque langage.

Answer 2

Le collecteur d'ordures ne nécessite pas que vous écriviez une méthode Dispose pour chaque classe/type que vous définissez. Vous en définissez une seule lorsque vous devez explicitement effectuer un nettoyage ; lorsque vous avez explicitement alloué des ressources natives. La plupart du temps, le GC ne fait que récupérer la mémoire même si vous ne faites que quelque chose comme new() sur un objet.

Le GC utilise le comptage de références - cependant il le fait d'une manière différente en trouvant quels objets sont 'atteignables' (Ref Count > 0) à chaque fois qu'il effectue une collection... il ne le fait simplement pas de manière compteur entier. Les objets inaccessibles sont collectés (Ref Count = 0). De cette façon, le moteur d'exécution n'a pas à faire de la maintenance/mise à jour des tables à chaque fois qu'un objet est attribué ou libéré... devrait être plus rapide.

La seule différence majeure entre C++ (déterministe) et C# (non-déterministe) est quand l'objet serait nettoyé. Vous ne pouvez pas prédire le moment exact où un objet serait collecté en C#.

Énième recommandation : Je vous recommande de lire le chapitre de Jeffrey Richter sur la GC dans CLR via C# au cas où vous seriez vraiment intéressé par le fonctionnement du GC.

Answer 3

Le comptage de références a été essayé en C#. Je crois que les personnes qui ont publié Rotor (une implémentation de référence de CLR pour laquelle le code source était disponible) ont utilisé un GC basé sur le comptage de références juste pour voir comment cela se comparerait à la version générique. Le résultat était surprenant - le GC "standard" était tellement plus rapide que ce n'était même pas drôle. Je ne me souviens pas exactement où j'ai entendu cela, je pense que c'était dans l'un des podcasts de Hanselminutes. Si vous voulez voir le C++ se faire littéralement écraser en termes de performances par rapport au C# - recherchez l'application de dictionnaire chinois de Raymond Chen. Il a créé une version en C++, puis Rico Mariani en a fait une en C#. Je crois qu'il a fallu à Raymond 6 itérations pour finalement battre la version C#, mais à ce moment-là, il a dû abandonner toute la belle orientation objet du C++, et se mettre au niveau de l'API win32. L'ensemble est devenu une astuce de performance. Le programme C#, quant à lui, n'a été optimisé qu'une seule fois, et à la fin ressemblait toujours à un projet OO décent

Answer 4

Il y a une différence entre le comptage de références du pointeur intelligent de style C++ et la collecte des déchets par comptage de références. J'en ai également parlé sur mon blog mais voici un résumé rapide :

Comptage de références de style C++ :

• Coût non borné à la diminution : si la racine d'une grande structure de données est diminuée à zéro, il y a un coût non borné pour libérer toutes les données.

• Collecte de cycle manuelle : pour empêcher les fuites de mémoire des structures de données cycliques, le programmeur doit manuellement rompre toutes les structures potentielles en remplaçant une partie du cycle par un pointeur intelligent faible. C'est une autre source de défauts potentiels.

Collecte de déchets par comptage de références

• RC différé : les modifications du compteur de références d'un objet sont ignorées pour les références de pile et de registre. Au lieu de cela, lorsque le GC est déclenché, ces objets sont conservés en collectant un ensemble racine. Les modifications du compteur de références peuvent être différées et traitées par lots. Cela entraîne un débit plus élevé.

• Fusion : en utilisant une barrière d'écriture, il est possible de fusionner les modifications du compteur de références. Cela permet d'ignorer la plupart des modifications du compteur de références d'objets, améliorant les performances de RC pour les références fréquemment mutées.

• Détection de cycle : pour une implémentation complète de GC, un détecteur de cycles doit également être utilisé. Cependant, il est possible d'effectuer une détection de cycle de manière incrémentielle, ce qui signifie à son tour un temps de GC borné.

En gros, il est possible de mettre en œuvre un collecteur de déchets basé sur un RC à hautes performances pour des environnements d'exécution tels que la JVM de Java et l'environnement d'exécution CLR de .net.

Je pense que les collecteurs par traçage sont en partie utilisés pour des raisons historiques : bon nombre des améliorations récentes du comptage de références sont survenues après la sortie de la JVM et de l'environnement d'exécution .net. Le travail de recherche prend également du temps pour passer aux projets de production.

Élimination des ressources de manière déterministe

C'est pratiquement une question à part. L'environnement d'exécution .net le rend possible en utilisant l'interface IDisposable, exemple ci-dessous. J'aime aussi la réponse de Gishu.

---

@Skrymsli, c'est le but du mot-clé "using". Par exemple :

public abstract class BaseCriticalResource : IDiposable {
    ~ BaseCriticalResource () {
        Dispose(false);
    }
    public void Dispose() {
        Dispose(true);
        GC.SuppressFinalize(this); // Pas besoin d'appeler le finaliseur maintenant
    }
    protected virtual void Dispose(bool disposing) { }
}

Ensuite, pour ajouter une classe avec une ressource critique :

public class ComFileCritical : BaseCriticalResource {
    private IntPtr nativeResource;
    protected override Dispose(bool disposing) {
        // libérer les ressources natives s'il y en a.
        if (nativeResource != IntPtr.Zero) {
            ComCallToFreeUnmangedPointer(nativeResource);
            nativeResource = IntPtr.Zero;
        }
    }
}

Ensuite, son utilisation est aussi simple que :

using (ComFileCritical fileResource = new ComFileCritical()) {
    // Quelques actions sur fileResource
}

// Les ressources critiques de fileResource sont libérées à ce moment-là

Voir aussi implémenter correctement IDisposable.

Answer 5

Je sais quelque chose sur la collecte des déchets. Voici un bref résumé car une explication complète dépasse le cadre de cette question.

.NET utilise un collecteur de déchets générationnel de copie et de compactage. Cela est plus avancé que le décompte de références et a l'avantage de pouvoir collecter des objets qui se réfèrent à eux-mêmes soit directement, soit à travers une chaîne.

Le décompte de références ne collectera pas les cycles. Le décompte de références a également un débit plus faible (plus lent globalement) mais avec l'avantage de pauses plus rapides (les pauses maximales sont plus petites) qu'un collecteur de traçage.