Plateforme .Net : le ramasse-miettes

Dans « The Annotated C++ Reference Manual », Margaret Ellis et Bjarne Stroustrup ont écrit :

Les programmeurs C pensent que la gestion de la mémoire est trop importante pour être laissée à un ordinateur. Les programmeurs LISP pensent que la gestion de la mémoire est trop importante pour être laissée aux utilisateurs.(1)

Quel que soit votre avis sur la question, il est indéniable de constater que dans un langage sans ramasse-miettes comme le C, la gestion de la mémoire par le programmeur est la source de deux problèmes majeurs :

• des fuites de mémoire, par oubli de la libérer une fois qu'elle n'est plus utile ;
• des accès non autorisés, par exemple en accédant à un pointeur déjà libéré.

Les accès non autorisés sont perfides : ils peuvent se manifester comme un bogue (dans le meilleur des cas) ou comme un trou de sécurité.

Et ces bogues sont d'autant plus difficiles à identifier que les conséquences, en plus d'être souvent aléatoires, sont difficilement reliables à leur cause originelle.

L'objectif d'un ramasse-miettes (Garbage Collector en anglais, ou GC) est de libérer le développeur(2) de la gestion de la mémoire. Une mémoire allouée ne sera automatiquement libérée que si elle n'est plus utilisée, ou autrement dit, pour le ramasse-miettes, si elle n'est plus référencée par le programme en cours d'exécution.

Tout de suite, on constate que les deux points problématiques de la gestion manuelle de la mémoire disparaissent :

• puisque la mémoire est automatiquement libérée dès lors qu'elle n'est plus utilisée, il n'y a plus de fuite ;
• puisque la mémoire n'est libérée que lorsqu'elle n'est plus utilisée, il n'est pas possible d'accéder à une mémoire qui aurait déjà été libérée.

C'est assez tôt que les premiers ramasse-miettes sont apparus. C'est John McCarthy, créateur du langage LISP, qui a, le premier, introduit cette notion.

Depuis, il y a eu beaucoup d'évolutions, et le ramasse-miettes a été adopté par d'autres langages, dont les plus connus sont sûrement le Java et le C#.

Les algorithmes sont aujourd'hui très performants. L'objectif de cet article est de vous présenter le fonctionnement du ramasse-miettes de la plateforme .Net.

Cet article décrit le fonctionnement du ramasse-miettes de la plateforme .Net, l'implémentation originelle de Microsoft. Il ne concerne pas les implémentations alternatives comme Mono ou .Net Core, même s'il y a de fortes chances que les principes restent les mêmes.

Plus de fuite de mémoire ne signifie pas que le besoin en mémoire d'une application ne puisse pas croître de manière déraisonnable. Mais dans ce cas, il s'agira d'une mauvaise gestion (trop d'allocation par exemple) et non un oubli de libération de mémoire.

I-B-1. Le tas versus la pile▲

I-B-2. Définition▲

I-B-3. Allocation▲

Lorsque le CLR a besoin d'allouer de la mémoire, par exemple, lorsqu'il rencontre l'opérateur new, il réserve l'espace nécessaire sur le tas. Pour cela, le CLR dispose d'un pointeur (NextObjPtr) qui indique l'espace où sera effectuée la prochaine allocation.

Au début du programme, ce pointeur est initialisé au début du tas. Et à chaque allocation, il est mis à jour et décalé.

Ainsi, l'algorithme d'allocation de mémoire est très simple et se déroule en temps constant, sans perdre de son efficacité au fil du temps.

I-B-4. Le ramasse-miettes▲

II-A-1. Anatomie d'une allocation mémoire▲

Pour bien comprendre la phase de marquage, revenons sur le fonctionnement d'une allocation mémoire. Lorsque le CLR rencontre l'opérateur new, voici ce qui se passe :

1. le CLR détermine le nombre d'octets x nécessaires pour l'objet à allouer ;
2. le CLR ajoute deux champs supplémentaires, de type pointeur, à l'objet :
   • un premier, appelé « sync block index », qui sera utilisé par le ramasse-miettes,
   • le second, « method table pointer », qui est une référence vers le type de l'objet ;
3. le nombre d'octets réservés x sera donc :
   • x + 8 (pour des architectures 32 bits),
   • x + 16 (pour des architectures 64 bits) ;
4. l'adresse de l'objet sera l'adresse contenue dans NextObjPtr ;
5. les x_res octets situés à l'adresse NextObjPtr sont initialisés à zéro ;
6. NextObjPtr est ensuite incrémenté du nombre d'octets réservés afin de pointer vers le prochain espace libre ;
7. le constructeur du type est ensuite appelé.

Première constatation, l'allocation d'une zone mémoire est très simple, puisqu'il s'agit simplement de décaler un pointeur et d'initialiser une zone mémoire à zéro.

Le deuxième constat est connu sous le nom de Fr principe de localité. Pratiquement, dans la majorité des applications, des objets alloués dans un même bloc de code ont tendance à être plus ou moins liés entre eux, et donc à être accédés conjointement. Cet algorithme, en allouant des zones contiguës, respecte ce principe.

Par exemple, il est fréquent d'instancier un FileStream en même temps qu'un TextWriter ou d'un BinaryWriter afin d'accéder à un fichier.

II-A-2. Phase de marquage▲

Maintenant que l'on sait distinguer quels sont les objets encore utilisés de ceux qui ne le sont plus, il reste à procéder à la récupération de l'espace alloué à ces objets.

Le principe derrière la libération de la mémoire est d'une étonnante simplicité : les objets encore utilisés sont déplacés en début de tas, afin de les « compacter ».

Ce compactage a deux effets bénéfiques :

• les objets encore utilisés seront contigus en mémoire, préservant ainsi le principe de localité précédemment abordé ;
• la mémoire libre est défragmentée.

Mais il y a malgré tout un inconvénient à procéder ainsi : les objets étant déplacés, il est nécessaire de mettre à jour toutes les références, afin que ces dernières pointent vers le nouvel emplacement en mémoire. Ainsi, à chaque référence d'un objet déplacé est soustrait le nombre d'octets duquel l'objet a été déplacé. Cette étape très importante et indispensable, se déroule elle-même en deux phases :

1. une première consistant en la mise à jour de toutes les références ;
2. une seconde consistant au déplacement des objets à proprement parler (compactage).

La dernière étape de cette phase est la mise à jour du pointeur NextObjPtr, pour qu'il pointe vers le premier octet de l'espace libre.

Le ramassage des miettes étant terminé, l'application peut reprendre son exécution.

Si le CLR n'est pas en mesure de libérer suffisamment de mémoire via une collecte, alors il alloue un nouveau segment de mémoire, augmentant ainsi la quantité de mémoire consommée par l'application.

Dans l'éventualité où l'allocation d'un nouveau segment ne serait pas possible, une exception OutOfMemoryException est générée.

Un patron de conception que l'on retrouve fréquemment pour les objets implémentant l'interface est, d'appeler, au niveau de l'implémentation de la méthode Dispose(), la méthode GC.SuppressFinalize.

public void Dispose()
{
    Dispose(true);
    GC.SuppressFinalize(this);
}

L'objectif de cette méthode est de préciser au ramasse-miettes de ne pas appeler le destructeur sur l'objet en question (il est donc retiré de la « finalization list »). Ainsi, lorsque l'objet est correctement libéré via l'appel à la méthode Dispose(), on libère toutes les ressources liées. Il devient donc inutile de maintenir l'appel au destructeur puisque les ressources auront déjà été libérées.

L'avantage de ce patron est qu'un objet correctement géré est donc libéré dès que possible, sans avoir à subir une double collecte ni être promu à la génération suivante.

L'inconvénient est que cela nécessite une connaissance approfondie du fonctionnement du ramasse-miettes et plus particulièrement de son implémentation.

public class Resource : IDisposable
{
    private AnotherResource managedResource = new AnotherResource();

    public void Dispose()
    {
        if (managedResource != null)
        {
            managedResource.Dispose();
            managedResource = null;
        }
    }
}

Ici, l'implémentation est très simple : on se contente de supprimer toutes références à des objets éventuellement maintenus.

Dans le cas où des objets proposent une méthode Dispose(), on appelle cette méthode afin de libérer correctement les ressources associées.

Dans le cas particulier où une classe ne gère que des ressources managées, il est totalement inutile d'avoir un destructeur. Le destructeur ne permet que de libérer des ressources natives directement possédées par l'objet en question.

public class Resource : IDisposable
{
    private IntPtr nativeResource = Marshal.AllocHGlobal(100);
    private AnotherResource managedResource = new AnotherResource();

    // Dispose() appelle Dispose(true)  
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    // NOTE: Supprimez le destructeur si cette classe ne 
    // possède aucune ressource native, mais laissez les 
    // autres méthodes telles quelles.
    ~Resource()
    {
        // Le destructeur appelle Dispose(false)  
        Dispose(false);
    }
    // La logique de nettoyage est implémentée dans cette méthode
    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // Libération des ressources managées
            if (managedResource != null)
            {
                managedResource.Dispose();
                managedResource = null;
            }
        }
        // Libération des ressources natives
        if (nativeResource != IntPtr.Zero)
        {
            Marshal.FreeHGlobal(nativeResource);
            nativeResource = IntPtr.Zero;
        }
    }
}

Comme nous pouvons le constater, l'implémentation(4) est légèrement plus compliquée. Regardons tout en détail afin d'en comprendre le fonctionnement.

Tout d'abord, l'appel à la méthode Dispose() ou au destructeur a le même objectif : la libération des ressources. C'est donc tout naturellement que ces deux méthodes en appellent une troisième, dédiée à la libération effective des ressources, dans le but d'éviter une duplication de code. Cette troisième méthode est généralement une surcharge de la méthode Dispose, mais acceptant un paramètre disposing de type booléen.

Comme la méthode Dispose() et le destructeur ont le même but, mais agissent de manière différente (la méthode Dispose doit libérer toutes les ressources, natives et managées, tandis que le destructeur ne doit libérer que les ressources natives), il est important que cette 3^e méthode puisse savoir le contexte de la libération des ressources. C'est le rôle du paramètre disposing :

• une valeur à true indique que la méthode Dispose() a été appelée (et donc qu'on libère également les ressources managées) ;
• une valeur à false indique que le destructeur a été appelé (et qu'on ne doit donc gérer que les ressources natives).

Ensuite, la surcharge de la méthode Dispose s'occupe de la libération des ressources. On voit bien ici qu'en fonction du paramètre, on libère ou non les ressources managées.

Dernier détail, la méthode Dispose() appelle la méthode GC.SupresseFinalize. L'objectif est de préciser au ramasse-miettes qu'il ne sera pas utile d'appeler le destructeur sur cet objet dans la mesure où les ressources ont déjà été libérées. On évite ainsi le besoin de procéder à une double collecte et à la promotion à la génération supérieure.

Le destructeur est véritablement un garde-fou dans le cas d'une mauvaise gestion des ressources, qui permet de libérer malgré tout les ressources lorsque ces dernières ne sont plus référencées au sein de notre programme.

On constate ici qu'une implémentation efficace de la méthode Dispose() nécessite une connaissance approfondie du ramasse-miettes et de son implémentation. Ce qui va à l'encontre de la nature même du ramasse-miettes dont l'usage est censé être le plus transparent et le moins intrusif possible.

Que se passe-t-il lors d'une collecte en cas de présence d'un objet épinglé ? La situation est résumée par le schéma de la figure 13.

Dans ce cas, les objets sont collectés, et les objets restants sont promus à la génération suivante. C'est ainsi que l'objet F passe en génération 1. La génération 0 commence après. On constate donc qu'il y a de l'espace libre, celui entre les objets B et F, qui n'est pas utilisé. Il en résulte une perte de mémoire disponible.

Soyez rassuré, cette perte n'est pas forcément permanente. Si l'objet n'est plus épinglé, ou s'il est candidat à une collecte, cet espace pourra être récupéré lors de la collecte.

Mais cela met donc en évidence un problème qui peut survenir s'il y a beaucoup d'objets épinglés : fragmentation de la mémoire libre, et inutilisable immédiatement.

Les deux facteurs accentuant ce mécanisme sont :

• le nombre d'objets épinglés (plus il y en a, plus la mémoire libre sera fragmentée) ;
• la durée pendant laquelle un objet est marqué comme épinglé (plus elle est longue, plus le ramasse-miettes à des chances de se déclencher et donc de fragmenter la mémoire libre).

En règle générale, on veillera donc à limiter le nombre d'objets épinglés, et la durée pendant laquelle ils le seront.

Heureusement pour nous, le ramasse-miettes dispose d'un mécanisme permettant de limiter ce problème de fragmentation. Le principe, connu sous le terme de « non-promotion »(5) (demotion en anglais) est illustré figure 14.

L'objet F, après la collecte, au lieu d'être promu à la génération 1 reste en génération 0. Cela permet de faire débuter la génération 0 juste après l'objet B au lieu de l'objet F comme dans le cas précédent. Ce mécanisme permet ainsi de récupérer une partie de l'espace libre situé entre les objets B et F : tant qu'il est possible d'utiliser cet espace pour allouer de nouveaux objets, il est utilisé.

L'œil averti remarquera que le principe de localité n'est pas respecté dans ce cas de figure. Tout d'abord, pour l'objet F. Mais le principe n'était déjà plus respecté au moment même où l'objet a été épinglé.

Ensuite, pour des objets qui seraient alloués avant et après F. Mais c'est une rupture mineure n'ayant qu'un impact très marginal en comparaison des avantages qui eux, sont tangibles.

Malgré le flou relatif à la gestion actuelle des objets épinglés par le ramasse-miettes, nous pouvons avoir la certitude d'un impact négatif quant aux performances du ramasse-miettes en présence de tels objets.

Il est donc recommandé d'éviter au maximum d'épingler les objets lorsque cela n'est pas nécessaire.

Lorsque le CLR ne dispose pas de la mémoire suffisante pour instancier un objet, il lance le ramasse-miettes afin de libérer l'espace qui n'est plus utilisé. Ce déclenchement est imprévisible et peut survenir à n'importe quel moment durant la vie d'une application.

Le programme rencontre un appel à GC.Collect.

Un appel sans argument force une collecte immédiate des objets.

Des surcharges avec arguments permettent de préciser les générations que l'on souhaite collecter, ainsi que le mode de collecte, c'est-à-dire est-ce que l'on force la collecte, ou est-ce qu'on indique un point de collecte, et c'est alors au ramasse-miettes de décider si oui ou non il procède effectivement à une collecte.

Dans le cas où le système d'exploitation reporte une mémoire disponible faible, le ramasse-miettes peut se déclencher afin de libérer de la mémoire sur le tas managé, afin de pouvoir redonner de la mémoire à Windows.

Lors du déchargement d'un domaine, le ramasse-miettes récupère toute la mémoire allouée à ce domaine. Tous les objets du domaine sont ainsi libérés, quelle que soit la génération à laquelle ils appartiennent.

Lors de la fermeture normale d'un programme, le CLR libère toute la mémoire allouée au processus. À noter qu'ici il s'agit d'un mode dégradé de la collecte. En effet, le programme se terminant, il n'y a plus aucun objet d'utilisé. Tous les objets peuvent donc être collectés, et il est inutile de procéder à un compactage.