Comment CPython gère-t-il la mémoire ?

CPython utilise le comptage de références comme mécanisme principal : chaque objet suit le nombre de références qui pointent sur lui, et il est libéré immédiatement quand ce compteur tombe à zéro. Un ramasse-miettes générationnel s'ajoute par-dessus pour attraper les cycles de références que le comptage seul ne peut pas libérer. La mémoire libérée par les petits objets retourne en général dans les pools internes de l'allocateur plutôt qu'au système d'exploitation.

Le comptage de références fait le gros du travail. Chaque objet porte un compteur, lier un nom l'incrémente, lâcher un nom le décrémente, et à zéro l'objet est détruit sur-le-champ. Ce déterminisme explique qu'un fichier se ferme dès que la dernière référence disparaît dans CPython, même si je ne m'appuierais pas dessus dans du code censé tourner sur d'autres implémentations. Le comptage ne peut pas libérer les cycles, donc un parent qui tient un enfant qui retient le parent n'atteint jamais zéro. C'est ce dont s'occupe le ramasse-miettes générationnel, avec trois générations, les objets jeunes examinés le plus souvent et les survivants promus. Sur un worker de longue durée que j'ai débogué, la mémoire montait régulièrement et il s'est avéré que c'était un cache qui tenait des objets avec des références arrière, plus une traceback d'exception gardée dans une variable de module, ce qui épinglait des frames entières. Des instantanés tracemalloc pris à dix minutes d'intervalle ont pointé droit dessus. Il vaut la peine d'ajouter que libérer des objets ne rend souvent pas les pages au système d'exploitation, donc une RSS haute et plate après un pic est normale et non une fuite.