Discussion :

[new_wave]

Bonjour,

Normalement pour les objets gérés par le CLR, le CLR gère l'allocation de mémoire pour ces objets .

Mais pour les objets non gérés par le CLR (ex: connexion Bases de donénes, connexion réseau ou COM), il est nécessaire de leur allouer manuellement de la mémoire.

Cependant, pour créer une nouvelle connexion à une base de données, on peut créer une classe connexion dans laquelle on crée un variable qui contiendra la chaine de connexion.

Puis on pourra ensuite instancier cette classe.

La connexion devient-elle alors gérée par le CLR ou pas ?

Car je n'ai pas constaté que j'alloue moi même de la mêmoire pour gérer une connexion de base de données.

Par ailleurs, concernant le processus de destruction d'un objet , je lis que le garbage collector procède en plusieurs étapes:

1-les objets situés sur le heap sont marqués morts "jusqu'à preuve du contraire"

2-les objets références sont marqués vivants

3-les objets non vivants sont déplacés dans la zone nommée "freachabale queue".

4-on défragmente le heap en faisant migrer les objets qui s'y trouvent vers le bas du heap

5-on met à jour les pointeurs vers les objets du heap puisqu'ils ont été déplacés

6-le processus de finalization commence

Pour ce qui est de l'étape n°3, Il est ajouté que le garbage collector vérifie que les objets morts aient une méthode destructor.

Je ne comprends pourquoi existe cette vérification puisque normalement les objets que gère le garbage collector possèdent tous une méthode destructor.

Seuls les objets non gérés par le garbage collector n'en n'ont pas et il faut leur en ajouter un.

Autre question, la freachable queue est-elle située sur le heap ou pas?

Par ailleurs, les méthodes Collect(), WaitForPendingFinalizers, SupressFinalize(), ReRegisterForFinalize(), AddMemoryPressure(), RemoveMemoryPressure() s'appliquent normalement aux objets qui sont gérés par le garbage collector mais qui nécessitent une intervention particulière.

Cependant ces méthodes s'appliquent elles également aux objets qui ne sont pas gérés par le Garbage collector et pour lesquels on souhaite executer le processus de nettoyage de la mémoire , tout comme pour les autres objets gérés automatiquement par le Garbage Collector.

Concernant les méthodes AddMemoryPressure et RemoveMemoryPressure, s'appliquent elles bien aux objets qui ne sont pas gérés par le Garbage collector, pour leur allouer ou de la mémoire manuellement ou en récupérer.

Merci beaucoup de votre réponse sur tous ces points.

Cordialement

curieuse_prog

[tomlev]

Mais pour les objets non gérés par le CLR (ex: connexion Bases de donénes, connexion réseau ou COM), il est nécessaire de leur allouer manuellement de la mémoire.

Ah bon ? Je n'ai jamais alloué manuellement de la mémoire pour me connecter à une base de données...

Cependant, pour créer une nouvelle connexion à une base de données, on peut créer une classe connexion dans laquelle on crée un variable qui contiendra la chaine de connexion.

Puis on pourra ensuite instancier cette classe.

La connexion devient-elle alors gérée par le CLR ou pas ?

Ni plus ni moins qu'avant de créer ta classe connexion
La connexion elle-même peut être non managée, mais en pratique les objets que tu utilises pour manipuler cette connexion sont managés (par exemple une instance de SqlConnection est gérée par le GC comme n'importe quel objet .NET)

Car je n'ai pas constaté que j'alloue moi même de la mêmoire pour gérer une connexion de base de données.

Non, parce que tu n'as pas besoin de le faire. C'est fait si nécessaire par des objets qui s'occupent de gérer la connexion à la DB, par exemple en appelant des API non managées. La classe SqlConnection, par exemple, est juste un wrapper qui masque le mécanisme réel de connexion à la base de données ; il est possible qu'il y ait à l'intérieur des allocations mémoire, notamment s'il y a des interactions avec du code natif, mais ça ne te concerne pas : de ton point de vue, c'est un objet .NET comme un autre.

Je ne comprends pourquoi existe cette vérification puisque normalement les objets que gère le garbage collector possèdent tous une méthode destructor.

Seuls les objets non gérés par le garbage collector n'en n'ont pas et il faut leur en ajouter un.

Ah bon ? Je ne sais pas où tu as vu ça. La grande majorité des classes .NET n'ont pas de destructeur... Tu peux en implémenter un si nécessaire, mais ce n'est pas obligatoire
Voir MSDN: http://msdn.microsoft.com/fr-fr/library/66x5fx1b.aspx

Autre question, la freachable queue est-elle située sur le heap ou pas?

Aucune idée, mais pourquoi te poses-tu cette question ? Je programme en .NET depuis 10 ou 12 ans, je connais cette plateforme de façon très approfondie, et je n'ai jamais eu besoin de savoir ça... Est-ce que cette information aura une influence sur le code que tu écriras ? Ça m'étonnerait...

Par ailleurs, les méthodes Collect(), WaitForPendingFinalizers, SupressFinalize(), ReRegisterForFinalize(), AddMemoryPressure(), RemoveMemoryPressure() s'appliquent normalement aux objets qui sont gérés par le garbage collector mais qui nécessitent une intervention particulière.

Cependant ces méthodes s'appliquent elles également aux objets qui ne sont pas gérés par le Garbage collector et pour lesquels on souhaite executer le processus de nettoyage de la mémoire , tout comme pour les autres objets gérés automatiquement par le Garbage Collector.

Concernant les méthodes AddMemoryPressure et RemoveMemoryPressure, s'appliquent elles bien aux objets qui ne sont pas gérés par le Garbage collector, pour leur allouer ou de la mémoire manuellement ou en récupérer.

Euh... AddMemoryPressure ne sert pas à allouer de la mémoire. Ca sert simplement à prévenir le GC d'une allocation de mémoire non gérée. Il y a 99.99% de chances que tu n'aies jamais besoin d'appeler cette méthode.

Pour le reste, d'une manière générale, tu n'as quasiment jamais besoin d'interagir avec le Garbage Collector. La plupart des gens qui le font, le font à mauvais escient parce qu'ils ne comprennent pas bien comment ça fonctionne. A moins d'avoir une excellente raison de le faire et d'être un expert du GC, laisse le faire son boulot tranquillement, il s'en sort très bien tout seul

[new_wave]

Bonjour et merci de ta réponse.

Je reprends quelques unes de tes réponses

Ah bon ? Je ne sais pas où tu as vu ça. La grande majorité des classes .NET n'ont pas de destructeur... Tu peux en implémenter un si nécessaire, mais ce n'est pas obligatoire

D'après ce que j'ai compris, dès qu'un objet ne possède plus de référence sur la pile, il devient candidat à la destruction c'est à dire à l'appel de la méthode Finalize(après passage dans la freachable queue).

Quand il est écrit que "que le garbage collector vérifie que les objets morts aient une méthode destructor."pour l'étape n°3 du processus de destruction d'un objet , que cela signifie-t-il exactement alors:qu' il vérifie qu'il peut bien appeler la méthode Finalize pour ces objets?

Tu écris également

AddMemoryPressure ne sert pas à allouer de la mémoire. Ca sert simplement à prévenir le GC d'une allocation de mémoire non gérée. Il y a 99.99% de chances que tu n'aies jamais besoin d'appeler cette méthode.

D'après ce que j'ai compris cette méthode permet d'allouer de la mémoire non gérée.
Allouer de la mémoire non gérée signifie-t-il bien allouer de la mémoire pour des objets non gérés par le CLR?
Si c'est le cas, pourquoi n'aurait-on pas besoin d'allouer de la mémoire pour ces objets?

Merci encore beaucoup de tes réponses.
Cela m'aide à voir plus clair dans toutes ces notions.

Cordialement.

new_wave

Je te remercie de ta réponse sur ce point

[tomlev]

Je te conseille de jeter un coup d'oeil à cet article, qui contient beaucoup d'infos utiles sur le sujet :
http://msdn.microsoft.com/en-us/library/0s71x931.aspx

D'après ce que j'ai compris, dès qu'un objet ne possède plus de référence sur la pile, il devient candidat à la destruction c'est à dire à l'appel de la méthode Finalize(après passage dans la freachable queue).

En gros, soit l'objet a un finaliseur (i.e. il redéfinit la méthode Finalize, ce qui en C# se fait en déclarant un destructeur), soit non.
S'il n'en a pas, la mémoire (managée) utilisée par l'objet est juste récupérée
S'il en a un, il survit un peu plus longtemps : il est ajoutée à une file de finalisation, qui appellera la méthode Finalize. Une fois la méthode Finalize appelée, la mémoire de l'objet est récupérée.

Quand il est écrit que "que le garbage collector vérifie que les objets morts aient une méthode destructor."pour l'étape n°3 du processus de destruction d'un objet , que cela signifie-t-il exactement alors:qu' il vérifie qu'il peut bien appeler la méthode Finalize pour ces objets?

Il vérifie si la méthode Finalize est redéfinie (overriden)

D'après ce que j'ai compris cette méthode permet d'allouer de la mémoire non gérée.

Non. Lis la doc :

Informs the runtime of a large allocation of unmanaged memory that should be taken into account when scheduling garbage collection.

En gros, le GC ne sait pas ce qui se passe dans la mémoire non gérée (puisqu'il ne la gère pas), mais s'il y a une grosse allocation dans la mémoire non gérée, c'est une info utile pour le GC, car il peut en tenir compte pour retarder ou avancer la collecte des objets morts. AddMemoryPressure sert juste à fournir cette info au GC.

Allouer de la mémoire non gérée signifie-t-il bien allouer de la mémoire pour des objets non gérés par le CLR?

Ca signifie allouer de la mémoire pour n'importe quoi qui n'est pas géré par le CLR, pas forcément des objets. Typiquement, quand tu interagis avec du code natif en C, c'est de la mémoire qui va contenir des tableaux, des chaines de caractères, etc (le langage C n'a pas de notion d'objet de toute façon)

Si c'est le cas, pourquoi n'aurait-on pas besoin d'allouer de la mémoire pour ces objets?

Je n'ai pas dit que tu n'avais pas besoin d'allouer de la mémoire, j'ai dit que tu n'avais pas besoin d'appeler AddMemoryPressure (qui ne sert pas à allouer de la mémoire) .

[vanquish]

Lorsqu'une classe fait appel à des ressources non managées, il ne faut pas gérer le nettoyage de ces ressources dans le destructeur, mais rendre la classe disposable et le gérer dans la méthode Dispose();

Si tu encapsules dans ta classe une connexion à une base de donnée, si l'objet n'est plus référencé il va être détruit. Oui, mais quand ?
Tu n'en sais rien !

Si la fermeture de la connexion et le nettoyage mémoire est fait dans le destructeur, il peut se passer un certain moment entre l'éligibilité à la destruction et la destruction effective (et donc la clôture effective de la connexion et/ou le nettoyage effective de la mémoire - d'où, par exemple, des connexions fantômes liés à des objets libérés, mais pas encore détruits).

D'où l'intérêt du Dispose, qui est appelé par le destructeur, mais qui peut aussi être appelé manuellement. ( il faut d'ailleurs penser à gérer un flag, pour que le dispose n'exécute pas son code 2 fois : une lors de l'appel manuel, puis une seconde fois lors de l'appel par le destructeur au moment du garbage collector).

Le mieux est alors d'utiliser son objet au sein d'une clause using.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
using( CMaClasse instance = new CMaClasse())
{
     instance.ceci();
     instance.cela();
}
// Ici le dispose a forcement été appelé
// Les ressources non managées ont été nettoyé.
// et la limitation de la porté de la variable, fait que je ne peux plus 
// référencer l'objet.
// Peu importe quand l'objet sera détruit

Ca correspond en gros à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
CMaClasse instance = new CMaClasse();
try
{
     instance.ceci();
     instance.cela();
}
finally
{
     instance.Dispose();
}

Le soucis de cette dernière construction, c'est que, du point de vue du compilateur, je peux encore faire un appel à instance après le finally, alors que dans la réalité l'objet n'est plus utilisable puisqu'il a nettoyé ses ressources internes.

D'où l'intérêt du using() { }, qui limite la porté de la variable.

Si l'utilisateur de la classe oublie d'utiliser le using (ou d'appeler le Dispose), pas de soucis : le destructeur s'en chargera. Par contre l’utilisateur averti pourra manuellement libérer les ressources dès que possible, sans attendre le GC.

[new_wave]

Merci beaucoup de ces informations.

Je commence à y voir plus clair dans tout cela.

new_wave

[new_wave]

Bonjour,

tu écris

En gros, soit l'objet a un finaliseur (i.e. il redéfinit la méthode Finalize, ce qui en C# se fait en déclarant un destructeur), soit non.
S'il n'en a pas, la mémoire (managée) utilisée par l'objet est juste récupérée
S'il en a un, il survit un peu plus longtemps : il est ajoutée à une file de finalisation, qui appellera la méthode Finalize. Une fois la méthode Finalize appelée, la mémoire de l'objet est récupérée.

puis j'écris

Quand il est écrit que "que le garbage collector vérifie que les objets morts aient une méthode destructor."pour l'étape n°3 du processus de destruction d'un objet , que cela signifie-t-il exactement alors:qu' il vérifie qu'il peut bien appeler la méthode Finalize pour ces objets?

tu réponds alors
Il vérifie si la méthode Finalize est redéfinie (overriden)

Bien c'est compris.

Tu dis que quand un objet possède un destructeur
il est ajouté à une file de finalisation, qui appellera la méthode Finalize.

La file de Finalization , est ce bien la freachable queue.
Est-il exact que c'est le processus de garbage collection qui finalement execute la méthode Finalize pour ces objets

Te remerciant de ta réponse,

Cordialement.

new_wave

[tomlev]

La file de Finalization , est ce bien la freachable queue.

En fait je n'avais jamais vu ce terme de "freachable queue" avant que tu en parles. Mais en cherchant sur le net, non, ce n'est apparemment pas la même chose... D'ailleurs ma compréhension du processus n'était pas tout à fait exacte apparemment

En gros, si un objet qui a un finaliseur, un pointeur vers cet objet est mis dans la Finalization queue (dès sa création, pas lors de sa destruction).
Quand la garbage collection se produit, pour chaque objet identifié comme "déchets" (garbage), le GC cherche s'il y a un pointeur vers cet objet dans la Finalization queue. Si c'est le cas, il est retiré de la finalization queue et ajouté à la freachable queue. La freachable queue est traitée par un autre thread qui appelle Finalize sur chaque objet avant de le retirer. Une fois que c'est fait, la mémoire de l'objet peut être récupérée.

cf. cet article qui explique ça assez bien (en anglais)

Est-il exact que c'est le processus de garbage collection qui finalement execute la méthode Finalize pour ces objets

La processus de garbage collection au sens large, oui, mais pas la partie qui s'occupe d'identifier les objets à détruire. C'est un traitement séparé