Discussion :

[Sphax]

C'est pour celà qu'on a inventé GC.AddMemoryPressure.

Je ne vois pas le rapport. Cette méthode est faite pour informer le GC que tu as alloué beaucoup de mémoire non managée c'est tout. Ou alors tu veux l'utiliser de manière artificielle dés que tu utilises une ressource non managée pour forcer plus souvent le GC à tourner ? Mauvaise idée à mon avis.

[alaks]

Wow ca a bien avancé depuis la derniere fois.
Mais j'avoue que je suis un peu perdu, alors vaudrait 'il mieux faire un destructeur, appelé dispose et supprimé l'objet de la liste des elements a finaliser, ou laisser le GC faire tout, tout seul ?

Petite question : dans une structure en liste chainée (d'objets), pour éviter les fuites mémoire il faudrai mettre tous les objets de la liste a null, ou seulement la réference de la liste chainée ?


Merci

[Sphax]

Wow ca a bien avancé depuis la derniere fois.
Mais j'avoue que je suis un peu perdu, alors vaudrait 'il mieux faire un destructeur, appelé dispose et supprimé l'objet de la liste des elements a finaliser, ou laisser le GC faire tout, tout seul ?

Petite question : dans une structure en liste chainée (d'objets), pour éviter les fuites mémoire il faudrai mettre tous les objets de la liste a null, ou seulement la réference de la liste chainée ?


Merci

Laisser faire le GC seul, c'est à dire implémenter un finilazer sans implémenter dispose est une trés mauvaise idée. Si tu encapsules des ressources natives il FAUT implémenter dispose, la question est: faut-il aussi faire un finalizer ? Je crois que c'est préconisé par MS, moi je ne suis pas sur de l'utilité (voir mes réponses précédentes) sauf peut être dans des cas très particuliers.

Pour ta structure en liste chaînée, le GC est qd même intelligent, il recherche l'ensemble des références "atteignables" et supprime les autres. Des éléments d'une liste null (donc non atteignable) sont également non atteignables et seront collectés.

[dev01]

Petite question : dans une structure en liste chainée (d'objets), pour éviter les fuites mémoire il faudrai mettre tous les objets de la liste a null, ou seulement la réference de la liste chainée ?

Si ta liste chainé est 100 % .NET alors tu n'as rien à faire, le GC s'occupe de tout .

[smyley]

Je ne vois pas le rapport. Cette méthode est faite pour informer le GC que tu as alloué beaucoup de mémoire non managée c'est tout. Ou alors tu veux l'utiliser de manière artificielle dés que tu utilises une ressource non managée pour forcer plus souvent le GC à tourner ? Mauvaise idée à mon avis.

Mal utilisé, c'est une mauvaise idée, mais tu ne devrais pas sous estimer cette solution. Il vaut mieux avoir des Collect un peut plus souvent plutôt que d'avoir une application qui utilise 300 Mo sans jamais s'arrêter simplement parce qu'elle contient 80 Mo de données managées et le reste non managé.

[Sphax]

Mal utilisé, c'est une mauvaise idée, mais tu ne devrais pas sous estimer cette solution. Il vaut mieux avoir des Collect un peut plus souvent plutôt que d'avoir une application qui utilise 300 Mo sans jamais s'arrêter simplement parce qu'elle contient 80 Mo de données managées et le reste non managé.

Non mais on se comprend pas là. Bien sûr que si tu a des classes qui "encapsulent" beaucoup de mémoire non managée alors il faut utiliser cette méthode, c'est fait pour ça ! Maintenant qd on parle de ressources non managées c'est aussi souvent des handles (ouverture de fichiers, mutex etc...) et dans ce cas tu ne vas pas utiliser AddMemoryPressure pour artificiellement générer des collectes...

Globalement ce que je veux dire c'est que l'appel des finalizer est lié à la gestion de la mémoire, que c'est non déterministe et surtout sans lien direct souvent avec la ressource que tu gères (tu peux ouvrir plein de handle sans jamais générer de garbage collection et inversement, ce n'est pas lié). A partir de là pour moi l'intérêt et plus que limité, contrairement aux destructeurs du C++ qui sont déterministes, ils sont appelés dés qu'on sort du scope de l'objet.