Discussion :

[agparchitecture]

Bonsoir à tous,

Est-il possible de savoir ce qui a détruit/finalise un object?

En gros si dans un code tres long existe-t-il un moyen de savoir ce qui a détruit un object pour savoir si c'est une ligne qui le met à null, le garbage collector, autres sans passer par toute les fonctions qui l'utilise?

Merci

[Pol63]

pour ce qui est sur la pile (variables de type struct et pointeurs de membres) c'est la sortie du bloc qui dépile et donc supprime la variable ou le pointeur
pour les objets sur le tas c'est le GC qui libère de la mémoire

quand il fait une passe sur toutes les instances en partant des objets vivants de départ et leurs références il sait alors quelles sont les instances non référencées et libère la mémoire
il appelle le finaliseur s'il y en a un, le finaliseur appelle Dispose(false) si la classe implémente IDisposable
(à noter que la mémoire est divisée en 3 selon la durée de vie des objets et qu'une passe agit sur une des 3 zone à la fois seulement)

mettre à null ne libère jamais la mémoire instantanément

de mémoire :
Pour les classes gérant de la mémoire non managée, et pour les classes utilisant des classes de ce type il est recommandé d'implémenter IDisposable
VS propose une implémentation simple ou plus complète, dans la plus complète on se retrouve avec une méthode Dispose(bool) (non public), une Dispose() et il est toujours possible d'ajouter un finaliseur/destructeur
Dans le principe si le développeur ne l'oublie pas il appelle Dispose() (via using le cas échéant), qui lui appelle Dispose(true) et c'est ici qu'on libère la mémoire non managée / qu'on peut appeler Dispose sur les variables de classe avec de la mémoire non managée
Si Dispose(false) est appelée ca veut dire que le GC intervient alors que le développeur n'a pas appelé Dispose, mais je pense que dans les 2 cas c'est le GC qui libère la mémoire managée
Avec un peu de chance, Dispose ne fait que s'occuper du finaliseur, et ne libère rien dans la foulée
car il y a aussi GC.SuppressFinalize(this) qui permet de déréférencé l'instance pour la finalisation

[François DORIN]

(à noter que la mémoire est divisée en 3 selon la durée de vie des objets et qu'une passe agit sur une des 3 zone à la fois seulement)

Pas tout à fait. J'avais fait un article sur le fonctionnement du ramasse miette. Il y a 3 zones + 1 (et encore, ce n'est plus vraiment vrai avec les dernières versions, où il me semble que le mécanisme implémentée à un peu changé, même si grosso modo, le principe général reste le même).

Les objets sont situés dans une zone :
- 0 : les objets fraichement alloués
- 1 : les objets moyen terme (grosso modo, les objets ayant survécu au 1er passage du ramasse miettes
- 2 : les objets long terme (les objets ayant survécu à plus de 2 passages du ramasse miettes

Lorsque le ramasse miette passe sur la zone 0, seul les objets de cette zone sont traités. Lorsqu'il passe sur la zone 1, c'est les deux zones 0 et 1 qui sont traités. Quand il passe sur la zone 2, c'est tous les objets qui sont étudiés.

La zone +1 concerne les objets de grande taille, qui sont sur un tas à part et considérés de base comme étant des objets de génération 2.

mettre à null ne libère jamais la mémoire instantanément

Tout à fait. En fait, il est même impossible d'appeler directement le destructeur d'un objet. C'est le ramasse miettes qui s'en charge au moment de la suppression d'un objet.

de mémoire :
Pour les classes gérant de la mémoire non managée, et pour les classes utilisant des classes de ce type il est recommandé d'implémenter IDisposable
VS propose une implémentation simple ou plus complète, dans la plus complète on se retrouve avec une méthode Dispose(bool) (non public), une Dispose() et il est toujours possible d'ajouter un finaliseur/destructeur
Dans le principe si le développeur ne l'oublie pas il appelle Dispose() (via using le cas échéant), qui lui appelle Dispose(true) et c'est ici qu'on libère la mémoire non managée / qu'on peut appeler Dispose sur les variables de classe avec de la mémoire non managée
Si Dispose(false) est appelée ca veut dire que le GC intervient alors que le développeur n'a pas appelé Dispose, mais je pense que dans les 2 cas c'est le GC qui libère la mémoire managée
Avec un peu de chance, Dispose ne fait que s'occuper du finaliseur, et ne libère rien dans la foulée
car il y a aussi GC.SuppressFinalize(this) qui permet de déréférencé l'instance pour la finalisation

Pour cela, j'avais fait une synthèse dans mon article sur les bonnes pratiques à suivre

En gros si dans un code tres long existe-t-il un moyen de savoir ce qui a détruit un object pour savoir si c'est une ligne qui le met à null, le garbage collector, autres sans passer par toute les fonctions qui l'utilise?

Pour les objets en général, non, ce n'est pas possible. Pour les objets implémentant l'interface IDisposable, c'est plus ou moins possible au niveau de la méthode Dispose(bool isDisposing) qui prend un booléen indiquant si la libération des ressources (et non destruction de l'objet, attention) est appelé depuis le destructeur (isDisposing = false) ou depuis la méthode Dispose() (isDisposing = true).

Le mécanisme est explicité dans l'article que j'ai cité juste au dessus

[agparchitecture]

Ok merci pour votre retour et éclaircissement.

Je vais donc "tracer" mon listview afin de savoir à quel moment il disparait